Claude's browser use tool costs 6,600 input tokens per request before a screenshot: the 19 August 2026 release

Summary. Anthropic released browser_toolset_20260801 on 19 August 2026, generally available on the Claude API with no beta header. Declaring it adds about 6,600 input tokens to every request, about 2,100 more than the computer use toolset's 4,500, and about 880 more if you enable all four optional members. At Claude Sonnet 5's $2 per million input tokens that is roughly $0.0132 of standing cost per request, or $132 per 100,000 requests before Claude sees any page content. On Claude Opus 5 at $5 per million it is $0.033 per request. The tool runs only on the Claude API: not on Amazon Bedrock, not on Google Cloud, not on Microsoft Foundry, and not inside Claude Managed Agents. The computer use page, meanwhile, advertises platforms its own next line withdraws.

What shipped

The browser use tool documentation describes the difference from computer use in one sentence: the browser tool "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."

Nothing runs on Anthropic's side. The docs are explicit: "Your application runs every call against its own browser automation." Your executor supplies the browser, the network identity the visited sites see, and every tool result. The API contributes the tool definitions and the agent loop.

The tool reference records it as GA and as a first version: "browser_toolset_20260801 is the first version of the browser use tool." There is no earlier beta to migrate from, and one legacy header is actively rejected on toolset entries — the fine-grained-tool-streaming-2025-05-14 beta header, because "each member's input arrives as one complete input_json_delta."

The token arithmetic

This is a client toolset, so there is no per-call surcharge and no server-side execution fee. You pay in tokens, and the standing cost is large enough to appear on an invoice.

From the tool page, repeated word for word on the pricing page: "Declaring browser_toolset_20260801 with its default members adds about 6,600 input tokens to a request (about 6,610 on Claude Fable 5, Claude Mythos 5, Claude Opus 5, and Claude Opus 4.8, and about 6,670 on Claude Sonnet 5), which covers the member tool definitions and the tool use system prompt. Enabling all four optional members adds about 880 tokens."

The computer use figure on the same pages is "about 4,500 input tokens" with "about 410" of that removed if you disable zoom.

Configuration	Standing input tokens per request	Cost per request, Sonnet 5 at $2/MTok	Cost per 100,000 requests, Sonnet 5
computer_toolset_20260801, default	about 4,500	about $0.0090	about $900
browser_toolset_20260801, default	about 6,600	about $0.0132	about $1,320
browser_toolset_20260801, all four optional members enabled	about 7,480	about $0.0150	about $1,500

The same three rows on Claude Opus 5 at $5 per million input tokens run to about $2,250, $3,300 and $3,740 per 100,000 requests. Prompt caching changes this materially, and the docs point at the token counting endpoint for a real number rather than an estimate — but the shape of the bill is set before your prompt is written.

Then come the observations. Computer use documentation puts screenshots at "roughly 1,000-1,800 input tokens each", and a browser agent loop accumulates them the same way. The browser tool's own guidance argues for reading the page structure instead: "a tree read of a typical page often costs fewer input tokens than a screenshot while giving Claude references it can act on immediately." That is the cost case for the accessibility tree, stated by the vendor, and it is the main reason to prefer this toolset over driving a whole desktop.

Where Anthropic's own pages disagree

Three conflicts sit in the launch-day documentation. Each one is checkable, and each one costs somebody an afternoon.

The computer use compatibility card contradicts the release notes

The computer use page documents computer_toolset_20260801. Its compatibility card lists, in adjacent bullets:

- Platforms: Claude API, Claude Platform on AWS (beta), Amazon Bedrock (beta),
  Google Cloud (beta), Microsoft Foundry (beta)
- Platforms other than the Claude API currently offer only the earlier beta tool versions.

The release notes for 19 August 2026 say the toolset is "now generally available on the Claude API", and that "Both toolsets are available for Claude Fable 5, Claude Mythos 5, Claude Opus 5, Claude Sonnet 5, and Claude Opus 4.8 on the Claude API."

So a page whose subject is the new toolset advertises Bedrock, Google Cloud and Microsoft Foundry as platforms, then withdraws that in the following line. "Computer use runs on Bedrock" and "the computer_toolset_20260801 runs on Bedrock" are different claims, and one card makes both. The browser use page has no such ambiguity: "Platforms: Claude API; not available on Claude Platform on AWS, Amazon Bedrock, Google Cloud, Microsoft Foundry." If your deployment is on Bedrock or Foundry, the browser tool is not available to you and the computer toolset is not either.

