Claude computer use and browser use: the GA toolsets

Claude can now drive a screen without a beta header. On 19 August 2026 Anthropic moved computer use out of beta as computer_toolset_20260801, which controls a whole desktop through screenshots, mouse and keyboard, and launched browser_toolset_20260801, which works inside a browser and reads the page itself. Both are client tools: Claude decides the next click, and your code performs it in a machine you run. Pick browser use when the job lives in web pages, computer use when it needs desktop apps, and neither when an API or a page fetch would do.

Three ways to get a job done on a website

Driving a screen is the slowest and most expensive way for an agent to reach information, so it comes last:

1. An API or an MCP server. If the system has one, call it. A function call returns exact data without a screen.
2. Web fetch. If Claude only needs to read a page you can point it to, the web fetch tool brings the text back without a browser.
3. Browser use, then computer use. When the work means logging in, clicking through a form or reading a page that builds itself with JavaScript, give Claude a browser. When it means a desktop app, a remote desktop or files across applications, give it a computer.

Anthropic's own advice runs the same way: browser use for tasks that stay inside web pages, computer use when a task needs a whole desktop, web fetch for reading.

What each toolset gives Claude

One entry in tools declares a set of member tools. You do not name them; the toolset version fixes them.

The element references are the reason browser use is the better choice for web work. A coordinate breaks when a banner pushes the page down; a reference points at the button itself, from the accessibility tree your executor reads. Claude still falls back to screenshots and coordinates for canvases, video, virtualized lists and cross-origin frames that the tree does not describe. Anthropic also notes that a tree read of a typical page often costs fewer tokens than a screenshot.

Neither toolset is in Claude Managed Agents yet, and neither runs on Anthropic's side: you host the browser or the desktop.

The loop your code runs

Claude never touches the machine. Each response holds one or more tool_use blocks, each naming a member and carrying toolset_name; your code runs them and sends back one tool_result per block. Since August, Claude can return several actions in one turn, such as click, type, press Enter, which Anthropic calls a batch action. You run the blocks in order, stop at the first failure and answer every later block with a fixed error text:

import anthropic

client = anthropic.Anthropic()
tools = [{"type": "browser_toolset_20260801"}]
messages = [{"role": "user", "content": "Open status.example.com and list the services that are degraded."}]

while True:
    response = client.messages.create(
        model="claude-sonnet-5-5", max_tokens=4096, tools=tools, messages=messages
    )
    messages.append({"role": "assistant", "content": response.content})
    if response.stop_reason != "tool_use":
        break

    results, failed = [], False
    for block in response.content:
        if block.type != "tool_use":
            continue
        result = {"type": "tool_result", "tool_use_id": block.id, "toolset_name": "browser"}
        if failed:  # an earlier action in this batch failed: do not run the rest
            result |= {"is_error": True, "content": "Not executed: an earlier action in this turn failed."}
        else:
            try:
                result["content"] = run_member(block.name, block.input)  # your Playwright code
            except Exception as error:
                failed = True
                result |= {"is_error": True, "content": str(error)}
        results.append(result)
    messages.append({"role": "user", "content": results})

print(response.content[-1].text)

Two rules trip people up. Every tool_use block needs an answer, or the next request is rejected, so a loop that reads only the first block breaks as soon as Claude batches. And if a person approves risky actions, the check has to run before each block, because one turn can complete a whole purchase. The computer toolset's halt text is slightly different: Not executed: an earlier computer action in this turn failed.

You may not need to write this loop. Since 7 October the Python and TypeScript SDKs have browser and computer toolset classes, in beta, that run it with the tool runner, apply your approval callback and, for the browser, a URL policy, and take a driver from a provider: Browser Use or Browserbase for the browser, Daytona for the computer, E2B for either. You still supply, or rent, the browser.

Moving off computer_20251124

Existing integrations keep working with their beta header on the models listed for them, including Claude Opus 5, Sonnet 5 and Opus 4.8. The forcing change is the Claude 5.5 models: on the Claude API and Google Cloud, Opus 5.5, Sonnet 5.5 and Haiku 5.5 reject the earlier versions with an error. If you switch models, you switch tools:

