Browser Use Is a New Claude Tool, Not a Renamed One

Anthropic’s browser use tool reached general availability on the Claude API on August 19, 2026 — and the most important thing to understand about it is what it is not. It is not computer use with a new name. browser_toolset_20260801 is a genuinely new client toolset for driving a browser your application hosts, and it shipped alongside — not instead of — computer use’s own move out of beta as computer_toolset_20260801.

The distinction is not branding trivia. The two toolsets read the world differently: browser use works with a page’s structure — its accessibility tree, elements, forms, and tabs — on top of screenshots, while computer use works with a whole desktop through screenshots and coordinates alone. They carry different member-tool counts (31 versus 17), different documented declaration overheads (about 6,600 versus about 4,500 input tokens), and sharply different platform availability. Pick the wrong one and you either give up the structured page interface or design against a platform where your toolset doesn’t exist.

This post covers the August 19 GA event itself, the verified action surface of the new toolset, a side-by-side decision table built from the two tool-reference pages, the cost mechanics Anthropic actually documents, and where the docs stay silent. Everything below is sourced from Anthropic’s Claude Platform release notes and the browser use and computer use tool-reference pages.

Anthropic’s August 19, 2026 release-notes entry is dense. Five capabilities reached general availability on the Claude Developer Platform in a single day: the new browser use tool, computer use, the Files API, Agent Skills with the Skills API, and the Admin API’s user-management endpoints for Claude Enterprise. Computer use, the Files API, the Skills API, and Admin API user management — plus the beta-header cleanup they all share — are covered in our companion post on the four platform betas that went GA the same day; this post stays on the one item that is genuinely new.

We found no separate launch blog post for browser use on anthropic.com/news. The primary record we can point to is the August 19 release-notes entry, which describes browser_toolset_20260801 as “a client toolset for driving a browser that your application hosts” — working inside a browser viewport rather than a whole desktop, reading the page itself and adding element references, form input, tab management, download reporting, and opt-in file upload on top of screenshot-and-click control. The same entry also shipped two adjacent Managed Agents items — domain allowlisting for web_search / web_fetch and memory stores for self-hosted sandboxes — which sit outside this post’s scope.

Because both toolsets carry the same _20260801 version suffix and went GA in the same release-notes entry, it is easy to assume browser use is computer use rebadged for the web. The documentation forecloses that reading directly. Browser use and computer use are separate tools with separate identifiers, separate member-tool tables, separate pricing-overhead figures, and separate compatibility rows. If you already run Anthropic’s computer use API, nothing about your integration was renamed out from under you.

The substantive difference is the interface contract. Computer use hands Claude a desktop and a screenshot; every action is a coordinate. Browser use hands Claude the page itself: a read_page call returns the accessibility tree as text with each element tagged with a reference like [ref_2], and subsequent clicks, hovers, and form inputs can target those references rather than pixel positions. Screenshots and viewport coordinates are still there — but as one channel among several, not the only one.

The other structural fact worth internalizing: browser use is a client toolset. Anthropic’s docs state, “Your application runs every call against its own browser automation; nothing runs on Anthropic’s side.” Claude decides what to do; your executor — your Playwright, CDP, or equivalent harness — actually does it. That keeps the browser, its session state, and its credentials entirely inside your infrastructure, and it is also why the security posture in Section 07 is your responsibility rather than the platform’s.

A single browser_toolset_20260801 entry in your tools array gives Claude 27 member tools by default; the full member tables enumerate 31 distinct actions once the four disabled-by-default members — javascript_exec, file_upload, read_console, and read_network — are counted. Those two numbers describe the same toolset: 27 is the enabled set, 31 is the full surface. Both counts come from the browser use tool documentation and its member-tool tables.

Three groups have no computer-use equivalent and explain why this toolset exists at all. Page reading: read_page returns the accessibility tree with element references (filterable to visible, interactive-only, or all elements), find looks elements up by natural-language description — “search field”, “add to cart button” — returning up to 20 matches, and get_page_text pulls page text without a screenshot. Forms and files: form_input sets a form element’s value directly — a string, number, or boolean, with booleans for checkboxes and an option’s value or visible text for selects — instead of simulating keystrokes. Tabs and downloads: tab state arrives as a first-class browser_state block capped at 100 tabs and 200 state changes per block (tab fields limited to 4,096 characters each), and downloads report a three-event lifecycle — download_started, download_completed with path and size when available, and download_failed.

The table below is assembled from the browser use and computer use reference pages and the August 19 release notes — including the two rows that decide most architectures: the documented declaration-overhead figures and the platform-availability asymmetry. Token counts are approximate and vendor-documented; treat them as declaration overhead, not a per-call fee. For how the pixel-first approach compares across vendors, see our computer-use comparison across Claude, OpenAI, and Gemini.

The member-tool counts are the concrete version of the abstract distinction. Browser use’s surface is larger because the tool has more to work with — references, forms, tabs, downloads — while computer use’s 17 members are what a screenshot-and-coordinates world affords. Neither count is a quality score; they describe different jobs.

