Wednesday, October 7, 2026ArchiveSearchAsk the paper

The Computomatix Times

All the posts fit to save — curated from @computomatix's bookmarks & likes on X

Shopify Launches WebMCP Checkout Support for Browser Agents

Browser agents now shop and check out faster on Shopify using WebMCP

Shopify announces WebMCP support for checkout, including Shop Pay, for eligible merchants, letting agents read, update and submit checkouts through structured tools instead of scraping pages. The author explains when to use UCP hosted MCP endpoints versus WebMCP in the browser.

Original post · 6 min read
Shopping with an agent shouldn’t feel like watching paint dry. 🥱
Today, we’re launching WebMCP support for checkout, including Shop Pay, for all eligible Shopify merchants.

Learn how it works, where UCP fits, and what the data shows:
X ArticleBrowser agents now shop and check out faster on Shopify using WebMCP
Today, we’re launching WebMCP support for checkout, including Shop Pay, for all eligible Shopify merchants. I recently wrote that shopping with a browser agent is often slower and less reliable than doing it myself. The agent reads the page, finds an input, fills it, and reads the page again to figure out what changed. Then the agent does that again, and again, and again for every input. Sometimes, it even fills in the wrong information.
We already support WebMCP for storefronts and carts, so agents can search products, browse collections, and add items to a cart through structured tools. Now they can also read the checkout, update it, and submit it with the buyer’s authorization. From search to order, no screenshots or scraping required.
When should you use WebMCP?
Shopify exposes structured commerce APIs via the Universal Commerce Protocol (UCP), that enable agents to discover products, build carts, and checkout. UCP is the shared language that hosted MCPs and WebMCP both speak to. These are different access methods to the same protocol, to support wherever your agent runs.
Some agents work entirely server to server. Some work inside the buyer's browser. Some do both in one purchase, like an agent that builds a checkout through our APIs and moves into the browser when the buyer needs to review or verify something.
So here's my recommendation. If your agent can work without a browser, then go server to server, reach UCP through our hosted MCP endpoints, like Checkout MCP. It's the most efficient path, as it does not require loading and rendering pages and orchestrating a browser.
If your agent is operating in the buyer’s browser, use WebMCP tools provided on storefront and checkout to efficiently complete order placement, instead of navigating HTML built for humans. These WebMCP tools provide structured and efficient APIs, purposely designed — via UCP — to ensure accurate commerce facts, required disclosures, and handoff requirements.
A checkout interface built for agents
I’ve worked on checkout for years and I know that details matter. An address changes the available shipping options; a delivery choice changes the total, which may in turn affect discount eligibility and more; a merchant may require the buyer to accept terms before placing an order. An agent has to get these right.
With WebMCP, checkout surfaces tools with well-defined names, descriptions, and input schemas that capture the full fidelity of required inputs and context to negotiate a checkout. A browser agent can now discover those tools and call them in the buyer’s existing session.
There are three core tools:
get_checkout reads the current checkout, including line items, totals, fulfillment options, and messages about what’s missing or blocking.
update_checkout applies the desired writable state through checkout’s existing validation and returns the recalculated checkout.
complete_checkout attempts to place the order after the agent signals buyer authorization for the purchase.
The responses tell the agent what’s still missing, if buyer action is required, and when the order has been placed.
Updates describe the desired state
Updates are PUT-style. An agent sends the complete desired state for the writable fields accepted by update_checkout, and receives the full updated response, eliminating guesswork and possibility of missed terms or requirements.
For example:
The buyer changes their shipping address.
The agent submits the new address alongside the values it needs to retain.
WebMCP returns the full updated checkout and messages, which enables the agent to immediately detect and reason through cases where only partial fulfillment is available, split shipping is required, and all of its downstream consequences.
The agent can then select a delivery option from that response in its next update.
Less guesswork and fewer turns for the agent, with more reliable outcomes for the buyer.
Just how much better is WebMCP?
Browser agents spend time repeatedly interpreting screenshots or scraping the DOM and deciding where to click or type. Take a Shop Pay buyer with multiple saved addresses. With browser automation, the agent has to open the address book, parse the page, and click through to make a selection. With WebMCP, it can retrieve those addresses and select the right one by ID. The address book is already structured data. The agent should be able to use it that way.
We compared WebMCP in checkout with browser use using GPT-6 Sol, with the same prompts and starting conditions. We tested 10 checkout tasks across 2 test shops, running each task 6 times with each approach: 30 paired comparisons, or 60 attempts in total.
In this benchmark, here’s how WebMCP performed:
Time per attempt: 27.4s → 10.3s, or 2.7x as fast.
Cost per attempt: 58% lower when using WebMCP, at OpenAI’s list price.
Successful attempts: 56/60 with browser automation → 60/60 with WebMCP.
Tasks included updating an address, applying and removing a discount, updating an email, e… continue on X ↗
♥ 146 · ⟲ 18 · 👁 41.5KView on X ↗

