Claude's new browser tool bills about 6,610 input tokens before it reads a word of your prompt. That is five times the computer-use beta's floor, and a single line of JSON takes 90% of it back.

What 6,610 tokens buys before Claude reads anything

Credit where it is due. Most vendors ship an agent tool and let you find out what the scaffolding costs from your invoice. Anthropic printed the number on its pricing page, which is the only reason this post can exist. The wording is precise about what is included: the figure covers the member tool definitions and the tool use system prompt, together, as one lump.

The legacy row is deliberately empty in both model columns. Those versions run on Opus 4.7, Opus 4.6, Sonnet 4.6 and Opus 4.5, none of which support the GA toolsets, so 466 to 499 tokens of system prompt plus roughly 735 per definition is what they cost on their own models rather than on these. Two other things about the table are easy to misread, so let me flag them before anyone quotes it. First, Anthropic publishes two buckets, not five per-model figures. Fable 5, Mythos 5, Opus 5 and Opus 4.8 share one number and Sonnet 5 gets its own. If you see an article listing five distinct browser-tool token counts, someone invented three of them. Second, the +880 for optional members is a single lump for enabling all four at once. There is no per-member breakdown, so you cannot work out what turning on just read_network costs.

The four optional members are javascript_exec, file_upload, read_console and read_network, all off by default. Anthropic's reasoning is not about money at all: the first two widen what a manipulated page could make Claude do, and the last two are off both because not every browser automation stack can supply those logs and because they widen what page-controlled content reaches Claude. The cost consequence is a happy accident. The safe default is also the cheap one, which is not the usual arrangement.

The beta this replaces cost about a quarter as much

Here is the comparison nobody has run. The legacy computer use versions charged 466 to 499 tokens of system prompt plus roughly 735 input tokens for the tool definition, measured on computer_20250124. Add those and the old fixed floor was somewhere between 1,201 and 1,234 tokens.

One caveat belongs on those multiples before anyone repeats them. Anthropic states that Claude 4.7 and later use a newer tokenizer producing roughly 30% more tokens for the same text, a change The Register picked apart in July for making Anthropic's rate card hard to compare with anyone else's. The ~735-token legacy definition was measured on an old-tokenizer model and the 4,520 and 6,610 figures are new-tokenizer counts, so part of the jump is the tokenizer rather than the toolset. Back that out and the like-for-like range is nearer 2.8x to 4.2x. Still a large increase, and still not the five-and-a-half-fold one the raw division suggests.

I want to be fair about what the extra tokens buy, because this is not a price rise dressed up as a feature. The GA computer toolset has 17 members against the beta's single tool, it supports batch actions so several actions fit in one turn, and zoom is on by default. The browser toolset carries 31 members, 27 of them enabled. You are paying for a much larger vocabulary. The point is simply that the vocabulary is not free and it is charged per request rather than per session.

One structural detail changes the migration math. The legacy versions run on Opus 4.7, 4.6, Sonnet 4.6 and Opus 4.5. The GA toolsets run on Fable 5, Mythos 5, Opus 5, Sonnet 5 and Opus 4.8. Those sets do not overlap at all, so you cannot hold the model constant and swap the toolset to measure the difference. Every migration off the beta is a model change and a toolset change at the same time, and the tokenizer moved too.

One line of JSON takes 90% of it back

This is the whole post, really. A toolset definition is the most cacheable thing in an agent request: it is large, it sits at the front of the prefix, and it does not change between turns. Cache reads bill at 0.1x input on every Claude model, so a cached toolset costs a tenth of an uncached one.

Anthropic's tool use with prompt caching page spells out where the marker goes, and it is a place people will get wrong on the first try: put cache_control on the toolset entry itself, and the breakpoint lands after the toolset definition. It is not accepted inside a member's configs entry, because the toolset's members load as one definition. That last clause is the useful bit. You are not caching 31 tools, you are caching one object.

Placement helps you here too. Cache prefixes are built in the order tools, then system, then messages, so the toolset is the first thing in the prefix and everything you cache after it stacks on top. Both toolsets also clear the published minimum cacheable prefix length without effort. That minimum is 512 tokens on Opus 5, Fable 5 and Mythos 5 and 1,024 on Opus 4.8 and Sonnet 5, which is every model these toolsets run on. The 4,096-token threshold you may have read about belongs to Opus 4.6, Opus 4.5 and Haiku 4.5, none of which support either toolset. At 6,610 tokens the browser toolset is not close to any of those floors.

One footnote on that table: Anthropic marks Mythos 5 as limited availability, so its row is a published rate rather than one most teams can buy today. Sonnet 5's row is the one that quietly got better this month. Anthropic confirmed that its $2 and $10 introductory card is now the standard price and the September 1 step up to $3 and $15 will not happen, which we covered when that increase was still on the calendar. Had it landed, every browser-tool request on Sonnet 5 would have gone from $0.01334 to $0.02001.

The cache is easier to break than it looks