Three cross-page anchors do not resolve

The browser use page delegates its entire limitations discussion and all of its screenshot-resizing guidance to the computer use page, using anchors that page does not have. #understand-computer-use-limitations points at a section actually headed "Limitations". #handle-coordinate-scaling-for-higher-resolutions points at one headed "Size screenshots to fit image limits". #understanding-the-agentic-loop points at "Understand the agent loop".

Small on its own. As evidence it is not small: the browser page was written against an older revision of the computer use page and shipped without a link check, on the same day both went GA.

The member count is given twice, differently

The page's opening paragraph says the toolset "gives Claude 27 member tools by default". The member tools section says the entry "declares 31 member tools". Both are true — 31 declared, four disabled by default — but neither sentence reconciles with the other, and the arithmetic appears only much further down, in a note about deferred loading.

What you have to build

Adopting this is not a config change on an existing computer use integration. The concrete deltas, all from the two tool pages:

The toolset_name on every result becomes "browser", and a result carrying the wrong value is rejected. The halt text changes: computer use requires the exact string "Not executed: an earlier computer action in this turn failed." while browser use requires "Not executed: an earlier action in this turn failed."

Coordinates become target objects. Computer use takes coordinate: [x, y]; browser use takes either a coordinate object or a reference object such as {"type": "ref", "ref": "ref_2"}. That means you must build and hold a reference registry. The docs are direct about the failure mode: "Don't renumber references you've already handed out for a tab until it navigates, because that silently invalidates references Claude still holds." References come from read_page and find, are scoped to the tab that produced them, and "the API can't detect a stale or unknown reference."

There is a new content block type, browser_state, with API-enforced shape rules. Tab-management results must carry exactly one such block and nothing else. Each tab_id, title and url may be at most 4,096 characters, and "a block may list at most 100 tabs and 200 state changes." Getting the shape wrong returns an invalid_request_error, not a soft failure.

Most of the other bounds are advisory, and this is the sentence to paste into your design doc: "The input bounds and output conventions noted in each member's row are stated to Claude, not enforced by the API, so validate inputs (including coordinates against your viewport) and apply the conventions in your executor." Your executor is the only thing enforcing that read_page caps output at 50,000 characters, that find returns at most 20 matches, or that a click lands inside the viewport.

The security work is yours, and the docs say so

Four members are disabled by default. Two of them, javascript_exec and file_upload, are off "because they widen what a manipulated page could make Claude do."

The file upload warning is the sharpest paragraph in the release: "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."

Navigation has a similar shape. The docs require you to "parse the URL and refuse any scheme other than http or https (javascript:, file:, data:, chrome:, and so on)", with a URL parser rather than a string prefix, and add the reason plainly: "the API never sees the navigation and can't reject it for you."

That is the honest summary of a client toolset. Anthropic defines the interface and bills the tokens; every guardrail is code you write. Teams comparing this against a full-desktop approach should read our note on the computer use toolset migration and its breaking changes and the three-vendor comparison of Gemini, Claude and OpenAI computer use and browser agents.

Where it will not work

The stated limitations are short and worth reading before a pilot. Browser use is Claude API only. Streaming delivers each member's input as one complete block, so there is no partial-input preview. Element references are best-effort: "Highly dynamic pages (virtualized lists, canvas-rendered interfaces, pages that re-render on scroll) might not expose stable references, and Claude falls back to screenshots and coordinate clicks there." And read_console and read_network "report only what it can capture, and only from the moment it attached to a tab."

The virtualized-list caveat matters more than it reads. Enterprise admin consoles, data grids and search results are exactly the surfaces a browser agent is bought for, and they are exactly the surfaces that re-render on scroll. When references fail there, you fall back to screenshots at 1,000-1,800 tokens each and the cost case for the accessibility tree evaporates.

Screenshots also have to be resized by you. "The API doesn't downscale toolset images: a screenshot or zoom image over your model's image size limits, or over the stricter per-image limit that applies once a request holds more than 20 images, is rejected." A long loop crosses 20 images within a few dozen turns.

