Ask which computer-use tool Claude Opus 5.5 supports and Anthropic's documentation gives two answers depending on where you run it — and the two tools do not have the same screenshot ceiling, so one model string buys two agents with different grounding accuracy and different cost per step. The portability unit for a GUI agent is not the model name. It is the pair (model, tool version), and nothing in your config makes that visible.
At a glance
Two tool generations are live at once, and the split runs along platforms rather than models. Every row below is from the computer-use tool reference.
| Property | computer_toolset_20260801 | computer_20251124 |
|---|---|---|
| Shape in the request | One toolset entry that expands into 17 named members | A single tool version |
| Beta header | None needed | Required |
| Screenshot ceiling | 2,576px long edge, 4,784 visual tokens (≈3.75 MP) | 1,568px long edge, ≈1.15 MP |
| Status: Claude API, Google-managed Claude on Google Cloud | GA, and the only option on Claude 5.5 and later | Rejected with an error on Claude 5.5 and later |
| Status: Bedrock, Claude Platform on AWS, Microsoft Foundry | Not available | Beta, and the only option |
| Models that support only this | — | Claude Opus 4.7, Opus 4.6, Sonnet 4.6, Opus 4.5 |
The sentence that does the damage
Two statements in that reference are individually unremarkable and jointly a portability problem. The first: “On the Claude API and Claude Models on Google Cloud (Google managed), Claude 5.5 and later models support computer use only through the computer_toolset_20260801 toolset and return an error for the earlier computer_20251124 and computer_20250124 tool versions.” The second: “On Amazon Bedrock, Claude Opus 5.5, Claude Sonnet 5.5, and Claude Haiku 5.5 accept the earlier computer_20251124 tool version as Claude Opus 5 and Claude Sonnet 5 do.”
Put them together and the question “which computer tool does Claude Opus 5.5 use?” has no answer. It has two, selected by the hosting platform, and the request that works against one is a 400 against the other. This is not a deprecation window where old and new coexist on the same endpoint and you migrate at your own pace. It is a fork: the Claude API has moved entirely to the toolset and refuses the old version, while three partner platforms carry only the old version and cannot accept the new one.
The older models are forked the other way, and that closes the escape hatch. Claude Opus 4.7, Opus 4.6, Sonnet 4.6 and Opus 4.5 “support computer use only through the earlier computer_20251124 tool version, which requires a beta header.” So on the Claude API there is no model that accepts both tool versions. There is no overlap to A/B through.
Where the two tools actually differ
If the difference were only a version string this would be paperwork. It is not, and the gap that matters most is the one a benchmark would pick up. The toolset “accept[s] up to 2,576 pixels on the long edge and 4,784 visual tokens total (⌈width / 28⌉ × ⌈height / 28⌉, approximately 3.75 megapixels)”; the earlier tool versions accept “up to 1,568 pixels on the long edge and approximately 1.15 megapixels total.” Spatial grounding — producing the pixel coordinate of the button rather than naming it — is the dominant error class in GUI agents, and it is directly sensitive to how many pixels the model got to look at. A 3.3× difference in available detail is not a config nuance; it is a different accuracy regime on small targets.
The toolset also adds the member that reads like an answer to that error class. zoom takes a region of [x0, y0, x1, y1] and re-captures it at full resolution, which is the API-level admission that the binding constraint was never screen size but resolution at the point of the click. The docs say so from the other direction too, in the troubleshooting advice: if clicks miss, enable zoom, use positional prompts, or break the task into smaller steps. A harness written against computer_20251124 has no such call to make.
Two smaller differences will also bite a straight port. The toolset arrives as one {"type": "computer_toolset_20260801"} entry whose tool_use blocks carry "toolset_name": "computer" and a member name, so result-routing code keyed on a flat tool name needs rewriting rather than renaming. And the old version requires a beta header that the new one does not — which means a config that merely swaps the version string produces a request that is wrong in two places at once.
Why this is an evaluation problem before it is a migration problem
The practical cost of the fork is that it removes the only controlled comparison you had. Upgrading a GUI agent normally means changing one thing and re-running your suite: new model, same tool, same screenshots, same step budget. Here the model and the tool move together, and the tool brings a different observation space with it. A score that improves after the upgrade cannot be attributed, because the model changed, the available resolution changed, and the action set changed in the same commit.
That matters more for computer use than for text agents, because GUI benchmark numbers are already fragile in exactly this dimension. OSWorld-class results are reported at different step limits, different screen resolutions and different tool permissions, which is why third-party trackers disagree about the same system on the same date. A number quoted without its step limit and its screenshot resolution is not a measurement of the model. Now the screenshot resolution is partly a function of which cloud you bought the model through.
The honest version of a multi-platform deployment is therefore two eval runs, not one. If you serve the Claude API in one region and Bedrock in another, you are operating two agents that share a name — and the one on the older tool is the one whose click accuracy you have not measured, because your suite ran against the frame size the other one gets.
Record the tool version next to the model string in every trace, and key your eval results on the pair. A trace that says claude-opus-5-5 and nothing else cannot tell you, six weeks later, whether a regression in click accuracy came from the model, the frame size or the host — and on this surface those are three different things that your config calls one.
What to do this week
Four steps, in the order that costs least.
- Find out which tool you are actually sending. Grep your harness for
computer_and check it against the platform you are hitting. A beta header still present after a move to the Claude API is the common shape of this bug, and it fails loudly; the quieter one is a Bedrock deployment you believed had been upgraded with everything else. - Pin the screenshot resolution explicitly rather than inheriting the display's. The docs recommend 1024×768 or 1280×720 for desktop work and 1280×800 or 1366×768 for web, and warn against going above 1920×1080. Those recommendations sit well under the toolset's own ceiling, which is the clue that the ceiling is headroom for
zoomrather than a new default frame. - Re-run your grounding evals per platform, not per model. One run per (model, tool version) pair. If you only have budget for one, run the older tool, because that is the configuration your existing numbers do not describe.
- Treat a platform migration as a harness change. Result routing, the action vocabulary, the coordinate scaling you apply when you downscale a screenshot, and the verification step after each action all touch the tool contract. The docs are blunt about why that last one matters: “Claude sometimes acts as if its actions succeeded without explicitly checking their results.”
The general lesson outruns computer use. A model name is a decreasingly complete description of what you deployed: effort settings, thinking modes, tool versions and now observation ceilings all vary underneath it, and several of them vary by host. The fix is not vigilance but identity — log the full tuple that determines behaviour, and let your eval results be keyed on the same thing your runtime is keyed on. See prompt portability for the same failure in the text surface, and unpinned vendor defaults for what happens when a value you never set changes under you.
FAQ
Can I use the same computer-use code on the Claude API and on Amazon Bedrock?
Not without a branch. The Claude API carries computer_toolset_20260801 and returns an error for computer_20251124 on Claude 5.5 and later models; Bedrock, Claude Platform on AWS and Microsoft Foundry carry only the earlier beta tool versions. The request shape, the beta header and the screenshot limits all differ.
Is the new toolset's higher resolution ceiling a reason to send bigger screenshots?
Not by default. The documented recommendations stay at 1024×768 or 1280×720 for desktop tasks, and the ceiling is denominated in visual tokens (⌈width / 28⌉ × ⌈height / 28⌉, up to 4,784), so a bigger frame is a bigger bill on every step of the loop. The targeted way to spend the headroom is zoom on the region you are about to click.
Which model should I use for click accuracy?
The reference compares the earlier tool's models directly: Claude Sonnet 4.6 is “more mechanically precise at clicking than Claude Opus 4.6,” and Claude Opus 4.7 is “roughly comparable to Sonnet 4.6.” That is a reminder that on this surface the strongest reasoning model is not automatically the best actuator, and it is one more reason to measure per configuration rather than inherit a ranking.
Does this affect agents that drive a browser rather than a desktop?
It affects any agent whose observations are screenshots, because the ceiling and the action set are properties of the tool rather than of the target. An agent working through the DOM or an accessibility tree is insulated from the frame-size difference, which is one of the arguments for hybrid grounding in the first place.
Will the platforms converge?
The reference says earlier tool versions “remain available in beta for models and platforms that don't support the toolset,” which describes the present rather than a schedule. Build for the fork existing, and keep the tool version in your configuration as a first-class value rather than a constant.
Further reading
On this wiki:
- Computer-Use & GUI Agents — grounding, the screenshot loop, and the reliability tax.
- The Per-Step Cost of Looking — what a screenshot costs once the loop re-sends it.
- GUI Grounding — why knowing what to click and knowing where it is are different skills.
- Prompt Portability — the same hidden-variable problem on the text surface.
- Unpinned Vendor Defaults — behaviour that changes without a deploy of yours.
- Evaluating Coding Agents — keying results on a configuration rather than a name.