Caching is the answer, but it is a fragile answer, and an agent loop is exactly the workload that breaks it. Anthropic's invalidation table is blunt about the default case: modifying tool definitions invalidates the entire cache, tools and system and messages together. So a config that toggles read_network on for troubleshooting does not cost you 880 tokens, it costs you the whole prefix on the next turn. There is an escape hatch worth knowing about, in beta since July 24 on Fable 5, Mythos 5, Opus 4.8 and Opus 5: mid-conversation tool changes (mid-conversation-tool-changes-2026-07-01) let you add or remove tools between turns while preserving the prompt cache. Note which model is missing from that list. Sonnet 5 supports both toolsets and does not support the beta.

The second trap is quieter. Toggling images present or absent invalidates the messages cache, and Anthropic notes for both toolsets that screenshot presence affects the messages cache. A loop that screenshots on some turns and not others is churning its own message cache on every transition. That does not touch the toolset definition, which sits ahead of messages in the prefix and survives, but it does mean your cache hit rate will look worse than the headline suggests.

The third one is genuinely easy to trip over. Inside a batch action, a cache_control marker on any of the turn's member tool_use or tool_result blocks is accepted and takes effect at the end of that batch, so several markers in one batch behave as a single breakpoint. Each marker still counts against the request limit of four breakpoints. Batch actions are the headline GA feature, so the natural way to write this code is also the way that silently spends your breakpoint budget. Use one marker per turn.

One adjacent rule, since people will go looking for it. On the tool search tool page Anthropic states that a tool with defer_loading: true cannot also carry cache_control, and that the API returns a 400; put the breakpoint on a non-deferred tool instead. Toolsets take defer_loading per member inside the entry's configs object rather than on the entry itself, and no page we found says what happens to a cache_control marker on a toolset whose members defer. Assume nothing there and test it.

Screenshots are not billed in pixels

I had the formula wrong before I checked, and I suspect most people do. Claude does not bill images by pixel area divided by some constant. It views them in 28 by 28 patches, so an image costs ceil(width / 28) times ceil(height / 28) visual tokens. Every model that supports these toolsets sits on the high-resolution tier, which allows a 2,576-pixel long edge and caps at 4,784 visual tokens. The standard tier caps at 1,568.

Look at what that does to the shape of the bill. On Opus 5 a single full HD screenshot costs $0.01346. That is roughly two-fifths of the entire uncached browser toolset definition, and once you have cached the definition down to a third of a cent, that one screenshot costs four times the definition it travels with. Cache the definition and screenshots become the dominant line on your invoice almost immediately. The computer use docs put a typical screenshot at roughly 1,000 to 1,800 input tokens, which only holds if you are sending something closer to a laptop viewport than a full HD frame.

There is a sharp edge here that will bite people in production. Images you return to these two toolsets are not downscaled for you. Anthropic states that the API rejects a tool_result image exceeding the model's limits with a validation error instead of resizing it, so a 4K monitor screenshot is a failed request rather than an expensive one. Resize before you return. Related: once a request holds more than 20 images, a stricter per-image dimension limit applies to every image in that request, and images nested in tool_result blocks count toward the threshold. A long browsing session hits 20 screenshots quickly.

Fifty turns, priced both ways

Let us put a number on the advice. Take a 50-turn browsing loop and count only the toolset definition, ignoring your prompt, the page text, the screenshots and the model's replies. Uncached, you pay the full definition 50 times. Cached, you pay one 5-minute cache write at 1.25x input on the first turn and 49 cache reads at 0.1x after it.

The ratio is 8.13x on all three rows, and it is worth seeing why. It is not that the token counts match, because Sonnet 5's do not. Both the token count and the rate cancel out of the division entirely, leaving 50 divided by (1.25 + 49 x 0.1), which is 8.1301 for any model at any price. Caching a 50-turn loop is worth the same multiple everywhere. Pick a dearer model and it does not become more urgent in percentage terms, only in dollars. Anthropic's own break-even guidance is simpler than any of this: a 5-minute cache pays for itself after one read, a 1-hour cache after two.

Run one caution over these figures. Anthropic permits declaring both toolsets together but publishes no combined number, and both stated figures include the shared tool use system prompt. Adding 6,610 and 4,520 double-counts it, and on Opus 5 that shared block is 286 tokens with tool_choice set to auto or none, or 406 with any or tool. So the true combined figure is around 10,844 rather than 11,130. If it matters to you, the token counting endpoint will tell you exactly, and the response usage object reports the real count after the fact.

You cannot buy browser use on Bedrock at any price

The two toolsets shipped on the same day and they did not land in the same places. Anthropic lists computer use on the Claude API plus Claude Platform on AWS, Amazon Bedrock, Google Cloud and Microsoft Foundry in beta, then adds a line that changes what that list means: platforms other than the Claude API currently offer only the earlier beta tool versions. Bedrock sells you computer_20251124, not the GA toolset. Browser use is first-party Claude API only, and it is absent from Claude Managed Agents as well.