India-specific considerations

For Indian teams the deployment restriction is the operative fact. Browser use runs on the Claude API only, so an architecture pinned to Amazon Bedrock or Microsoft Foundry for regional or procurement reasons cannot use it at all today. That decision usually predates the model choice.

Because the browser runs in your environment, page content reaches the API only as the tool results you return, which gives you a real control point for Digital Personal Data Protection Act 2023 obligations: you decide what leaves the executor. The corollary is that redaction is your code, not a platform setting. Teams replacing scripted automation should also weigh the token floor against a deterministic script, a trade we set out in our note on replacing RPA with computer use agents.

What is still unknown

Anthropic publishes no API-level timeout, rate limit or per-session cap for this toolset; timeouts appear only as sample error text in an executor example. There is no migration guide from computer use to browser use — the only migration section on either page covers the older computer_20251124 version. The cloud-platform documentation pages could not be checked for this article, so their own account of toolset availability is unconfirmed. And the two toolsets can be declared together, "each in its own coordinate frame", with no published guidance on what that combination costs in tokens.

FAQ

What is the Claude browser use tool?

It is an Anthropic-defined client toolset, browser_toolset_20260801, released on 19 August 2026. One entry in the tools array gives Claude 27 member tools by default and four more on request. Your application runs every call against its own browser automation; nothing executes on Anthropic's infrastructure.

How much does it add to each request?

About 6,600 input tokens for the default member set, rising by about 880 tokens if all four optional members are enabled. The figure varies slightly by model: about 6,610 on Claude Opus 5 and about 6,670 on Claude Sonnet 5. That cost applies before any page content or screenshot reaches the model.

How does that compare with computer use?

Computer use declares at about 4,500 input tokens, so the browser toolset carries roughly 2,100 more per request. Disabling zoom removes about 410 tokens from the computer use figure. At Claude Sonnet 5 input pricing of $2 per million tokens, the 2,100-token gap is about $210 per 100,000 requests.

Which models and platforms support it?

The supported models are claude-fable-5, claude-mythos-5, claude-opus-5, claude-sonnet-5 and claude-opus-4-8. It runs on the Claude API only and is documented as unavailable on Claude Platform on AWS, Amazon Bedrock, Google Cloud and Microsoft Foundry. It is also not currently available inside Claude Managed Agents.

Is a beta header required?

No. The documentation states it is generally available on the Claude API with no beta header; you add one entry of type browser_toolset_20260801 to the tools array. One legacy header is rejected on toolset entries, the fine-grained-tool-streaming-2025-05-14 header, because each member's input arrives as one complete block.

What is the biggest implementation risk?

File upload. Anthropic's own documentation warns that an unrestricted implementation would let a malicious page direct the upload of any file the executor can read. The member is disabled by default and should stay off unless your executor resolves every path and confines uploads to a dedicated allowlisted directory that is not the download directory.

Where do element references break?

On highly dynamic pages. The documentation names virtualized lists, canvas-rendered interfaces and pages that re-render on scroll as surfaces that might not expose stable references. Claude falls back to screenshots and coordinate clicks there, which costs roughly 1,000 to 1,800 input tokens per screenshot.

Can we migrate an existing computer use integration?

Not by configuration. The toolset name, halt text and coordinate format all change, you must implement a reference registry and the new browser_state content block, and you must add URL-scheme validation the API does not perform. Anthropic publishes no migration guide between the two toolsets.

How eCorpIT can help

eCorpIT builds and operates agent systems on the Claude API, including the executor layer this toolset requires: the reference registry, the browser_state handling, the URL and upload guardrails, and token budgeting against a real workload rather than a launch-post estimate. If a browser agent is on your roadmap and you need the cost floor modelled before you commit, our AI engineering team can scope it. Start at /contact-us/.

References

1. Browser use tool, Claude Platform documentation
2. Computer use tool, Claude Platform documentation
3. Claude Platform release notes, 19 August 2026 entry
4. Claude Platform pricing
5. Tool reference and client toolsets
6. Tool use overview and pricing
7. Vision: image size limits and request limits
8. Token counting endpoint
9. Claude Managed Agents tools
10. Claude models overview
11. Messages API overview and pagination

Last updated: 22 August 2026.