Computer-use agents control a graphical environment through observations and actions, but a tool name is not a promise of compatibility. Applications built for one Anthropic computer-use schema may fail when a later toolset changes the shape of calls, supported actions, or where the executor runs. The safe unit of migration is the entire tool contract, not a model-name substitution.
What changed in the contract
In the earlier tool interface, an application declares a named computer tool with display dimensions and receives an action in a structured input. In the newer toolset, members such as screenshot, click and key are exposed individually, and the executor dispatches by both the toolset and member name. That difference affects validation, logs and replay. Build an adapter with explicit version selection, supported-action negotiation and an exact correspondence table; never reinterpret an unknown action as a similarly named permitted operation.
A migration that can be rehearsed
Begin with a recorded, non-sensitive workflow such as opening an internal test page and copying a displayed identifier. Capture the screenshots, action payloads and resulting browser state under the old integration. Run the same task against the candidate toolset in a fresh sandbox. Compare action envelopes, coordinate scaling, screenshot limits, error responses, and whether multiple actions arrive in a single model turn. If the executor supports only one operation at a time, reject batches rather than silently dropping actions.
Trust boundary and user consent
The model can propose clicking or typing, but application code owns the desktop, credential vault, filesystem and outgoing network. Give each session an isolated display and browser profile, restrict file mounts and destinations, and preserve human control for sign-in, purchase, external messages or sensitive record changes. Screenshot text and webpage content are untrusted instructions, even when they resemble policy notices. Include a human-visible target and operation summary rather than relying on a hidden reasoning trace.
Failure conditions that matter
A screenshot may be captured before the interface finishes rendering. A click at yesterday’s coordinates may hit a different button after a layout change. A modal may block later actions even though the model reports progress. Introduce observation checkpoints after navigation and state-changing clicks, impose tool-call and wall-time ceilings, and require a read-back of the application state before saying an operation succeeded. Abort when the surface requires CAPTCHA circumvention or an unsupported authentication bypass.
Evaluation and adoption decision
Evaluate action correctness, wrong-target clicks, secret exposure attempts, task completion by external state, and recovery after stale screenshots. Report results separately for each toolset revision, model, browser and viewport. Use a browser-specific API when the job has stable machine-readable controls; use full-desktop operation only when the required software cannot be reached through a narrower, auditable interface. Commercial terms, model availability and region limits remain deliberately unspecified without a dated entitlement check.
Choose between desktop control and browser tools
If your job requires a native desktop client with no accessible API, a full computer tool may be warranted; for an ordinary website, prefer the least powerful browser or service interface that can complete the request. Ask the executor team whether it can pin screenshots to a viewport, terminate a session immediately, mask sensitive windows and recover after a partial UI action. Do not adopt a new toolset solely because a newer model supports it.
Production acceptance and review test
Before changing a production tool version, run an end-to-end test with a disabled network, an expired login, two monitors or shifted window geometry, and a site showing an unexpected high-risk dialog. Each test should produce a trace of action proposals, actually executed actions, observed UI state and the exact reason any action was blocked. Compare traces with the previous version and require a human review for differences that affect approval boundaries.
Scope, version and availability
Features documented by a current vendor page are not assumed to have existed in earlier releases. Where a historical launch date is provided, it is supported by a dated first-party publication. Exact subscription tier, market availability, quotas, API billing, licensing permissions and deployment regions are not asserted without a directly applicable record. This is researched editorial guidance rather than a claim of independent hands-on testing, deployed operation or statutory certification.
Sources and Further Reading
- Anthropic — Computer use tool (source reviewed 2026-10-25)
- Anthropic — Developing a computer use model (source reviewed 2026-10-25)