Cutting Token Cost in Claude Browser & Computer Use

Computer use has a cost problem that chat never had: screenshots. Every observation an agent takes of a screen is an image, every image is thousands of tokens, and a single web task can run dozens of steps. Multiply that by retries, by multi-agent fan-out, and by a long system prompt re-sent on every turn, and a workflow that looked cheap in a demo becomes alarming on a production bill. The good news is that nearly all of the waste is structural, which means it is fixable. This post walks through where the tokens actually go in a Claude computer-use run and the concrete levers that bring cost and latency down without dumbing the agent down.

Where the tokens actually go

Before optimizing, measure. In a typical browser-use loop, the largest cost is not the model's reasoning — it is the repeated input. On every single turn, the agent re-sends the full system prompt, the tool definitions, the entire conversation so far, and the latest screenshot. As the run grows, that input balloons, and because you pay for input tokens on every step, a long run pays for its early context over and over. Screenshots compound the problem: a full-resolution screen can dominate the token count of a turn all by itself.

The practical takeaway is that cost in computer use is driven by how much context you re-send per step and how many steps you take, far more than by the cleverness of any single response. Two runs that produce identical results can differ in cost by an order of magnitude depending on caching, image discipline, and step count. So the optimization targets are clear: cache the stable parts, shrink the images, take fewer steps, and route easy work to cheaper models.

Prompt caching: the single biggest lever

Prompt caching is the highest-leverage change you can make. The idea is simple: the stable prefix of your prompt — system instructions, tool definitions, durable context — does not change between turns, so the model can cache it and charge you a small fraction of the price to reuse it instead of reprocessing it. In a long agent loop where that prefix is re-sent dozens of times, caching the prefix turns a linear cost into something far closer to flat.

To benefit, order your context from most stable to least stable: put the system prompt and tool definitions first, then durable task context, then the volatile turn-by-turn history and the latest screenshot last. The cacheable boundary sits at the point where content stops changing. If you interleave a constantly-changing timestamp or a per-turn note into your system prompt, you defeat the cache for everything after it. Keep the prefix byte-for-byte identical across turns and you will see input cost on cached portions drop dramatically.

flowchart TD
  A["Turn begins"] --> B["Stable prefix: system + tools"]
  B --> C{"Prefix unchanged from last turn?"}
  C -->|Yes| D["Read from cache (cheap)"]
  C -->|No| E["Reprocess prefix (full price)"]
  D --> F["Append latest screenshot + action result"]
  E --> F
  F --> G["Model decides next action"]
  G --> H["Trim old screenshots from history"]
  H --> A

Screenshot discipline

Images are the second lever and often the easiest win. Three habits help. First, do not keep every screenshot in context forever — the agent rarely needs a screen from twelve steps ago, so trim old images out of history and keep only the most recent one or two. The text record of what happened can stay; the pixels usually cannot earn their token cost. Second, downscale screenshots to the smallest resolution at which the model can still read the UI reliably; full retina captures are almost always overkill. Third, prefer structured observations over pixels when you can get them — a compact text description of the relevant DOM, or accessibility-tree data, is dramatically cheaper than an image and often more reliable for the model to act on.

A good rule of thumb: take a screenshot when the agent genuinely needs to see the screen to decide, not reflexively after every action. Many actions have predictable results that text can confirm. Reserve the expensive visual observation for moments of real uncertainty.

Batching and fewer, bigger steps

Step count is a direct multiplier on cost, so the fewer turns a task takes, the cheaper it is. One way to cut steps is to let the model plan a short sequence of actions when the path is predictable, rather than round-tripping a screenshot after every micro-action. Another is batching at the workload level: if you have a hundred similar pages to process, structure the work so shared setup and instructions are paid for once rather than re-established for each item.

Be deliberate about multi-agent fan-out here. Spawning several subagents in parallel is powerful for genuinely independent work, but it multiplies token usage several times over because each subagent carries its own context. Reach for parallelism when the latency win justifies the spend, and keep sequential single-agent flows for tasks that are cheap and quick. The orchestration pattern is a cost decision, not just an architecture decision.

Route the easy work to cheaper models

Not every step needs your most capable model. The Claude family spans Opus for the hardest reasoning, Sonnet for balanced work, and Haiku for fast, cheap, high-volume steps. A smart computer-use system routes by difficulty: use a smaller model for routine navigation, extraction, and confirmation, and escalate to a larger model only when the agent hits genuine ambiguity or a hard planning decision. You can implement this as a tiered loop where the cheap model handles the common path and hands off when it is uncertain.

Model routing pairs beautifully with caching and screenshot discipline: the cheap model on a small image with a cached prefix is the lowest-cost possible step, and you only pay for the expensive combination when the task truly demands it. Measured together, these four levers routinely turn a runaway computer-use bill into something predictable.

Frequently asked questions

What is prompt caching and why does it matter for agents?

Prompt caching lets the model reuse the processing of a stable prompt prefix — system instructions, tool definitions, durable context — at a small fraction of the normal input price instead of reprocessing it every turn. In an agent loop that re-sends that prefix dozens of times, it is the single biggest cost saver.

How do I reduce screenshot token costs?

Keep only the most recent screenshots in context and trim older ones, downscale images to the smallest resolution the model can still read, take a screenshot only when the agent needs to see the screen to decide, and prefer structured DOM or accessibility data over pixels when available.

Does multi-agent parallelism save money?

It saves wall-clock time, not tokens. Each subagent carries its own context, so a multi-agent run typically uses several times more tokens than a single-agent run. Use it when the latency win is worth the spend, and keep cheap, quick tasks single-agent.

Which Claude model should browser agents use?

Route by difficulty. Use Haiku or Sonnet for routine navigation, extraction, and confirmation, and escalate to Opus only for hard planning or genuine ambiguity. Tiered routing keeps the common path cheap and reserves the expensive model for the moments that need it.

Bringing efficient agents to your phone lines

Caching the stable prefix, trimming what the agent re-sends, and routing easy turns to cheaper models are exactly the techniques that make real-time voice agents both fast and affordable. CallSphere runs these patterns under the hood so its voice and chat assistants stay responsive on every call without a runaway bill. Hear it for yourself at callsphere.ai.

---

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.