More in Agents & Dev Tools

Developer Rebuilds Seven Adobe Apps in Rust Using Opus 5.5

Peter Yang highlights a developer who reimplemented seven Adobe apps, including Photoshop, Premiere and Lightroom, in Rust with Claude Opus 5.5 and open-sourced them. The developer believes they can match Adobe's features within months, against Adobe's $840 yearly all-apps plan.

Original post · 1 min read
It's insane to watch AI blow apart closed source software and games.

4 examples from the past month:

1. 7 of Adobe's biggest apps, including Photoshop, Premiere, and Lightroom, have been partially rebuilt in Rust with Opus 5.5 and open sourced. It's still early, but the developer thinks they can match Adobe's features within months. Adobe's all-apps plan costs $840/year.
Miguel Ángel Durán @midudev
Todos los productos de Adobe reimplementados desde cero, gratuitos y de código abierto

→ getartcraft.com/apps
♥ 50 · ⟲ 2 · 👁 10.7KView on X ↗

Vercel's Guillermo Rauch Explains Turborepo's Migration From Go to Rust

Guillermo Rauch says Vercel moved Turborepo from Go to Rust, a migration that was controversial internally due to human costs. He argues that with AI agents the calculus has changed, so what is best for humans is no longer necessarily best for business.

Original post · 1 min read
DHH is fundamentally right about Rust. For context, Vercel has been undergoing a Rust-ification (carcinization, technically 🦀) for a while.

One of the first projects we migrated was Turborepo, from Go to Rust¹. The migration completed, but the RoI was actually quite controversial internally.

While Rust was in our eyes better for low-level OS access, something crucial for a build system like Turbo, the human migration costs were very sustantive.

Go is very fast. It's beautifully designed. It's easy to iterate on. We were very conflicted about the migration, because it was *humans* writing the code, *even if we knew Rust was a better choice*.

The calculus has now changed. What's "best for humans" is no longer necessarily "best for business".

FWIW, it's also quite unlikely that Rust is the end-all-be-all toolchain. I'm quite certain there's greener pasture ahead, because Rust itself was designed before the 'supersonic tsunami' of agents hit.

¹ https​://vercel.com/blog/how-turborepo-is-porting-from-go-to-rust
♥ 3.2K · ⟲ 152 · 👁 352.7KView on X ↗

Integer Multiplication Algorithm Bound Tightened Repeatedly With Astra

A post reports that a user running ChatGPT Astra in a loop is repeatedly breaking records for integer multiplication algorithms. It quotes an update to OpenAI problem #109 that tightens the constant from 2^-182 to 2^-59, a roughly 500,000-fold improvement over the previous result.

Original post · 1 min read
This guy has 6.1 Astra running in a loop and is breaking the record for integer multiplication algorithms every few hours lmaooooo.
Doug Colkitt @0xdoug
We are publishing an update to OpenAI problem #109 Integer multiplication) with another substantial further tightening:

κ = 2⁻⁵⁹ (from OpenAI’s original κ = 2⁻¹⁸²)

Approximately 500 thousand fold improvement over our previous result and a 2¹²³ fold improvement over the original OAI result.

