Claude computer use went GA on 19 August 2026: seven changes that break an existing agent loop

Summary. Anthropic made computer use generally available on the Claude API on 19 August 2026 as the computer_toolset_20260801 toolset, and shipped a separate browser_toolset_20260801 on the same day. The GA toolset carries 17 member tools; the browser toolset carries 27 by default and 31 with every optional member enabled. Declaring the computer toolset adds about 4,500 input tokens to every request (about 4,520 on Claude Fable 5, Mythos 5, Opus 5 and Opus 4.8, about 4,590 on Sonnet 5). The browser toolset adds about 6,600. Anthropic's own migration list runs to seven items, and three of them silently change runtime behaviour rather than returning an error. zoom flips from off to on, oversized screenshots are rejected instead of downscaled, and the action name moves out of input.action. Migration is optional, because computer_20251124 keeps working with its beta header, which is precisely why teams will hit these changes months from now with no deployment to blame.

What actually shipped

The Claude API release notes dated 19 August 2026 list eight changes. Computer use reaching GA is the one that touches running code.

The old shape was a single tool named computer, with the action carried inside the input object. The new shape is a toolset: one entry in tools that expands into 17 member tools, each of which arrives as its own tool_use block. Anthropic's documentation states it plainly: "The computer use tool is an Anthropic-defined client toolset: one {"type": "computer_toolset_20260801"} entry in tools gives Claude 17 member tools such as screenshot, left_click, type, and zoom, and your application runs every call in an environment you control."

The block shape changes with it. Where a response previously carried "name": "computer" and "input": {"action": "left_click", "coordinate": [500, 300]}, it now carries "name": "left_click", "toolset_name": "computer", and "input": {"coordinate": [500, 300]}. As the docs put it: "The action name moves from input.action to name, and the block gains toolset_name."

Two constraints are worth knowing before you read the migration list. Computer use "isn't currently available in Claude Managed Agents," and "Platforms other than the Claude API currently offer only the earlier beta tool versions" — so Bedrock and Vertex integrations are not migrating yet even if you want them to.

The seven changes, and which ones fail loudly

Anthropic's migration section gives seven steps. Sorted by how you find out you got it wrong:

The zoom flip is the one that will cost teams an afternoon. Anthropic is explicit that the default reversed: "Zoom is enabled by default on the toolset, whereas enable_zoom defaults to false. If your environment doesn't implement zoom, add "configs": {"zoom": {"enabled": false}} to keep the previous behavior; otherwise implement it." An executor that ignores unrecognised member names will not crash. It will return errors to Claude, which will retry, and the loop will look flaky rather than broken.

The repeat change has the same shape. The docs warn that "A handler that ignores unrecognized fields would press the key once, so make your key handler honor repeat." A cursor that moves one line instead of forty is a bug report, not an exception.

Screenshot sizing is the third silent-ish one, and it moved work onto your side. "Screenshots and zoom images that you return to the computer use toolset must already fit within your model's image size limits: the toolset takes no display dimensions and the API doesn't downscale for you, so an oversized tool_result image is rejected with a validation error." The limits differ by model generation: "Claude Opus 4.7 and later models, including every model that supports computer_toolset_20260801, accept up to 2576 pixels on the long edge and 4784 visual tokens total (ceil(width/28) x ceil(height/28), approximately 3.75 megapixels); earlier models accept up to 1568 pixels on the long edge and approximately 1.15 megapixels total." A 4K desktop screenshot clears neither.

Batch actions rewrite the agent loop, not just the parser

The change with the widest blast radius is not in the migration list at all. Claude can now return several actions in one response: "Claude can plan a short sequence of actions, such as click, type, and then take a screenshot, and return them together in one response. This is called a batch action; it uses the same response shape as parallel tool use with one difference: you run the blocks in order rather than concurrently."

Three consequences follow, and the docs spell out all three.

A loop that reads only the first block is now a hard error rather than a partial execution: "A request that leaves any tool_use block in the batch unanswered is rejected with an invalid_request_error, so an agent loop that reads only the first block fails on its next call."

When an action in the batch fails, you must halt the rest and return a specific string. Not a paraphrase of it — the exact text Not executed: an earlier computer action in this turn failed. The browser toolset mandates a different string for the same situation: Not executed: an earlier action in this turn failed. One word apart, two toolsets, both validated.

The third consequence is a governance problem rather than a parsing one. If your product asks a human to approve consequential actions, the approval gate moved. Anthropic's warning: "If your application asks a human to confirm consequential actions, make that check before each block runs, because a batch can complete a multistep action within one turn." A confirm-per-turn design that was adequate in November 2025 now waves through a click, a form fill and a submit as a single unit. Teams building reliable agent tool-use evaluation should treat this as a new test case, not a config change.

If you cannot restructure the loop yet, there is an escape hatch: set disable_parallel_tool_use to true in tool_choice and "Claude then returns at most one member tool_use block per turn."

What the toolsets cost before a single click

The token overhead is published, and it is not small. Both figures below are quoted from Anthropic's pricing page, which matches the individual tool pages exactly.

Sonnet 5 sits at "$2 / $10 per MTok", which Anthropic confirmed on the same pricing page is now the standard rate after the increase scheduled for 1 September 2026 was cancelled. The cost column above is our arithmetic on Anthropic's published token counts, not a figure Anthropic publishes.

The number that matters is the ratio. The GA toolset costs roughly four times the old single-tool definition in per-request overhead, and it is charged on every request in the loop, not once per session. A 40-step browsing task on Sonnet 5 pays about $0.53 in toolset definitions before you count a single screenshot. Disabling zoom claws back about 410 of those tokens. Neither toolset carries a per-action or per-session charge — both are client tools, priced like any other request.

