What a screenshot costs a computer-use agent, worked out per step
Image token formulas from three model APIs, applied to one 1280x800 screen. Why keeping every screenshot makes a long task cost ten times more.
A computer-use agent sees the screen through screenshots. Every step it takes, it looks again, and every look is billed as input tokens. On a 1280x800 display, one screenshot costs about 1,200 to 1,550 input tokens depending on the provider. On its own that is small. What decides the bill is how many screenshots you send back to the model on each turn.
This guide works through the numbers using the published token formulas, then shows where the real money goes in a 40-step task.
Why the model needs to see at all
An agent that drives a browser or desktop works in a loop: take a screenshot, decide on an action (click at these coordinates, type this text, scroll), perform it, take another screenshot to check the result. Anthropic's computer use documentation describes exactly this loop, and recommends prompting the model to take a screenshot after each step and confirm the step worked before moving on.
Two capabilities are required for this: tool calling, so the model can request actions, and image input, so it can read the screen. A model with tool calling but no vision can still run shell commands or call APIs, but it is blind on a desktop. It will guess at coordinates or claim a button was clicked when it never saw the page. When you pick a model for screen work, check that its listing includes image input. OpenRouter, for example, lists each model's input modalities in its models API.
Tenslo Bot handles this by removing the screen tools from any model that is not marked as accepting images, so a text-only model never pretends to see.
What one screenshot costs
Each provider turns an image into tokens differently. Here is the same 1280x800 screenshot through three published formulas.
Anthropic (Claude). The vision documentation says images are split into 28x28 pixel patches and cost ceil(width / 28) x ceil(height / 28) visual tokens. For 1280x800 that is 46 x 29 = 1,334 tokens.
OpenAI. The images and vision guide describes 32x32 pixel patches, ceil(width / 32) x ceil(height / 32), then a per-model multiplier. For 1280x800 that is 40 x 25 = 1,000 patches. With the 1.2 multiplier the guide lists for current GPT-5 models, that is 1,200 tokens, assuming the image fits the patch budget of the detail level you choose.
Google (Gemini). The image understanding guide gives a rough tiling rule: a crop unit of about floor(min(width, height) / 1.5), tiles of 258 tokens each. For 1280x800 the crop unit is 533 pixels, which gives 3 x 2 = 6 tiles, about 1,548 tokens. Gemini 3 models also accept a media_resolution setting that caps tokens per image, so check which one your model uses.
| Screen size | Claude | OpenAI (1.2x, within the patch budget) | Notes |
|---|---|---|---|
| 1024x768 | 1,036 | 922 | Anthropic's suggested size for general desktop tasks |
| 1280x720 | 1,196 | 1,104 | Anthropic's suggested baseline when accuracy is poor |
| 1280x800 | 1,334 | 1,200 | Suggested for web applications |
| 1920x1080 | 1,560 or 2,691 | 2,448 | Claude downsizes this on its standard tier; the larger number is its high-resolution tier |
The suggested sizes come from the computer use documentation, which also advises staying at or below 1920x1080.
So for a single look, the providers land within about 30 percent of each other. Choosing between them on screenshot price alone is not worth much. The loop is where the difference shows up.
Where the cost actually comes from
A chat API is stateless. On every turn you send the whole conversation again, including every earlier screenshot you chose to keep. If the agent keeps all of them, turn 1 sends one image, turn 2 sends two, and turn N sends N.
The total image tokens for an N-step task is then T x N x (N + 1) / 2, where T is the cost of one screenshot. That grows with the square of the task length.
Take a 40-step task at 1280x800 on Claude (T = 1,334):
- Keep every screenshot: 1,334 x 40 x 41 / 2 = 1,093,880 image tokens.
- Keep only the 2 most recent: turn 1 sends one image, every later turn sends two. That is 1,334 x (1 + 2 x 39) = 105,386 image tokens.
The pruned loop sends about a tenth of the image tokens for the same task. At the $1 per million input tokens that Anthropic's docs quote for Claude Haiku 4.5, that is roughly $1.09 against $0.11 per task, before text and output. The gap grows with a more expensive model or hundreds of runs a day.
There is a second limit besides money. The same documentation notes that once a single request carries more than 20 images, each image is held to a stricter size limit, and that a loop keeping its screenshot history reaches that count within a few dozen turns. The context window fills up too. Full history is not only expensive; long tasks eventually fail.
Prompt caching changes the math, partly
Prompt caching lets the provider reuse a prefix it has already processed. With Anthropic's prompt caching, a cache write costs 1.25 times the base input price (5 minute lifetime) and a cache read costs 0.1 times on most models. The computer use guide recommends moving cache breakpoints forward each turn for exactly this reason.
Redo the 40-step, keep-everything loop with caching. Each turn writes one new screenshot to the cache and reads all the earlier ones:
- Writes: 40 x 1,334 x 1.25 = 66,700 base-token equivalents
- Reads: 0.1 x 1,334 x (0 + 1 + ... + 39) = 104,052 base-token equivalents
That is about 170,750 in total, far below the uncached 1.09 million and not far above the pruned loop.
Two catches. First, caching only helps while turns arrive within the cache lifetime; an agent that waits ten minutes for a page or a human loses it. Second, pruning and caching pull against each other. Removing an old screenshot changes an earlier part of the prompt, so everything after it no longer matches the cached prefix. If you prune, prune in a way that keeps the start of the conversation stable, or accept the rewrite cost. Caching does not fix the 20-image threshold or the context limit; pruning does, which is why most agents prune.
Resolution is a lever, up to a point
Fewer pixels means fewer tokens. Dropping from 1280x800 to 1024x768 saves about 22 percent per screenshot on Claude. It is tempting to go lower, but the computer use documentation lists "resolution too low" as a cause of consistently poor accuracy, and clicks that land near but not on small targets as a sign that detail was lost.
Three practical rules follow from the docs:
- Pick the display size, do not let the provider pick it. Anthropic's API rejects a computer-use screenshot that exceeds the model's limits instead of quietly downscaling it. Resize in your own code and scale the model's coordinates back to the real screen.
- Watch for Retina captures. On macOS, screenshots are captured at twice the logical resolution. A 1280x800 screen becomes a 2560x1600 image, which exceeds the image limits and is rejected for computer use. Downscale it by 2x before you send it, and the coordinates the model returns are already in logical pixels, so use them as they are. Halve the coordinates only if you send the full-size image, and never do both. Anthropic's computer use documentation describes both options.
- Zoom instead of enlarging everything. Newer Claude computer-use tools have a
zoomaction that captures one region at full resolution. Reading a small label that way costs one extra image, not a permanently larger screen.
A quick estimate for your own agent
To estimate image spend for a workload, you need four numbers:
- T, the tokens per screenshot at your display size, from the formulas above.
- N, the typical number of steps per task. Log it; guesses tend to be low.
- K, how many recent screenshots you keep in each request.
- R, runs per day.
Image tokens per task without caching are roughly T x (K x N - K x (K - 1) / 2) when you keep K screenshots, which is close to T x K x N for long tasks. Multiply by R and your model's input price. Then compare against keeping everything, T x N x (N + 1) / 2, to see what history is worth to you.
For most screen work, two or three recent screenshots carry the state the model needs: what the screen looks like now, and what it looked like before the last action. Older pages are better summarised in text than re-sent as pixels. Tenslo Bot keeps the two most recent screenshots by default and drops the rest from each request, which is the same trade-off this guide works through.
Token formulas and prices were checked against these pages in October 2026. Providers change them; recheck before you budget.
Sources
- Computer use tool, Anthropic
- List models API, OpenRouter
- Vision: resolution and token cost, Anthropic
- Images and vision: calculating costs, OpenAI
- Gemini API image understanding, Google
- Prompt caching, Anthropic