There is no browser-use surcharge. Both toolsets follow standard tool-use pricing — you pay for the tokens the tool declarations, tool calls, and tool results add to each request. What Anthropic does document, unusually precisely, is the declaration overhead: adding browser_toolset_20260801 with its default members puts roughly 6,600 input tokens on every 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 — while enabling all four optional members adds about 880 more. Computer use’s equivalent figure is roughly 4,500 (about 4,520 on the same four models, about 4,590 on Sonnet 5).

Resist the urge to turn that pair into a percentage headline. The overhead is a fixed declaration cost, not a per-action fee, and total run cost is dominated by what comes back: screenshot and zoom images bill as standard vision input, while text results — accessibility trees, page text, console and network entries — bill as ordinary text tokens. Anthropic doesn’t publish an aggregate cost-per-task figure for either toolset, and the docs warn that toolset images are not auto-downscaled: an image over your model’s size limits — or over the stricter per-image limit that applies once a request holds more than 20 images — is rejected rather than resized. Browser use is also listed as eligible for Zero Data Retention, excluding Covered Models, which matters for regulated workloads.

The practical read: a browser-use agent that leans on read_page and get_page_text instead of screenshot-per-step can keep most of its tool results in cheap text tokens — an option a pixels-only tool structurally doesn’t have. That, more than the declaration gap, is the cost story worth modeling.

The platform asymmetry is the gotcha that will bite architecture decisions. Anthropic’s docs state it flatly: “Browser use is available on the Claude API only.” Computer use’s compatibility table, by contrast, lists the Claude API at GA plus Claude Platform on AWS, Amazon Bedrock, and Google Cloud, each tagged beta. If your agents live on Bedrock or Google Cloud, browser use is not an option there as of GA — you either route those workloads to the Claude API directly or stay on computer use’s beta track for your platform. The browser use tool documentation gives no timeline for it reaching the other platforms.

The versioning story, meanwhile, is deliberately boring — in the good sense. Nothing about August 19 forces a migration.

Anthropic’s computer use docs are explicit about the additive posture: “Existing computer_20251124 integrations keep working, and earlier tool versions remain available in beta for models and platforms that don’t support the toolset.” The migration guide for computer_20251124 spells out the mechanics. GA here means the new toolset format is the supported forward path — not that the old one stopped working on August 19. The same additive pattern holds across the rest of the day’s GA entry.

Because browser use is a client toolset, the security perimeter is entirely yours: the browser, its profile, its cookies, and its network access all live in your infrastructure. Anthropic’s browser use tool documentation is unusually direct about the headline risk in its security-considerations section — prompt injection from page content — rather than burying it in a generic disclaimer.

The docs pair that admission with six numbered precautions. Condensed: run the browser in a dedicated container or VM with a fresh, credential-free profile; enforce a network allowlist and re-check it after redirects; treat all page content as untrusted input, working from the accessibility tree and visible text rather than raw DOM; validate navigate URL schemes strictly, limited to http and https; leave javascript_exec and file_upload disabled unless a task genuinely needs them; and require human confirmation for consequential actions.

The two most dangerous members are opt-in for a reason. javascript_exec runs, per the docs, “with the page’s full privileges, including its cookies, storage, and same-origin requests” — arbitrary script in an authenticated context. file_upload carries an explicit precondition: enable it only when your executor resolves each path — following symlinks and .. segments — and accepts nothing outside a dedicated, allowlisted upload directory holding only files meant for the task. If your isolation story is thin, the sandboxing patterns from sandboxed browser agents inside Claude Code translate directly to an API-hosted executor.

The decision is cleaner than most tool-choice questions because the two toolsets barely overlap. The question is what your agent touches: a page, a desktop, or a platform where only one of them exists.

Know what the docs don’t tell you. As of GA, Anthropic’s pages are silent on browser-use-specific rate limits, on headless-versus- headed browser behavior, and on any per-session cost ceiling — and browser use “isn’t currently available in Claude Managed Agents.” For a team about to build, those silences are findings: budget a spike to measure your own task costs rather than expecting a published envelope. It’s also worth saying plainly what this post is built on: Anthropic’s August 19 release notes and the two tool-reference pages, read directly. We did not locate third-party coverage to cross-check them against, so treat every figure here as vendor-documented.

The trend reading: Anthropic keeps moving agent capability out of monolithic betas and into versioned, member-configurable toolsets — the same _toolset_ format now carries browser use, computer use, and Managed Agents’ tool configs. A structured, reference-based browser interface also puts API-level Claude in the same territory that browser automation frameworks like Playwright and Stagehand have occupied — except the interface contract is now defined by the model vendor, not the framework. Looking forward, we’d expect the platform asymmetry to narrow — but that is our projection, not something Anthropic has stated, and the docs commit to nothing beyond Claude API only. Teams already running browser agents for landing-page QA in paid media should shortlist this toolset now; if you want help scoping where an app-hosted browser agent pays for itself, our AI transformation engagements start with exactly that evaluation.