Computer Use Goes GA — and the Browser Toolset That Reads the Page Instead

Five Parameters That Now Fail the Request

Under computer_20251124, the tool entry described your display. Under the GA toolset it describes almost nothing, because the toolset itself fixes what used to be configurable. The whole entry can be one field:

{ "type": "computer_toolset_20260801" }

Everything you used to put alongside it is now an error rather than an ignored extra, which is the good outcome — a rejected request tells you immediately, where a silently dropped field would not. The five removals and what replaces each one:

The configs object is keyed by member name, and every member you omit keeps its default. That default matters, and it is the one item on this list that can change behaviour without changing your code: all members are enabled by default, zoom included, and the release note lists “zoom enabled by default” as one of the things going GA brings. If you deleted an enable_zoom line during the migration, or never sent one, you are now offering Claude a member your executor may have no handler for. Decide it explicitly rather than inherit it:

{
  "type": "computer_toolset_20260801",
  "configs": {
    "zoom": { "enabled": false }
  }
}

Each member config accepts enabled and defer_loading, the latter for tool search. The toolset has 17 members in total — screenshot, zoom, the five click variants, left_click_drag, the three mouse-button and movement members, cursor_position, scroll, type, key, hold_key and wait — so an executor written against the beta tool already covers the surface. The entry itself also still accepts cache_control, and allowed_callers restricted to ["direct"]. You cannot declare both tool versions in the same request, and you cannot declare another tool named computer alongside the toolset.

Coordinates Move Into the Screenshot You Return

Dropping display_width_px and display_height_px is the change most likely to produce a working request that clicks the wrong thing. Claude now expresses every coordinate in the pixel space of the screenshot it was given, with the origin at the top left, and never relative to a zoomed crop. If you downscale a physical display before sending it, the mapping back is yours to do:

scale = 1024 / 1512          # screenshot width / real display width
screen_x = claude_x / scale
screen_y = claude_y / scale

Any code that derived that scale from the values you used to declare on the tool entry needs to derive it from the screenshot instead. The documented resolution guidance is unchanged in spirit: 1024x768 or 1280x720 for general desktop work, 1280x800 or 1366x768 for web applications, and nothing above 1920x1080. There is more headroom than there used to be — every model that supports the GA toolset accepts up to 2576 pixels on the long edge and 4784 visual tokens per image, against 1568 pixels and roughly 1.15 megapixels on earlier models — but headroom is not a reason to use it. A larger screenshot costs more image tokens on every single turn of an agent loop, and the loop is where the cost lives.

Batch Actions Change the Loop, Not Just the Request

The GA toolset also lets Claude return several actions in one response — click, then type, then screenshot. The response shape is the same as parallel tool use, with one difference that inverts the usual rule: you run the blocks in order, not concurrently, because the type depends on what the preceding click focused. If one fails, you do not run the rest.

You still owe a tool_result for every tool_use block, including the ones you skipped, and every result must carry toolset_name matching the block it answers:

{
  "type": "tool_result",
  "tool_use_id": "toolu_01Xf5W1sD8Q9aBcJ7kLmN2pQ",
  "toolset_name": "computer",
  "is_error": true,
  "content": "Not executed: an earlier computer action in this turn failed."
}

A batch is also where an executor's assumptions about retries stop holding. Re-running a whole failed batch replays actions that already succeeded, and a click that submitted a form is not free to repeat — the reasoning in idempotent tool calls for AI agents applies directly here, because a batch turns one retry decision into several.

The Model List Is Part of the Migration

The GA toolset runs on Claude Fable 5, Claude Mythos 5, Claude Opus 5, Claude Sonnet 5 and Claude Opus 4.8. Claude Opus 4.7, Claude Opus 4.6, Claude Sonnet 4.6 and Claude Opus 4.5 support computer use only through computer_20251124, with its beta header. So if your integration is pinned to Sonnet 4.6, the toolset migration is a model migration first, and it should be sequenced and verified as one rather than folded into the same change.

Platform coverage narrows the same way. Both toolsets are Claude API features: Claude Platform on AWS, Amazon Bedrock, Google Cloud and Microsoft Foundry stay on the earlier beta tool versions, and the browser toolset is not currently available on Managed Agents at all. A multi-cloud deployment therefore has to keep the beta path alive rather than replace it. That makes this a two-branch period, not a cutover — the same shape as the other Claude API betas that went GA on the same date, covered in the Claude API beta headers that just went GA. Existing computer_20251124 integrations keep working, so there is no forced date; the risk is drift between the two branches, not breakage.

When the Browser Toolset Is the Better Answer

browser_toolset_20260801 is not a renamed computer use. It works inside a browser viewport instead of a whole desktop, and it reads the page rather than only photographing it. read_page returns the accessibility tree as text with a reference on each element, find takes a natural-language description such as "search field" and returns matches, and get_page_text returns visible text for read-heavy pages. Claude then acts on a reference:

{ "type": "tool_use", "name": "left_click",
  "input": { "target": { "type": "ref", "ref": "ref_2" } } }

That is the substantive difference for anyone automating a web flow. A pixel coordinate breaks when a banner shifts the layout by 40 pixels; ref_2 does not care where the element moved to. References are scoped to the tab that produced them and go stale when the page navigates or the DOM changes materially, and the documented recovery is to re-read the page rather than to guess. Coordinates remain available for the cases where an accessibility tree is not usable — canvas, iframes, virtualised lists — and they are viewport pixels, not desktop pixels. The toolset adds form_input for setting a field's value directly instead of clicking and typing, multi-tab handling through a browser_state block that reports the full tab inventory after each call, and download reporting.

Four of its 31 members are disabled by default, and they are disabled for a reason: javascript_exec runs arbitrary code in the page context, file_upload writes to file inputs, and read_console and read_network can surface secrets and credentials that appear in logs or URLs. Enable one only if your executor implements it and the task needs it. Everything the page returns is untrusted input, tab titles and URLs in browser_state included, which is ordinary prompt-injection and tool-safety territory rather than a browser-specific novelty. The documentation is explicit about the rest: isolate the browser, allowlist domains at the network layer, reject any scheme that is not http or https using a URL parser rather than a prefix check, and require human confirmation before consequential actions.

The choice is not close in most cases. If the task never leaves a webpage, the browser toolset gives Claude structure to work from and survives layout changes. If it touches the desktop, several applications or a native window, computer use is still the only option. If you only need to read a page, neither is the answer — web search and web fetch are, and the Claude API guide covers where each server-side tool fits.