• Drop the anthropic-beta: computer-use-2025-11-24 header and call the standard client.
• Replace the entry with {"type": "computer_toolset_20260801"}; delete name, display_width_px, display_height_px, display_number and enable_zoom, which the toolset now rejects.
• Dispatch on name plus toolset_name instead of input.action, and handle every block in a turn.
• Echo "toolset_name": "computer" on every result.
• Decide on zoom. It is now on by default; if your environment cannot crop, set "configs": {"zoom": {"enabled": false}}.
• Honour the new repeat field on key, or "press Tab 4 times" becomes one press.
• Resize screenshots yourself. The toolset takes no display size, does not downscale and rejects an image over the model's limit, 2,576 pixels on the long edge for the models that support it.

Amazon Bedrock is the exception: there the 5.5 models still accept computer_20251124, and the toolset is not available.

What a task costs

Neither tool has a fee of its own. You pay for tokens, and the screenshots are what add up: each one is billed as image input, about 1,200 tokens at 1280×720, and because every request resends the conversation, a screenshot taken on turn 3 is paid for again on turn 4, 5 and every turn after. Without prompt caching, the cost of a turn grows with its position, and the total grows with the square of the turns.

Try itWhat does one screen-driving task cost?

Toolset

Computer useBrowser use

Screenshot size

·1024×768·1280×720·1280×800·1920×1080

Turns to finish the task

30

a turn is one request; it can carry several actions

530100

Model

Opus 5.5Sonnet 5.5Haiku 5.5

Conversation history

CachedNot cached

Turn 1Bars: cost of each turn, not cached. Dashed line: the other way.Turn 30

On our assumptions, a 30-turn browser task on Claude Sonnet 5.5 costs about $1.89 with no cache and $0.31 with one; at 100 turns the gap is $17.13 against $1.53. Claude Haiku 5.5 is cheaper per token but charges higher rates on any request whose prompt passes 100,000 tokens, so a long run on Haiku jumps from about $0.33 at 60 turns to about $2.97 at 100. Anthropic's advice for the 5.5 models is to keep screenshots at 2,000 pixels or less a side and not to prune old ones on the client, because removing an earlier screenshot invalidates the thinking that followed it; use server-side tool result clearing instead. For whole-agent budgets, the agent cost simulator works on the same prices.

Keep the page from driving

A computer use agent reads whatever the screen shows, and anything on a page can be written to steer it. Anthropic's docs say plainly that Claude sometimes follows instructions found in content even when they conflict with yours. Anthropic runs classifiers over screenshots and page text that flag likely injections and make Claude check before acting, but it treats them as an extra layer, not the defence. (They don't currently run on browser toolset requests through Amazon Bedrock.) Our prompt injection examples show what such text looks like.

The precautions that do the work are in your environment:

• A fresh machine each session. A dedicated container or VM with minimal privileges and a browser profile that is signed in to nothing you would not hand to Claude.
• An allowlist at the network. The SDK's URL policy checks only the URLs Claude asks navigate to open, and without one it checks none. A click or a redirect can still reach localhost or the cloud metadata address 169.254.169.254. Egress rules on the container can block the metadata address and private ranges, but rules outside the container can't block localhost, so check each request in the driver as well. Our piece on limiting what an agent can fetch covers that layer.
• Only http and https. Refuse file:, which reads the host's files, and javascript:, which runs script even with javascript_exec off.
• Risky members off. Leave javascript_exec and file_upload disabled unless the task needs them; the SDK refuses to enable either without an approval callback.
• A person for consequences. Purchases, account changes, messages and accepting terms go to a human first; our human-in-the-loop guide covers how to pause a run for approval.

Where it still falls short

Anthropic lists the limits itself: it is slower than a person, so it suits background jobs and automated testing more than live help; it can misjudge coordinates or pick the wrong tool, more often in niche apps or several apps at once; scrolling and spreadsheets can take several tries; and it is limited at creating accounts or posting on social platforms. For anything that needs perfect precision or handles sensitive data, Anthropic's advice is a human watching. That makes the best first jobs for these tools the ones with no API and a forgiving outcome: checking a vendor portal, testing your own web app, filling an internal form, collecting a status from a dashboard. They are the tool use of last resort, not the first thing an agent reaches for.