Methodology and data — visual context token cost benchmark

Who ran it and who paid for it#

Roberto Ercole designed, computed and published this benchmark. No third party sponsored it. He also makes Walkie, which appears as one of the four modalities measured, and that conflict is the reason every vendor figure here is calculated from a public rule quoted verbatim with its URL: a reader who distrusts the publisher can recompute the entire table without him.

What was measured and what was calculated#

Two categories of number appear in this study, and every figure on both pages is labelled with which one it is.

Measured means counted from a real file produced on a real Mac, using the Claude tokenizer.

Calculated means derived from a vendor rule quoted on this page, with the arithmetic written out on the findings page. Every cell of the benchmark table except the Walkie bundle row is calculated.

One cross-check ties the two together. The 1288×811 capture measured 1,334 tokens, and Anthropic's published formula predicts ⌈1288/28⌉ × ⌈811/28⌉ = 46 × 29 = 1,334. Measurement and formula agree exactly on that image, which is the reason the rest of the Claude column is published as calculated rather than hedged.

The vendor rules, verbatim#

Anthropic Claude

Source: Anthropic's vision documentation — verified 2026-08-16. The older docs.anthropic.com/en/docs/build-with-claude/vision path used in earlier Walkie articles now returns a 301 to this URL.

Claude views images in patches instead of pixels. Each patch is a 28×28-pixel block of the image, referred to as a visual token. An image, therefore, costs ⌈width / 28⌉ × ⌈height / 28⌉ visual tokens.

The same page publishes two resolution tiers: high-resolution, for "Claude 4.7 and later models", with a 2,576-pixel maximum long edge and 4,784 maximum visual tokens; and standard, for "all other models", with a 1,568-pixel maximum long edge and 1,568 maximum visual tokens. "Images larger than either limit are downscaled before processing."

This benchmark uses the high-resolution tier, because that is the tier Claude Code's models run on. Anthropic's own example table publishes 2,691 tokens for a 1920×1080 image on that tier and 4,784 for a 3840×2160 image downsized to 2576×1449, which matches this benchmark's calculated values for both rows. On the standard tier the same 1920×1080 image is downscaled to 1456×819 and costs 1,560 tokens, also published in that table.

OpenAI

Source: OpenAI's images and vision guide — verified 2026-08-16. The older platform.openai.com/docs/guides/images-vision path returns a 301 to this URL. The flagship model was confirmed on OpenAI's models page, verified 2026-08-16.

Some models tokenize images by covering them with 32px x 32px patches. Many model and detail-level combinations define a maximum patch budget.

A. Compute how many 32px x 32px patches are needed to cover the original image. A patch may extend beyond the image boundary.

original_patch_count = ceil(width/32)×ceil(height/32)

For GPT-5.6 models with detail set to original or auto, the service uses the original patch count without resizing the image to a patch budget or pixel-dimension limit. This means large images can use more input tokens than they did with earlier models.

OpenAI's models page states: "If you're not sure where to start, use GPT-5.6 Sol, our flagship model for complex reasoning and coding." GPT-5.6 is therefore the rule used in the main table, at its default detail level — the same guide states that on GPT-5.6 models auto and the omitted default are equivalent to original. The guide's multiplier table lists multipliers only for gpt-5.4-mini, gpt-5.4-nano, gpt-5-mini, gpt-5-nano, gpt-4.1-mini, gpt-4.1-nano and o4-mini; no multiplier is published for the full-size GPT-5.6 models, so this benchmark treats the patch count as the token count for them and says so rather than assuming a hidden factor.

The other OpenAI rule. The same page documents tile-based tokenization for GPT-4o, GPT-4.1, GPT-4o-mini, computer-use-preview and the o-series except o4-mini: scale to fit a 2048×2048 square, scale so the shortest side is 768 px, count 512-pixel squares, then add base tokens. Base and tile costs are 70/140 for gpt-5 and gpt-5-chat-latest, and 85/170 for gpt-4o, gpt-4.1 and gpt-4.5. Worked on a 1920×1080 screenshot for gpt-5: the image already fits 2048×2048, scaling the short side to 768 gives 1365×768, that covers ⌈1365/512⌉ × ⌈768/512⌉ = 3 × 2 = 6 tiles, so 70 + 6 × 140 = 910 tokens (calculated). The same procedure reproduces OpenAI's documented 765 tokens for a 1024×1024 image on gpt-4o, which is how this implementation was checked. These older models are not in the main table.

Google Gemini

Sources: Google's media resolution documentation, Google's image understanding guide and Google's token counting guide — all verified 2026-08-16, all showing "Last updated 2026-07-30 UTC".

Google publishes two image rules on two pages, and they do not produce the same numbers. This benchmark reports both.