For cost planning that asymmetry matters more than it first looks, because the levers that move an Anthropic bill are mostly platform-specific. Bedrock and Google Cloud regional endpoints carry their own 10% premium over global. On the first-party API and Claude Platform on AWS, asking for US-only inference with inference_geo applies a 1.1x multiplier to every token category, input and output and cache writes and cache reads alike, on Claude 4.6 and later. Those multipliers stack with the Batch discount and with each other. If your compliance posture requires Bedrock, browser use is not a cost question yet. It is simply not available, and the nearest substitute is the legacy computer tool driving a browser through a virtual desktop. That one is cheaper per request, at the 1,201 to 1,234 token floor, which is the rare case where the constrained platform bills less rather than more. You are paying for it in vocabulary instead. We wrote up the wider Bedrock rate story when OpenAI's cards landed there, and the shape of the problem is the same: the endpoint decides the price before the model does.

The two dearest models have no published baseline

Every tool-enabled request carries a tool use system prompt on top of the definitions, and Anthropic publishes a table of it: 286 tokens on Opus 5 with tool_choice auto or none and 406 with any or tool, 290 and 410 on Opus 4.8, 354 and 474 on Sonnet 5, 675 and 804 on Opus 4.7, 496 and 588 on Haiku 4.5. Zero if you send no tools at all.

Fable 5 and Mythos 5 are not in that table. They are the two most expensive models on the Claude API at $10 and $50 per million, they both support both toolsets, and the per-request baseline for them is simply not published anywhere we could find. It does not change the toolset figures above, which fold the system prompt in already. It does mean that if you add a couple of your own tools to a Fable 5 request, you cannot predict the overhead from the docs. You have to measure it.

While we are listing gaps: there is no per-member cost for the four optional browser members, no quantified saving for disabling browser members through configs beyond the statement that it reduces the count, and no combined figure for both toolsets. Thezoom switch on computer use is the only config-level reduction Anthropic puts a number on, at 410 tokens, which is 9.1% of that toolset. Anthropic's answer to all of it is the token counting endpoint, which is a fair answer for a developer and a useless one for anyone trying to budget a quarter in advance.

The cheapest thing you can do takes one line

My advice after two days with these numbers is unglamorous. Put cache_control on the toolset entry before you write anything else, because it is one line and it takes about 88% off the definition. Leave the four optional browser members off unless a specific task needs them, since they cost 880 tokens and turning them on mid-session invalidates your whole cache. Disable zoom on computer use if you are not zooming. Resize screenshots to something near a laptop viewport rather than a full HD frame, which is worth more per turn than the entire cached definition.

And choose the toolset by fit rather than by price. The 2,090-token gap between browser and computer use is about a cent on Opus 5, which is nothing next to the cost of an agent taking six extra turns because it is driving a browser through a screenshot loop instead of reading the page. That is the mistake worth avoiding. The definition overhead is a fixed, cacheable, well-documented cost; wasted turns are neither fixed nor documented. Current rates for every model named here sit on the pricing page, and you can push your own token split through the calculator.

Six Anthropic pages, and the row missing from one of them

• Anthropic: Claude API pricing - The source of almost everything above. The ~6,610 and ~6,670 browser figures and the +880 for optional members; the ~4,520 and ~4,590 computer figures and the 410-token zoom saving; the legacy 466 to 499 system prompt and ~735 per definition; the tool use system prompt table, which carries thirteen model rows and none for Fable 5 or Mythos 5; the full rate card including cache write and read multipliers; the 1.1x inference_geo rule and the note that multipliers stack; the confirmation that Sonnet 5's $2 and $10 is now standard and the September 1 increase will not occur
• Anthropic: tool use with prompt caching - Where cache_control goes on a toolset and why it is refused inside a member's configs; the tools, system, messages prefix order; the invalidation table behind the claim that changing a tool definition clears everything; the batch-action breakpoint rule and the defer_loading warning
• Anthropic: browser use tool - The 31 members, 27 on by default, and the four optional ones by name, plus Anthropic's stated security reason for keeping them off. Also the platform table showing browser use as first-party API only, with no Bedrock, Google Cloud, Foundry or Managed Agents support
• Anthropic: vision and image tokens - The 28-pixel patch formula, the 4,784-token and 2,576-pixel high-resolution caps against the standard tier's 1,568, the warning that toolset tool_result images are rejected rather than downscaled, and the stricter limit past 20 images per request. Our 1920x1080 figure of 2,691 and the 4,784 cap both reproduce Anthropic's own published examples exactly, which is how we checked the formula
• Anthropic: Claude Platform release notes - The August 19, 2026 GA entry, including the dropped beta header, batch actions, zoom on by default and per-member configs
• TokenCost: GPT-5.4 computer use, April 14 - The same question asked of OpenAI, where the driver was screenshot accumulation across turns rather than a fixed definition floor
• What this post does not know. We have not seen an invoice for either toolset, only Anthropic's published token counts, and every figure Anthropic gives is prefixed with "about", so treat the cent-level dollar figures as arithmetic on approximations rather than quotes. The combined cost of declaring both toolsets is our estimate, built by subtracting Opus 5's 286-token shared system prompt, not a number Anthropic publishes. We could find no other outlet that has costed the GA toolsets, which means nothing here has been checked against a second independent reading