Spokes.wiki Search About
Tech Article T2 stable source ↗ source url
Published
Created
Updated

Anthropic's new browser tool doesn't actually run a browser (The New Stack)

amanda-caswell for the-new-stack, 21 Aug 2026, on claude-browser-use — the Browser Use toolset anthropic announced the day before, alongside general availability for Computer Use, the Skills API and the Files API.

The headline is the finding. Browser Use gives Claude 27 operations it can ask for and executes none of them. The developer supplies the browser, runs each action, holds the session open between turns and returns a result Claude can read. What Anthropic ships is a protocol and a tool definition.

What the piece establishes

  • Accessibility tree, not pixels. read_page returns a text rendering of the tree with elements tagged ref_3-style; Claude acts on the reference rather than computing x: 640, y: 320. Toolset id browser_toolset_20260801, Claude API only.
  • Refs rot silently. Navigation or a big enough page change invalidates a reference, and "the API will not catch that on its own" — detection, rejection and the forced re-read are the executor's responsibility.
  • Batched actions. Several tool_use blocks per turn, executed in order, results returned together. Fewer model calls, and Anthropic's claim is lower latency and cost as tasks grow from a handful of interactions to hundreds.
  • ~6,600 input tokens of overhead for the default toolset, per Anthropic's pricing documentation, before screenshots or trees or results. Operations can be disabled to shrink it.
  • The hosting line. Skills API skills run in Anthropic's sandbox and Files API documents live on Anthropic's side; browser sessions, downloads and uploads stay with the developer. Browser Use is also not available in claude-managed-agents.
  • Containment advice, not containment. Isolated container or VM, minimal access, JavaScript and file uploads off unless needed — because Claude-generated code runs with the page's privileges.

Where it beats a rewrite of the announcement

Three passages do work a vendor post would not.

The ordering argument on batching: "the browser still has to carry them out in order because each one depends on what happened before it." Click, fill, submit — if the click fails, the executor cannot skip to the fill, because everything after it was planned against a page state that never existed. The efficiency win and the failure mode come from the same property.

The approval consequence, which outlives this particular tool: a batch can open with a click nobody would gate and close on something that needs a person, so the check has to happen action by action inside the loop. Per-action approval was already the design with the bad number attached here (agent-permission-model); batching makes the boundary harder to draw without making the control any better.

The prior-art comparison, done honestly. Playwright's ARIA snapshots and role locators, Microsoft's Playwright MCP server with its referenced accessibility snapshots, Puppeteer's Accessibility.snapshot() — the concepts line up, "but the protocols do not." Playwright MCP speaks MCP and Browser Use speaks Anthropic's own client-toolset protocol, so anyone bridging the two writes an adapter in both directions.

It also clears up a name collision the corpus already had exposure to: the unrelated open-source browser-use project drives Chromium over the Chrome DevTools Protocol and has nothing to do with Anthropic's tool. Two pages here, deliberately.

Weaknesses

T2, not T1. Trade reporting on a vendor release, no independent testing, no benchmark, nobody quoted outside the documentation. Every number in it — the operation count, the token overhead, the toolset id — is Anthropic's own, restated. The 6,600-token figure is the only one with a citation, and it points at the pricing docs rather than at measurement.

Disclosed conflict: the page carries "TNS owner Insight Partners is an investor in Anthropic." Stated openly, which is the right handling, and still a reason to treat the framing as friendly.

The article gives no launch pricing beyond the token overhead, no availability tiers, no rate limits, and no comparison of what a Browser Use turn costs against a Computer Use turn on the same task — which is the number that would settle whether the accessibility tree pays for itself the way mobilerun says it does on a phone.

claude-browser-use · text-first-agent-design · agent-permission-model · claude-managed-agents · browser-use · mobilerun · webmcp · anthropic · the-new-stack · amanda-caswell