Rule 1, the one used in the main table. The media resolution page states that "The media_resolution parameter determines the maximum number of tokens allocated per input image or video frame", that unspecified is "The default setting", and that "The token count for this level varies significantly between Gemini 3 and earlier Gemini models". Its Gemini 3 table gives an image 1,120 tokens at unspecified (default), 280 at low, 560 at medium, 1,120 at high and 2,240 at ultra_high. Because the setting allocates a token budget rather than measuring pixels, every resolution in this benchmark costs 1,120 tokens on Gemini 3 at the default.

Rule 2, on the image understanding page.

258 tokens if both dimensions <= 384 pixels. Larger images are tiled into 768x768 pixel tiles, each costing 258 tokens.

Calculate the crop unit size which is roughly: floor(min(width, height) / 1.5). Divide each dimension by the crop unit size and multiply together to get the number of tiles.

For example, for an image of dimensions 960x540 would have a crop unit size of 360. Divide each dimension by 360 and the number of tile is 3 * 2 = 6.

Applied to this benchmark's five resolutions, that rule returns: 1000×1000 → crop unit 666 → 2 × 2 = 4 tiles → 1,032 tokens; 1288×811 → crop unit 540 → 3 × 2 = 6 tiles → 1,548; 1920×1080 → crop unit 720 → 6 tiles → 1,548; 2560×1440 → crop unit 960 → 6 tiles → 1,548; 3840×2160 → crop unit 1440 → 6 tiles → 1,548 (all calculated). The rule is scale-invariant for a fixed aspect ratio, because the crop unit is defined as a fraction of the image's own short edge — every 16:9 image tiles to exactly six crops regardless of pixel count.

Resolutions and modalities (the frozen core)#

The core is frozen. It does not change between editions, so a 2027 edition is directly comparable to this one.

Why those five resolutions: 1000×1000 is the square case Anthropic publishes itself, so it anchors the table against the vendor's own numbers. 1288×811 is the real measured capture, the only row where measurement and formula can be compared. 1920×1080 is what an ordinary screenshot workflow produces and is the benchmark's headline row. 2560×1440 is where Claude's 4,784-token cap starts to bind. 3840×2160 is where the three vendors diverge hardest — capped on Claude, uncapped on OpenAI, flat on Gemini.

Why those four modalities: they are the four things a developer actually hands an agent. Four screenshots is the "cover one long page" case. The 30-frame dump is what happens when a recording is converted naively at 1 frame per second.

Two frame-dump baselines exist and must never be mixed in one comparison. Baseline A is 30 × 2,691 = 80,730 tokens, from a 1920×1080 frame, and it is the headline because it matches what an ordinary screenshot workflow produces. Baseline B is 30 × 4,784 = 143,520 tokens, from full-Retina frames that each hit the high-resolution cap; it is the upper bound Walkie's in-app savings figure uses, and it is reported as such rather than as the headline.

Precision and limitations#

The awkward parts, stated plainly.

1. Tokenizers differ between vendors. The ~3,500-token bundle is a Claude-tokenizer measurement. Other vendors tokenize text differently by a small factor. That is why the bundle cells for OpenAI and Gemini are blank rather than estimated, and why the headline 23× ratio is quoted for Claude only.
2. Vendor rules change, sometimes between editions. Every rule on this page carries a URL and a 2026-08-16 verification date. OpenAI's own guide notes that GPT-5.6 at default detail can cost more than earlier models for the same image. Treat this page as a snapshot, not a permanent fact.
3. Google publishes two conflicting rules. The media resolution page and the image understanding page give different token counts for the same image, and neither cross-references the other. Both are reported above with their numbers computed.
4. 1 fps is an assumption. It is a deliberately low sampling rate. A higher rate scales the frame-dump rows linearly; a lower rate risks missing the moment the bug appeared.
5. The frame dump assumes no downscaling. Frames are priced at the source resolution. A tool that downscales before sending would land between the rows shown.
6. Dollar figures are a rate, not a price. Everything is shown at $10 per million input tokens for comparability. No vendor list prices are reproduced on either page, because a list price fetched today goes stale faster than a formula does and would make the comparison less honest rather than more.
7. The publisher makes one of the products measured. See the first section. The mitigation is that every competing figure is calculated from a quoted public rule.
8. Output tokens are out of scope. Every number is input tokens only.

AI disclosure#

Drafted with Claude; every formula, fetch and computation verified by Roberto Ercole before publication.

Data#

The complete table is published as visual-context-token-cost-2026.csv — 48 rows, one per vendor × resolution × modality, plus three measured Walkie rows.

Cost is not a column. It depends on a rate rather than on the data, and baking one rate into the file would make the file wrong the day that rate changes.

The findings, the tables and the CSV are published under CC BY 4.0. See the licence block on the findings page.

Change log#

Contact#

Roberto Ercole — support@usewalkie.com. Corrections, data requests and disagreements about a formula are all welcome at that address; a correction ships with a dated note on the page. How every number on this site is checked is written up on the about page.