What a scanned page actually costs

Quoting a document pipeline requires knowing what one page costs. Almost every estimate we see starts from an assumption about pixels, and that is not how images are billed.

Claude reads images in patches. Each patch is a 28×28 pixel block and counts as one visual token, so an image costs:

tokens = ⌈width / 28⌉ × ⌈height / 28⌉

A 1000×1000 image is ⌈35.7⌉ × ⌈35.7⌉ = 36 × 36 = 1,296 tokens. That number is computable before you send anything, which makes a real quote possible.

The formula is the easy half. The half that surprises people is the resolution tier, which decides whether a page costs 1,560 tokens or 4,784.

Two tiers, and a 3× difference

Every model has a long-edge limit and a visual-token ceiling. Exceed either and the image is downscaled before processing.

The ceiling is what matters. On standard-tier models, no image can cost more than 1,568 tokens — feed it a 4K scan and it is downscaled until it fits. That cap is a useful budgeting property: page cost is bounded regardless of what customers upload.

High-resolution models remove that ceiling and raise it to 4,784. Same code, same images, up to three times the token cost:

Note the first row. Below about 1.2 megapixels the tiers agree, because nothing is being downscaled. The divergence starts exactly where document scans live.

Priced per thousand pages

Take a 2000×1500 scan — roughly A4 at 180 DPI, a normal setting:

Standard tier, Claude Haiku 4.5 at $1/MTok input:

1,564 tokens × $1 / 1,000,000 = $0.001564 per page
                              = $1.56 per thousand pages

High-resolution tier, Claude Opus 5 at $5/MTok input:

3,888 tokens × $5 / 1,000,000 = $0.01944 per page
                              = $19.44 per thousand pages

A 12× spread on the same document, from two decisions — which model and what resolution — that are usually made for unrelated reasons. At 400,000 pages a month that is $626 against $7,776 for the image tokens alone.

The upgrade that quietly doubles a bill

Here is the version of this that reaches production. A pipeline runs on a standard-tier model. Someone upgrades to a newer model for better extraction accuracy, which is a reasonable thing to want.

Nothing else changes. No prompt change, no resolution change, no volume change. But the newer model is high-resolution tier, so images that were being capped at 1,568 tokens are now billed at up to 4,784. The image half of the bill roughly doubles or triples, on top of whatever per-token price difference the new model carries.

This is invisible in a diff and it is invisible in a provider dashboard, which reports input tokens without distinguishing text from image. It shows up as "costs went up after the upgrade" and gets attributed to the model's price rather than to the tier change.

Guard against it by recording the split:

// Compute expected visual tokens before the call, and store it alongside
// actual usage. A divergence between the two means an image was downscaled
// — which is itself worth knowing, because it may explain accuracy changes.
function visualTokens(w: number, h: number, tier: "standard" | "high"): number {
  const maxEdge = tier === "high" ? 2576 : 1568
  const maxTok  = tier === "high" ? 4784 : 1568

  let [W, H] = [w, h]
  const long = Math.max(W, H)
  if (long > maxEdge) {
    const k = maxEdge / long
    W = Math.round(W * k); H = Math.round(H * k)
  }
  let t = Math.ceil(W / 28) * Math.ceil(H / 28)
  if (t > maxTok) {
    const k = Math.sqrt(maxTok / t)
    W = Math.round(W * k); H = Math.round(H * k)
    t = Math.ceil(W / 28) * Math.ceil(H / 28)
  }
  return t
}

What resolution to actually send

Sending the largest image you have is not free and often is not better, because above the tier limit it gets downscaled anyway — you paid the upload bandwidth and latency for pixels the model never saw.

Rules that hold up:

Match the tier, do not exceed it. For standard-tier models, resize the long edge to 1,568 px yourself. You get identical results, smaller payloads and lower latency. For high-res models the equivalent number is 2,576.

150 DPI is usually enough for printed text. A4 at 150 DPI is 1240×1754 — the long edge is already over the standard limit, so going to 300 DPI buys nothing on those models. On high-res models 200–250 DPI is the sensible ceiling for ordinary documents.

Go higher only where the detail is the job. Small print, dense tables, degraded scans, handwriting. Decide it per document type, not globally, and measure whether accuracy actually moves — a golden set is what makes that a measurement rather than an argument.

Compress carefully. JPEG at reasonable quality reduces payload size and latency for free. Heavy compression puts artefacts on exactly the small text you are trying to read, and repeated compression passes compound it. Inspect what you are actually sending at least once.

Estimating a real pipeline

Everything above composes into a quote you can defend:

per page = visual tokens × input rate
         + instruction tokens × input rate      (cache this)
         + output tokens × output rate          (usually the larger half)

For 2000×1500 scans on Haiku 4.5, with 800 tokens of cached instructions and 600 tokens of structured output:

image:        1,564 × $1  / 1M  = $0.001564
instructions:   800 × $0.10 / 1M = $0.000080   (cache read, 0.1x)
output:         600 × $5  / 1M  = $0.003000
                                  ----------
                                  $0.004644 per page
                                  $4.64 per thousand pages

Output is the largest line, which is the general pattern — output tokens are five times the price and people consistently optimise the wrong half. But the image line is the one that moves by 3× on a decision nobody logged, and that is worth knowing before the invoice arrives.

More in what an AI feature costs to build, which feature tripled the bill, and how we build extraction pipelines. Formula and token tables from Anthropic's published vision documentation, checked 27 August 2026.