The latest redesigned the finite network to share intermediate computations and scratch space, then tightened the recursion and Gaussian estimates.
♥ 4.1K · ⟲ 118 · 👁 167.4KView on X ↗

Boris Cherny Says Prompting Claude Should Feel Like Talking to a Coworker

Boris Cherny explains his approach to prompting Claude, advising users to give clear goals, specify effort level and verification steps rather than relying on heavy scaffolding.

Original post · 1 min read
I am surprised that people are surprised this is how I prompt Claude.

Talk to Claude the way you would a coworker. There's no secret to prompting. There's no need to be overly scaffolded or prescriptive for most tasks -- give Claude a goal, and it will figure it out.

Back in the Sonnet 3.5 days, your prompt mattered a lot. Nowadays, it's much more important to communicate to the model:

1. What you want it to do
2. How much effort you want it to spend
3. How it should verify that it did the right thing
Boris Cherny @bcherny
Prompt
♥ 12.1K · ⟲ 720 · 👁 1.1MView on X ↗

Eric Raymond Highlights Open-Source Rust Clone of Photoshop Built via LLM

Eric S. Raymond shares the photocraft GitHub project, a clean-room open-source reimplementation of Photoshop that he says was likely generated by decompiling the app, converting it to a spec and prompting an LLM for Rust. He argues this threatens closed-source software.

Original post · 1 min read
This is the doom I predicted a few days ago, coming for Photoshop. A clean-room open-source reimplementation.

No prizes for guessing that they decompiled Photoshop to source code, processed that to some kind of non-code specification language, then fed the spec to an LLM with an instruction to generate Rust.

Adobe just got nuked. And closed source is dead, dead, dead.

github.com/storytold/photocraft
♥ 16.2K · ⟲ 1.4K · 👁 3.7MView on X ↗

Nat Eliason Details Fourteen Ways His Bot Setup Automates Work

Nat Eliason lists fourteen functions of his bot setup, including a chief-of-staff agent that drafts emails, specialist agents per work lane, and cloud coding agents that open pull requests from Linear issues. He notes GrokBot as a substantial improvement over his previous OpenClaw setup.

Original post · 2 min read
Things my @bot setup does that still blow my mind:

1. A Chief of Staff who opens the day pulling open loops from email & tasks and suggesting things it can knock out before 7am.

2. After every meeting, decisions get folded into Notion, Linear, and Todoist — not left rotting in Granola

3. Every email starts as a draft. The CoS bot scans my email every ~2hr and drafts replies to nearly everything — including checking my cal for availability and finding requested attachments / links

4. A specialist for each lane: curriculum, engineering, coaching, hiring, content, ops, and one for every single piece of software

5. Routines that keep running while I’m offline (e.g. monitoring Sentry errors in our apps and proactively fixing things)

6. Group rooms where 2–4 bots share one project thread instead of me copy-pasting context

7. Cloud coding agents that pick up Linear issues and open PRs after running the list of open work by me EoD — then squash-merge to main when it’s done

8. Meeting prep briefs pulled from Granola + Notion before I walk in

9. A growing shareable knowledge base in Notion + a GitHub repo that we update daily based on what happens at school

10. Student progress look-up across Expertise, Followers, and CoFounder without inventing numbers — chat anytime to see where a student is on their business work

11. Mentor Mind that coaches me on how to hold the bar without inventing doctrine

12. Todoist as a central task list where it logs things it’s blocked on for me, or from meetings / emails — and I can paste links into chat to direct it how to solve them

13. Engineering work is automatically tracked in Linear so my and the product teams’ bots don’t collide with each other

14. Presentations spun up in Gamma / Claude Design without me opening a slide tool

15. Plaud / live capture → notes the bots can actually act on

Probably more but these were the immediate ones we thought of.
Nat Eliason @nateliason
GrokBot feels like absolute magic at this point, a meaningful leg up on my previous OpenClaw etc. setups.

And with how easy it is to setup, there's really no excuse now.
♥ 2.1K · ⟲ 207 · 👁 522.0KView on X ↗