LLM Token Cost Per Page for Document Processing: 2026 Breakdown

You opened a pricing page, saw $0.30 per million input tokens, did some quick arithmetic, and quoted a per-page number to your boss or your client. Then the first invoice came in higher than the estimate, and you could not immediately say why. The gap is almost never the price per token. It is the number of times each page gets read.

Short Answer

A single extraction pass on a typical page costs between $0.002 and $0.024 depending on the model, with output tokens accounting for most of that. Once you add reasoning tokens billed at output rates, retries on malformed JSON, a second validation pass, and the inevitable full corpus rerun after a schema change, the loaded cost lands near three times the single-pass figure. Even so, the absolute numbers stay small: on a 5,000 page job the token bill is usually double digits of dollars, and the real expense is the human time spent finding the wrong 2%.

Per-Page Token Cost by Pipeline

The table below assumes one page producing roughly 900 output tokens of structured JSON, with a 1,000 token prompt and schema amortized across 20 pages per call. Published rates as of August 2026.

Pipeline	Input tokens/page	Output tokens/page	Single pass	Loaded (retries, validation, reruns)
Gemini 3.5 Flash-Lite ($0.30 / $2.50)	~310	~900	~$0.0023	~$0.008
Gemini 3.5 Flash ($1.50 / $9.00)	~310	~900	~$0.0086	~$0.029
Claude Haiku 4.5 ($1 / $5)	~3,550	~900	~$0.0081	~$0.028
Claude Sonnet 5 ($3 / $15)	~3,550	~900	~$0.024	~$0.082
Mistral OCR then Flash-Lite cleanup	~850 text	~900	~$0.0035	~$0.012

Rates verified against vendor pricing pages on 8 August 2026. Claude Sonnet 5 also carries introductory pricing of $2 per million input and $10 per million output through 31 August 2026, which lowers its single-pass figure to roughly $0.016. Model pricing moves often, so confirm current rates before you build a quote on these numbers.
| AWS Textract Tables (no LLM) | n/a | n/a | $0.015 | ~$0.023 |

Two things stand out. First, the input side is nearly free on Gemini because the API bills a document page at a flat 258 tokens, and on Gemini 3 models text pulled natively out of the PDF is not charged at all. Second, output tokens carry roughly 95% of the cost on the Gemini rows. If you want a cheaper pipeline, shorten what the model writes, not what it reads.

Claude works differently. Its PDF handling converts each page to an image and extracts the text layer, then reads both, which the documentation puts at 1,500 to 3,000 text tokens per page plus image tokens on top. That is a richer signal for charts and stamped forms, and it is also why the Claude rows show input costs an order of magnitude above the Gemini rows.

Have a messy PDF? Upload 1-3 sample pages and we will tell you if it is clean, OCR-heavy, or needs human QA.

Scan Quality Barely Touches Your Input Bill

This surprises people. A 600 DPI color scan and a 150 DPI fax of the same page cost close to the same in input tokens on Gemini, because pages are scaled to a maximum of 3072 x 3072 pixels before billing and the per-page figure is fixed regardless. On Claude, density moves the text token count within that 1,500 to 3,000 band, but a bad scan often has less extractable text, not more, so the input cost can actually fall.

What scan quality changes is everything downstream of the first read:

Retry rate. Blurry digits and skewed tables produce output that fails schema validation, so the page gets re-sent.
Output length. Uncertain models hedge. They emit nulls with explanations, or restate ambiguous cells, and every extra token bills at the output rate.
Escalation rate. Pages that fail twice on the cheap model get sent to the expensive one, which can be a 10x jump per page.
Human review rate. This is the line item that actually hurts, and no token price affects it.

So the correct mental model is not "bad scans cost more tokens per page." It is "bad scans cost more passes per page, and more minutes of a person's attention."

Where the 3x Multiplier Actually Comes From

Retries are the smallest contributor. Here is the honest breakdown of what sits on top of a single pass.

Cost driver	Multiplier on base	Mechanism
First extraction pass	1.0x	Baseline
Reasoning / thinking tokens	+0.5x to +2.0x	Billed at output rates, and output already dominates
Retry on invalid JSON or schema violation	+0.05x to +0.15x	Full re-read of the page
Second-model validation pass	+0.2x to +0.3x	Reads the page plus the candidate JSON, emits a short verdict
Adjudication when passes disagree	+0.05x	Stronger model breaks the tie on a small subset
Corpus rerun after a schema or prompt change	+1.0x per rerun	Everything processed so far gets reprocessed

