Anthropic supplies the browser toolset. Your application still runs the browser.

Anthropic made computer use, the Skills API, and the Files API generally available on the Claude Platform on August 20, 2026, and introduced a browser use tool for web applications. The browser tool can combine page structure with screenshots, target page elements by reference, and return several actions in one model turn.

The implementation boundary matters more than the feature list. Anthropic defines the tools and the message protocol, but its documentation says your application runs every call against its own browser automation. This article explains what the launch changes, what the customer-run executor still has to do, and when a browser agent is the wrong automation choice.

What did Anthropic make generally available?

Anthropic's launch announcement says computer use, the Skills API, and the Files API are generally available on the Claude Platform. The updated computer-use tool can return several actions in one turn instead of requiring a model call for each action. Computer use can also be used for HIPAA-regulated workloads under Anthropic's business associate agreement, subject to the customer's complete compliance design.

Browser use is the new component. Unlike desktop-oriented computer use, which works from screenshots and coordinates, the browser use documentation says the browser tool can use both pixels and page structure: accessibility information, elements, forms, tabs, and references returned by a page-reading action. A link can therefore be selected by a reference produced from the current page rather than only by its screen position.

That should make many web-only tasks easier to express and less dependent on a fixed layout. It does not prove that a task will complete correctly when labels are ambiguous, a page changes, a session expires, or untrusted content tries to redirect the agent.

The browser toolset is not a hosted browser

Anthropic describes browser use as a client toolset. Adding one versioned toolset entry to a Messages API request exposes 27 member tools by default, including navigation, page reading, clicking, typing, and screenshots. Four more capabilities—JavaScript execution, file upload, console reading, and network reading—are optional.

The model chooses calls, but the customer's executor performs them. Your application has to maintain the browser session, translate each member call into browser automation, collect the resulting page state or error, and return one matched result for every call. Anthropic does not run that browser for you, and the tool is not currently available in Claude Managed Agents.

This division leaves important decisions outside the model request:

• which domains the browser can reach;
• which test or production account it uses;
• where credentials and downloaded files live;
• whether optional JavaScript, console, network, and upload capabilities are enabled;
• which actions require approval; and
• which evidence proves the task completed.

A platform team can change those controls without changing the prompt. That is useful separation, provided the executor denies capabilities the workflow does not need rather than implementing every available member because the toolset supports it.

Batch actions make the halt rule part of your code

Several calls in one model turn can remove round trips, but they are not a license to run calls concurrently. Anthropic's documentation says the executor must process them sequentially because later actions usually depend on earlier results. Every call needs a result before the next API request is accepted.

The failure rule is equally specific. If an early call fails, the executor should return an error for that call and apply the documented halt behavior to later calls in the same batch. A sequence such as click, type, and submit cannot safely continue with type and submit after the click failed or landed on an unexpected page.

This is an application responsibility, not a model-quality setting. Test a failed navigation, a missing element, an expired login, a blocked download, and a changed form before production. For each case, verify that later calls do not run, the run ends in a legible state, and a person can tell what did and did not happen.

Live pages expand the trust boundary

A browser agent reads content supplied by websites and can take actions with real effects. Anthropic explicitly treats page content as untrusted input. The executor should do the same.

Start with a domain allowlist and a dedicated account that has only the permissions the workflow needs. Block pop-ups or navigation outside the approved boundary. Keep irreversible submissions, account changes, payments, and destructive actions behind a separate confirmation or human review step. A structural page reference can make targeting more reliable; it does not make the referenced action authorized.

Returned data crosses another boundary. Screenshots, page text, accessibility trees, and tab state sent back as tool results become content in the API request. Browser sessions, downloads, and uploaded files remain in the customer's environment, but the material returned to Claude follows the applicable API retention arrangement. Map both paths rather than describing the whole workflow as either "local" or "in the API."

The adjacent Skills and Files releases add more state, not less. The Skills documentation says API skills run in a code-execution environment without network access and do not automatically sync across Claude surfaces. The Files API documentation says files are workspace-scoped, immutable after upload, and referenceable by any API key in the same workspace. Pin the skill version, record file IDs and deletion rules, and do not assume a browser download and a Files API object share one lifecycle.

Browser use has a visible token floor

The browser capability is not costless before the first page is read. Anthropic currently estimates that declaring the default browser toolset adds about 6,600 input tokens to a request, with optional members adding more and disabled members reducing the definition. Screenshots and page text returned during the run add further input.

Treat the response's recorded usage as the authoritative measurement for your request. Compare complete task cost and completion time, not only the number of model turns. Fewer turns can still carry substantial tool definitions, screenshots, and page structures.

That cost supports another reason to choose the narrowest mechanism. If the job only needs public information, web search or fetch is lighter. If a stable API exposes the action, use the API rather than operating its web form. Choose browser use when the task genuinely needs to read or act inside a JavaScript web application. Choose computer use when the workflow leaves the browser and needs a whole desktop.

What should a first production test prove?

Use a representative task with a test account and a reversible outcome. Measure whether the executor stays on approved domains, targets the intended element, processes calls in order, stops after failure, and produces a verifiable receipt. Include at least one normal run and the failure cases most likely on that site.

Review the completion evidence separately from the model's final sentence. A confirmation number, downloaded file, changed record read back from the system, or expected status in an independent API can establish success. "Done" cannot.

Also record model and toolset versions, enabled members, browser and executor versions, account scope, destination domains, skill version if used, file lifecycle, total input and output usage, elapsed time, and the owner who can disable the workflow. Re-run the test when any of those dependencies or the target site changes.

Use browser use when you are ready to own execution

Anthropic's launch gives developers a richer, versioned language for web action and reduces the need to locate everything by coordinates. It does not transfer browser operations to Anthropic. The customer still runs the session, executes each action, controls credentials and network reach, stops failed batches, and proves the final state.

That boundary is the buying and implementation decision. Use browser use when a valuable web-only workflow lacks a suitable API and your team can operate a constrained executor. Prefer a direct API, read-only web tool, or manual path when it is simpler and easier to verify.

If you want to test that choice against one real process, BaristaLabs can review one browser workflow and separate model decisions from executor permissions, failure handling, and completion evidence.

Sources

• Anthropic, “Build production agents with computer use, the Skills API, and the Files API,” August 20, 2026
• Anthropic, browser use tool documentation
• Anthropic, Agent Skills documentation
• Anthropic, Files API documentation

Anthropic controls the product behavior, availability, compatibility, usage estimates, and limits attributed to its announcement and documentation. BaristaLabs supplies the implementation interpretation and recommended tests.