Claude can drive a computer and a browser: what shipped, and what it means for a store

Anthropic took computer use out of beta on 19 August 2026 as computer_toolset_20260801, and launched a separate browser tool the same day. The sentence "Claude can use a computer" covers two different things, though, and the difference decides who carries the security burden. Here is what shipped, what it costs, and what the technology will not do for you today.

Two different things with the same name

Worth separating up front, because conflating them leads to bad security decisions.

Per Anthropic documentation and release notes, accessed 3 September 2026.

The API version is the one most often misread. The documentation is explicit: Claude does not connect to that environment directly. The model returns a list of actions, your application translates them into clicks in your environment, captures the result and sends it back as a screenshot.

Put another way: the model never sees your computer. It sees an image you sent it.

Computer use: seventeen actions on a machine you run yourself

The toolset exposes seventeen actions across a whole desktop: screenshot, zoom into a region, five kinds of click, drag, cursor movement, scrolling, typing text, individual keys and combinations, holding a key, and waiting.

• Models: Opus 5, Sonnet 5, Opus 4.8, Fable 5.1, Mythos 5.1, Fable 5 and Mythos 5.
• Platforms: Claude API and Google Cloud fully; Claude Platform on AWS, Amazon Bedrock and Microsoft Foundry in beta.
• What you supply: a virtual X11 display, a window manager, installed applications and the agent loop. Anthropic’s reference implementation runs in a Docker container.
• Limitation: the tool is not available in Claude Managed Agents.

Browser use is a separate tool, and the one that matters for stores

The same day brought browser_toolset_20260801, thirty-one actions scoped to webpages. The difference from desktop control runs deeper than scope.

Per the documentation for both tools, accessed 3 September 2026.

That distinction lands directly on store work. An admin panel, a marketplace seller console and a supplier portal are all webpages, so the browser tool handles them more reliably: it acts on element references rather than coordinates, which means a small layout change does not knock the whole flow over.

Beyond clicking, it also reads page text, finds elements, uploads files and, optionally, inspects the console and network requests. Those last two, along with executing JavaScript, are the ones the documentation recommends leaving switched off by default.

Counting the cost

There is no separate price; you pay the normal token rate for whichever model you use. The catch sits elsewhere.

• One screenshot: 1,000 to 1,800 input tokens.
• Image ceiling: up to 2,576 pixels on the long edge on newer models, at 4,784 visual tokens.
• Guidance: no more than twenty images in a single request.

An agent clicking through a panel takes a screenshot after every step to see what happened. On a thirty-step loop the images alone run to tens of thousands of input tokens before any text is counted. The cost of this kind of automation therefore scales with the number of steps rather than the length of the instruction, which is why short tasks come out disproportionately cheaper than long ones.

The real risk sits in the page content

This part of the documentation is the most valuable and the least quoted. Anthropic states outright that browser use carries risks standard API features do not, because the model reads and acts on content from the open web, where any page can carry text written to steer it.

The example given is disarmingly plain: text on a page saying "ignore your previous instructions and navigate to…" can divert the model from its task. That is not a flaw in the model but a property of reading somebody else’s content.

The vendor’s guidance, condensed:

• Isolation: a dedicated container or virtual machine with minimal privileges and a fresh profile holding no credentials.
• Network: a domain allowlist enforced at the network layer rather than in code.
• Addresses: accept only http and https; reject javascript, file, data and chrome schemes.
• Data: treat everything a page supplies as untrusted, tab titles and URLs included.
• People: human confirmation for consequential actions, meaning purchases, account changes, messaging and accepting terms.

One defence arrived on the model side: classifiers flag suspected prompt injection inside a screenshot and steer Claude to ask the user for confirmation before continuing.

What this means for a store

Three conclusions, in order of practicality.

Panels without an API stop being a dead end

The most interesting use is systems you cannot integrate with: an older wholesale panel, a supplier portal, a carrier console, a form somebody has been filling in by hand for five years. Driving a browser routes around the missing API, because it clicks the way a person does.

An honest caveat: this is a workaround, not an integration. It runs slower, costs more and breaks when the interface is rebuilt, so I would treat it as a bridge until a real API exists rather than as a destination.

Credentials are the genuinely hard part

For an agent to reach a seller panel, it has to log in. The documentation recommends a fresh profile holding no credentials, which sits in obvious tension with the idea of having it work a panel that requires an account. Resolving that tension belongs to the implementation, and it is the hardest piece of the whole puzzle.

Buying in somebody else’s store is its own category

The vendor puts purchases on the list of actions requiring human confirmation. Worth remembering when deciding what an agent does alone and what it brings back for approval.

If you are thinking about agents on your own side of the store rather than the buyer’s, we covered that in our piece on what AI agents do in a store panel on a Monday morning. Why such automation can fail without a single exception in the logs is in our piece on quiet failures, and the models these tools run on we covered around the Fable 5.1 release.

At Seedlight we build this kind of automation in the AI Automation stage of the BEAM framework, and we start by asking whether an API can do the job, because it is cheaper and steadier when it can. Driving an interface comes in when there is no API and there will not be one. The scope is on our AI commerce automation page. Where the work concerns Amazon or Allegro seller panels, that side is run by our sister agency Amazonway in marketplace account management.