Claude has two separate client toolsets for acting on a screen, and mixing them up leads to the wrong architecture. The computer use toolset drives an entire desktop through screenshots and pixel coordinates, while the browser use toolset drives a single webpage through an accessibility tree and element references. One works across any application you can screenshot; the other only works inside a browser your own application runs and controls.
Both ship as Anthropic-defined “toolsets” — a single tools entry that expands into a whole family of member tools Claude can call. Anthropic’s own documentation describes each one in isolation, but it doesn’t put them side by side, so most of what follows is read straight from the computer-use-tool and browser-use-tool reference pages on platform.claude.com and lined up into one table.
What each toolset actually sees
The computer use toolset only ever sees pixels. Every turn, your application sends a screenshot, Claude returns click, type, or scroll instructions anchored to coordinates in that image, and your application executes them against the real display. Claude never gets the DOM, never gets an element tree, and never knows an app is a browser at all — it is driving a desktop.
The browser use toolset sees more than pixels. Alongside screenshots, it exposes read_page (an accessibility tree with stable element references like ref_2), find (a natural-language element search), and get_page_text. Claude is told to prefer a ref_id over a raw coordinate whenever one is available, and only falls back to viewport-pixel coordinates when the page gives it nothing stable to point at — a canvas-based app, a virtualized list, or a view that re-renders on every scroll.
The two toolsets, lined up
| Dimension | Computer use toolset | Browser use toolset |
|---|---|---|
| Scope | Whole desktop, any application | Content inside one webpage |
| What Claude observes | Screenshots only | Accessibility tree, element refs, tabs, forms, plus screenshots |
| How Claude targets elements | Pixel coordinates | Element refs first, viewport-pixel coordinates as fallback |
| Member tools included | 17 | 27 by default, 31 with optional members enabled |
| Who runs the automation | Whatever you point the screenshot loop at (VM, container, real desktop) | A browser your application runs and executes every call against |
| Default added input tokens | Not stated as a flat figure; roughly 1,000–1,800 tokens per screenshot | About 6,600 input tokens per request for the default toolset, plus image/text results |
| Image size limit (5.x models) | Up to 2,576 px long edge, ~3.75 MP (4,784 visual tokens) | Same limit; oversized screenshots are rejected, not downscaled, by either toolset |
| Diagnostics | Not offered | read_console and read_network, both disabled by default |
| Not available on | Claude Managed Agents | Claude Managed Agents |
Two things in that table are easy to miss on a first read of the docs. First, neither toolset downscales an oversized screenshot for you — both reject it, so the resizing math (scale to fit, then divide Claude’s returned coordinates by the same scale factor) is something your code has to do either way. Second, the model lists are close to identical: Opus 4.8, Opus 5, Opus 5.5, Sonnet 5, Sonnet 5.5, Haiku 5.5, Fable 5/5.1, and Mythos 5/5.1 all accept both toolsets on the Claude API and Google Cloud. The choice between them is architectural, not a question of which models support which tool.
A minimal browser use call
Adding the browser toolset to a request is a single entry in tools, with no beta header required for the current version:
response = client.messages.create(
model="claude-opus-5-5",
max_tokens=2048,
tools=[{"type": "browser_toolset_20260801"}],
messages=[{"role": "user", "content": "Open example.com/docs and tell me how to get started."}],
)Claude’s reply comes back as tool_use blocks tagged "toolset_name": "browser", calling members such as navigate and read_page. Your executor runs each one against its own browser and returns matching tool_result blocks. Nothing executes on Anthropic’s infrastructure — the docs are explicit that this toolset only describes a contract between Claude and whatever browser automation your application already runs, which is exactly the role filled by reviewing an MCP server’s permissions before you let a model drive a tool with side effects: the toolset defines what Claude can ask for, not what your code is obligated to allow.
Where each one breaks in practice
- Coordinate drift. Computer use coordinates are only as good as the screenshot dimensions you declared. A macOS screenshot taken at a device pixel ratio of 2 will be double the size you think it is, and every click lands offset until you correct for it.
- Stale references. Browser use refs like
ref_2go stale the moment a tab navigates or its DOM changes materially. The fix the docs describe is to return an error so Claude re-reads the page withread_page, rather than retrying the same ref. - Latency. Both toolsets carry the same warning: round-tripping a screenshot or a page read is too slow for a human sitting in the loop waiting on each click. Anthropic positions both as better suited to background or automated tasks than live, interactive sessions.
- Untrusted content. A webpage or a desktop screen can contain text aimed at the model rather than the user — the classic prompt-injection surface covered in a walkthrough of the OWASP LLM Top 10. Anthropic runs its own injection classifiers automatically on the official
computer_toolset_20260801actions and offers the same scanning for the browser toolset’s page content by default, but a custom tool definition that reimplements either loop does not get that protection unless you build it yourself.
Which one to reach for
If the task lives entirely inside a webpage — filling a form, reading a dashboard, clicking through a checkout flow you don’t control — the browser use toolset is the better fit. The accessibility tree survives page updates far better than coordinates do, and features like find let Claude locate an element by description instead of guessing where it sits on screen. Save the computer use toolset for tasks that cross application boundaries: switching from a spreadsheet to an email client, or driving a desktop app that has no web equivalent at all. Neither one is a drop-in replacement for the kind of agent loop that calls ordinary function tools — both exist specifically for the cases where no API exists and a screen is the only interface left. Picture a task like “compare the shipping cost on three competitor checkout pages”: every step happens inside a browser tab, so the browser toolset’s read_page and find will get through it in far fewer turns than screenshot-and-guess coordinates would. Compare that to “export this report from the desktop app, then attach it to a new email in the desktop mail client” — two unrelated applications with no shared DOM, which is squarely a computer use job. And because both toolsets add real, non-trivial token overhead on every call, it’s worth weighing that cost the same way you would weigh any other provider’s rate limits and pricing tiers before committing an architecture to one or the other.
The full action list, side by side
The computer use toolset’s 17 members cover exactly what a human does with a mouse and keyboard: screenshot, zoom (a full-resolution crop of one region), the click family (left_click, right_click, middle_click, double_click, triple_click), left_click_drag, mouse_move, the low-level left_mouse_down / left_mouse_up pair for drags the drag action can’t express, cursor_position, scroll, type, key (with a repeat count up to 100), hold_key (up to 300 seconds), and wait. Every member is enabled by default; you withhold one your environment can’t support through a configs block rather than by omitting it from the tool definition.
The browser use toolset’s 27 default members group into four jobs instead of one. Navigation and capture (navigate, screenshot, zoom) move Claude around the page. Pointer and keyboard actions mirror the computer toolset’s list almost exactly, plus a scroll_to member that jumps straight to an element reference instead of scrolling blindly. Page reading (read_page, find, get_page_text) is what the computer toolset has no equivalent for at all. And tab management (new_tab, list_tabs, switch_tab, close_tab) only makes sense once “the desktop” has been narrowed down to “a browser,” which is the whole premise of the toolset. Four more members — form_input, file_upload, read_console, and read_network — ship disabled by default, so a page that only needs to read and click never pays for them.
Sandboxing, confirmation, and what Anthropic actually recommends
Both reference pages converge on the same operating posture, worth stating plainly rather than paraphrasing into something softer: run either toolset inside an isolated VM or container, restrict the domains or applications it can reach, keep credentials away from the model where the task allows it, and require a human confirmation step before any action that can’t be undone — a purchase, a send, a delete. For the browser toolset specifically, Anthropic also recommends leaving javascript_exec and file_upload disabled unless a task genuinely needs them, since both widen what a page’s own injected content could get Claude to do. The browser toolset is also ZDR (zero data retention) eligible, with exclusions for a few covered models, and the browser session itself never leaves your environment — useful context if a security review is the reason you’re choosing between the two in the first place.
Sources: Claude Platform Docs — Computer use tool, Claude Platform Docs — Browser use tool, and Best practices for computer and browser use with Claude.