Midpoints sum to roughly 3.4x. Note where the weight sits. Reasoning tokens and corpus reruns are the two big blocks, and neither is a failure of the extraction. Reasoning tokens are the model doing its job. Corpus reruns happen because the client adds a column in week two, which they always do.

The multipliers a percentage-obsessed spreadsheet would focus on, retries and adjudication, together add about 15%. If you are trying to control cost, capping reasoning effort and freezing the schema before you process page one will do more than any amount of retry tuning.

Worked Example: 5,000 Pages

Take a 5,000 page project on Gemini 3.5 Flash-Lite. Single pass: about $11.50. Loaded at 3.4x: about $39. Run it through the Batch API, which carries a 50% discount on both input and output in exchange for asynchronous turnaround, and the loaded figure drops to roughly $20.

Now price the other side of the job. If 6% of pages need a human to open the source and fix a cell, that is 300 pages of review. At two minutes each that is 10 hours. Whatever you value an hour at, multiply by 10 and compare it to $20. The token bill is a rounding error against the verification bill on nearly every real document project.

This is the part that gets missed when teams evaluate extraction approaches on price per million tokens. The number that determines whether a project is profitable is the percentage of pages that need human eyes, and that is driven by document quality, schema clarity, and how well the validation layer catches errors rather than by which model you picked.

When a Deterministic Tool Beats an LLM

Be honest with yourself about the document type. If you are processing a high volume of one fixed form, a deterministic parser or a template-based service will be cheaper and far more predictable than any LLM pipeline. AWS Textract at $0.015 per page for tables looks expensive next to $0.0023, but it returns the same structure every time, has no reasoning tokens to budget for, and does not need a validation model watching it. For a single stable layout at scale, that predictability is worth more than the token savings.

LLM extraction earns its keep when layouts vary, when you need semantic judgment (is this line item freight or a discount?), or when the corpus is a mix of digital PDFs, scans, and photographs with no consistent structure. That is exactly the case where template tools fail and where the per-page cost genuinely does spread across a wide range.

What to Measure Instead of Cost Per Token

Track four numbers per batch and you will be able to forecast a project accurately:

Passes per page. Total API calls divided by pages. If this is above 2.5, look at your prompt before you look at your model choice.
Output tokens per page. The dominant cost term. A tighter schema and a ban on explanatory prose cuts this quickly.
Schema failure rate. The percentage of responses that do not parse or violate the schema. This is your retry driver.
Human touch rate. The percentage of pages a person opens. This is your real unit cost.

Cost per token is a vendor's metric. Cost per verified row is yours.

DataConvertPro is a managed service, so we carry all four of those numbers internally and quote you a per-page or per-project price with the QA already included. If you would rather run the pipeline yourself, the math above is the same math we use, and you are welcome to it.

Frequently Asked Questions

How many tokens does one PDF page use?

It depends on the provider. Gemini bills a document page at a flat 258 tokens regardless of resolution, and on Gemini 3 models the natively extracted text is not charged separately. Claude converts each page to an image and also reads the text layer, which its documentation puts at 1,500 to 3,000 text tokens per page plus image tokens. Output tokens are separate and usually cost more than the input in both cases.

Why is my actual bill higher than my per-page estimate?

Most often reasoning tokens, which are billed at output rates and are not visible in the response body, followed by whole-corpus reruns after a schema change. Retries on malformed output are real but typically add only single-digit percentages. Log total tokens per page rather than estimating from page count, and the gap will explain itself within one batch.

Does using a cheaper model actually save money?

On the token line, yes, and the difference between a lite model and a frontier model can be 10x. On the total line it depends on the failure rate. A cheaper model that pushes your human touch rate from 4% to 12% costs more overall on any realistic labor rate. Run both on 100 representative pages, count the corrections, and let that decide.

Is batch processing worth the wait?

If your turnaround allows it, yes. Both Google and Anthropic offer a 50% discount on batch inference in exchange for asynchronous completion, and Mistral OCR roughly doubles pages per dollar in batch mode. For a one-time historical backfill this is free money. For anything a client is waiting on, it is not.