That is the honest trade. You are paying for 17 or 31 typed member tools instead of one overloaded action enum, and the model no longer has to guess an action string. Whether that is worth four times the overhead depends entirely on how many turns your task takes, which is the same calculation that governs mid-conversation tool changes and prompt caching.

The browser toolset is a different product, not a lighter computer use

The browser tool released the same day works "in a browser that your application runs" rather than a whole desktop, and Anthropic is clear that nothing moves to their side: "Your application runs every call against its own browser automation; nothing runs on Anthropic's side."

The real difference is that it reads structure, not only pixels. "It works with the page both through its structure (the accessibility tree, elements, forms, and tabs) and through pixels (screenshots and viewport coordinates), whereas the computer use tool works with a whole desktop through screenshots and coordinates alone." The docs make an efficiency claim for that: "a tree read of a typical page often costs fewer input tokens than a screenshot while giving Claude references it can act on immediately." On a text-heavy page that can offset the higher definition overhead. On a canvas-rendered app it will not.

Element references are the mechanism, and they come with a caveat you have to design around: "References are scoped to the tab that produced them and stay valid until that tab navigates or its DOM changes materially. The API can't detect a stale or unknown reference." Detection is your job, and so is stability: "Don't renumber references you've already handed out for a tab until it navigates, because that silently invalidates references Claude still holds."

Four members are off by default, and the reasoning is a security argument rather than a capability one: "javascript_exec and file_upload because they widen what a manipulated page could make Claude do, and read_console and read_network because not every browser automation stack can supply those logs and they widen what page-controlled content reaches Claude."

The sharpest warning on the page concerns file_upload: "Claude writes these paths while it's reading untrusted pages, so an unrestricted implementation would let a malicious page direct the upload of any file the executor can read to a site the page controls. Enable the member only when your executor resolves each path (following symlinks and .. segments) and accepts nothing outside a dedicated, allowlisted upload directory that holds only files meant for the task. Don't reuse the browser's download directory for this; if you do, every file a page causes the browser to download becomes uploadable."

Prompt injection gets the same treatment for tab metadata: "Tab titles and URLs come from the page and render into text Claude reads, so they're a prompt-injection surface... The length and character limits the API enforces are a floor, not a defense." Those limits are 4,096 characters per tab_id, title and url, at most 100 tabs and 200 state changes per block.

Download reporting hides a data-leak edge worth flagging to a security reviewer: "The url comes from the remote server and often carries signed query-string credentials after redirects, so strip query parameters you don't want in Claude's context."

Who this affects, and how to tell if that is you

You are affected if any of the following is true.

You send anthropic-beta: computer-use-2025-11-24 today. Nothing breaks now, but you are on a version Anthropic has labelled an earlier tool version, and the platforms question below will eventually force the move.

Your agent loop reads response.content[0] and dispatches on input.action. Both assumptions are gone in the new toolset.

You run on Bedrock or Vertex. You cannot migrate yet: "Platforms other than the Claude API currently offer only the earlier beta tool versions."

You screenshot a display larger than 2576 pixels on the long edge and relied on the API to shrink it.

You have a human-approval step that fires once per model turn.

Grep your codebase for display_width_px, enable_zoom, and input.action. Three hits is a migration; zero hits and you are probably not using computer use at all. Teams comparing implementations across vendors will find the same loop questions in our breakdown of computer use and browser agents across Gemini, Claude and OpenAI.

India-specific considerations

For Indian teams building agent products for regulated buyers, two details in this release change the compliance conversation. Both toolsets are marked ZDR eligible, which matters when a BFSI or healthcare client asks where screen contents go. But the execution environment is entirely yours: page content reaches the API only as tool results you return, and the sites Claude visits see your executor's network identity, not Anthropic's. Under the Digital Personal Data Protection Act 2023, that makes the browser executor, not the model provider, the place where personal data handling has to be designed, logged and bounded. An allowlisted upload directory and a query-string stripper are DPDP controls, not just hardening.

What is still unknown

Anthropic has not said when computer_20251124 stops being accepted; the docs only say migration "is optional" and that the earlier version "keep[s] accepting it with its beta header." There is no published date for the Managed Agents or Bedrock and Vertex availability. The browser toolset page describes itself with two different member counts: "27 member tools by default" in the introduction and "declares 31 member tools" in the member table. That reconciles as 27 plus 4 optional, but will mislead anyone who quotes either number alone.

FAQ

How eCorpIT can help

Migrating a working computer-use agent is mostly loop surgery and cost modelling, not prompt work: the parser, the batch halt contract, the approval gate and the per-request token bill all move together. Our senior engineering teams build and govern agent systems for regulated buyers, including the executor sandboxing that browser use pushes onto the customer side. If you are weighing the migration against staying on the beta tool, our note on AI coding agent rollout and governance covers the control questions, and you can reach the team through /contact-us/.

References

1. Claude API release notes Anthropic, 19 August 2026 entry.

1. Computer use tool Anthropic documentation, including the migration section.

1. Browser use tool Anthropic documentation.

1. Claude API pricing toolset definition overhead figures and Sonnet 5 standard pricing.

1. Tool reference Anthropic documentation.

1. Beta headers Anthropic documentation.

1. Files API Anthropic documentation, GA response format.

1. Tool use overview Anthropic documentation.

1. Vision and image limits Anthropic documentation.

1. Models overview Anthropic documentation, supported model list.

1. Agent Skills Anthropic documentation.

Last updated: 21 August 2026.