If you run a document through a large language model, you pay for every page, every pass, every year.
We call that the model tax.
Most advice on this stops at the document type: use rules on invoices, use AI on contracts, pick a lane. That’s not granular enough, and it’s not really the point.
The real cost lever sits deeper than the document: at the page, the field, and the data type inside it. A total in a fixed spot is a rule’s job. A signature is a pattern to detect. A handwritten note in the margin might genuinely need a model, and sometimes it does.
You should be able to make that call field by field, not once for the whole document, and you should know which fields will use AI before you run anything, not find out from the bill afterward.
At 25,000 documents a month, our cost model estimates that a per-token LLM approach (not Grooper) could cost roughly $56,000 to $120,000 a year depending on the model. The same workload on a Grooper-designed pipeline, where AI use is controlled down to the field, is estimated at around $15,000 a year.
One thing before the math: every figure below is a directional estimate from our own cost model, not a quote. The numbers are built on published API list prices as of August 2026, and token prices change without notice, so confirm current rates on each vendor’s own pricing page before making any decision. The full set of assumptions behind the model is stated near the end of this post.
Table of Contents
What is the model tax?
The model tax is the recurring cost of renting intelligence by the token. Every AI document tool that sends pages to a large language model pays per token, and passes that meter on to you. The meter never stops: same documents next year, same bill next year.
Double your volume and the bill doubles with it.
That’s not how software used to work, and it’s not how it has to work now.
There are two ways to buy AI document processing.
You can rent a model, meaning every page flows through an LLM and every page gets billed. Or you can design a pipeline, where the decision of what needs AI and what doesn’t is made at the level that actually matters: not the whole document, but the page, the field, and the data type inside it.
Some fields need a rule. Some need a small model. Some, like handwriting or a genuinely unstructured note, may need a frontier model, and a designed pipeline doesn’t pretend otherwise. It routes to AI exactly there, using whichever provider you choose, and nowhere else.
The difference between those two approaches is the model tax. On typical mid-size volumes, our estimates suggest it can run into six figures over five years.
Why control AI at the field level instead of the document level?
Because “route this document type to AI, route that one to rules” is still too coarse to be useful. Deciding by document type means either sending the whole invoice to a model because of one hard field, or missing that field because the rest of the document didn’t need AI.
The finer answer sits below the document. In Grooper, that control goes down to the field using ReadScope, which operates at the field level rather than the document level. Each page, data type or data field in a document can have its own method, chosen by what that field actually needs: a deterministic rule, a small model, or your own AI, not whatever the rest of the document is doing. A total gets a rule. A signature gets a pattern match. A handwritten margin note can go to whichever model you already trust, including one you have a contract with elsewhere.
Because that configuration is set before processing starts, you know exactly which data types or fields will use a rule and which will use AI before a single page runs. That’s a different kind of predictability than sending a whole document to a model and finding out what happened when the results, and the bill, come back. You’re deciding where AI runs, in advance, instead of discovering it after the fact.
How much does it cost to run documents through an LLM?
For a typical workload (25,000 semi-structured documents a month, 2 pages each, 15 fields, simple line-item tables, hundreds of sender layouts), our model estimates that a metered LLM approach could cost $56,000 to $120,000 per year in combined API and error-correction costs, depending on which model you pick.
That could mean 19 to 40 cents per document, for as long as you run it. To be clear about attribution: those figures are estimates for non-Grooper, per-token approaches, not Grooper pricing (Grooper’s estimated figure, roughly $15,000 on this workload, comes below).
All of these estimates are based on August 2026 list prices and will drift as vendors reprice; the point is the spread, not the third digit.
Here is where the money goes.
A page of a business document is roughly 1,500 input tokens, plus prompt and schema overhead on every call. Real extraction is never one call: classify, extract, validate is typically 2 or more passes per document, plus re-runs when a response fails to parse. Output tokens scale with how many fields you capture.
Multiply that by 300,000 documents and 600,000 pages a year, and our estimates suggest even mid-priced models could bill roughly $11,000 to $13,000 in raw API costs alone.
But the API bill is the smaller half of the tax.
Renting a model vs. designing a pipeline
Here is the difference in one table.
| Renting a model | Designing with Grooper | |
|---|---|---|
| Who picks the model? | The vendor. You get what's baked in, at their price. | You do: per document, page, field, or data type. Or no model at all. |
| When do you know which fields use AI? | Only after processing, when the bill reflects it. | Before you run a single page, configured field by field. |
| Cost per page | Metered. Every page, every pass, every year. | The predictable majority of pages handled by rules at $0 in token costs. |
| Complex tables | Rows silently dropped or misaligned; found downstream. | Read as rows and columns, deterministically. Same table, same answer, every time. |
| Your data | Leaves your network with every API call. | Stays on your network when you say so. Zero-AI configuration included. |
| When token prices change | Your unit cost changes with them. You find out on the invoice. | Nothing happens. Rules don't reprice. |
| When volume doubles | The bill doubles. The meter scales with you. | Only the small exception share grows. Your savings grow with volume. |
*Sources:
- “Benchmarking Table Extraction: Multimodal LLMs vs Traditional OCR” (ACL Anthology, 2025): https://aclanthology.org/2025.xllm-1.2.pdf
- Microsoft Research, “Table Meets LLM” (WSDM ’24): https://www.microsoft.com/en-us/research/publication/table-meets-llm-can-large-language-models-understand-structured-table-data-a-benchmark-and-empirical-study/
- Horn & Keuper PDF-parser benchmark (arXiv, 2026): https://arxiv.org/pdf/2603.18652
Why is the cheapest model often the most expensive?
Because errors cost more than tokens. In our model of the per-token approach (again, these are non-Grooper estimates), the budget-tier model could have the lowest API bill of any option, an estimated $1,300 a year, and the highest total cost, an estimated $120,000 a year. Its higher error rate could produce tens of thousands of bad documents, and humans fixing them at 4 minutes each could cost nearly $120,000 in labor.
And error rates climb as documents get harder due to:
- More fields per document
- More layouts across senders
- Longer line-item tables all multiply the miss rate
A flagship model might hold errors near 4 percent on a moderate workload. A budget model on the same workload could run closer to 16 percent.
At 300,000 documents a year, the gap between 4 percent and 16 percent errors could mean 36,000 extra documents a person has to open, find, and fix.
So the “save money with a cheaper model” play usually backfires. Cheap tokens, expensive cleanup. And the reverse trap exists too: paying flagship prices to read simple, uniform forms is premium tokens spent on pages a rule could read for free.
That is the real problem with renting a model. The vendor picks the model, you get what is baked in, and the only lever you hold is which meter you plug into.
What does intelligent document processing pricing look like without the meter?
A designed pipeline inverts the cost structure. In Grooper, deterministic rules (layout recognition, pattern matching, table readers, validation logic) handle the predictable majority of documents at zero marginal cost. Only the genuine exceptions go to a model, and only as small, targeted snippets.
On the same 25,000-documents-a-month workload, the default design looks like this: rules handle 62 percent of documents without any LLM at all. That is 372,000 pages a year that could be processed at $0 in token costs per page. The remaining 38 percent get right-sized AI assistance, a small model reading short snippets instead of a flagship model reading whole pages. The annual API cost for that assistance is estimated at a few hundred dollars, not tens of thousands.
Add a 2 percent exception rate for human review and our model estimates the Grooper pipeline at about $15,400 a year. That is the Grooper estimate, and only that figure and the zero-AI figure below are Grooper estimates on this page: roughly 5 cents per document, against an estimated 19 to 40 cents per document ($56,000 to $120,000 a year) for non-Grooper, rented-model approaches on the same workload. Both sides are modeled under the same assumptions; your actual pipeline economics depend on your documents, which is exactly what a proof of concept establishes.
This is what we mean by AI-native, never AI-dependent. Grooper works with any LLM provider you choose, and that choice can change by document type, by page, by field, or by data type. Or no model at all. A rule that beats a model means no model at all, and the ability to deliver without AI is often the most valuable thing about how we deliver with it.
The goal isn’t to avoid AI. It’s to spend it only where it earns its keep, on the terms you choose, with AI use visible and configured before you ever commit to running it.
Before you pick a platform, price the whole system.
The IDP Buyer’s Checklist is an 8-page worksheet covering the three things demos skip: a 3-year total cost of ownership model, 20 questions vendors should answer without flinching, and a step-by-step accuracy test using your documents. Register below and it’s yours.
What if your documents can’t go to a cloud AI?
Then every metered option is off the table, because every API call sends your data off your network. Grooper includes a zero-AI configuration: engineered rules process 100 percent of documents on your own infrastructure, with no model, no meter, and nothing leaving your network.
In our cost model, Grooper’s zero-AI configuration on the same workload is estimated at about $22,800 a year in exception-handling labor, with $0 in AI costs. That is a Grooper estimate, and the trade-off is honest: error rates could run slightly higher than the hybrid design, around 3 percent, because there is no model catching odd layouts. For regulated documents (health records, legal files, land records, anything under data residency rules), that trade is usually an easy yes.
And if you want models on sensitive data anyway, Grooper also runs LLMs on your own GPUs, so the data stays home and the meter stays off.
How do complex tables change the math?
Tables are where LLM extraction quietly fails. Long, multi-page line-item tables are the documented weak spot: models drop rows, merge rows, or misalign columns, and the errors surface downstream in your ERP, not in the extraction report. In our model, complex tables multiply error risk by 1.7x and inflate token counts on every page.
Grooper reads tables structurally, as rows and columns, using deterministic table extraction. The same table produces the same answer every time, which is exactly the property a probabilistic model cannot promise. If your documents are invoices, EOBs, or remittances full of line items, this single difference often decides the comparison.
*Sources:
- “Benchmarking Table Extraction: Multimodal LLMs vs Traditional OCR” (ACL Anthology, 2025): https://aclanthology.org/2025.xllm-1.2.pdf
- Microsoft Research, “Table Meets LLM” (WSDM ’24): https://www.microsoft.com/en-us/research/publication/table-meets-llm-can-large-language-models-understand-structured-table-data-a-benchmark-and-empirical-study/
- Horn & Keuper PDF-parser benchmark (arXiv, 2026): https://arxiv.org/pdf/2603.18652
How can you check this math on your own documents?
Not with our spreadsheet, and not with anyone else’s. The honest answer is a proof of concept on your actual files, because the only numbers that matter are the ones your documents produce.
For transparency, here are the assumptions behind every figure on this page: published API list prices as of August 2026, about 1,500 input tokens per page plus prompt and schema overhead per call, 2.2 processing passes per document (classify, extract, validate), 8 percent re-runs, output tokens scaling with field count, and error correction at 4 minutes per bad document at a $38 per hour loaded labor rate.
Change the assumptions and the totals move, but the structural spread between metered and designed survives any reasonable set of inputs.
- OpenAI: https://platform.openai.com/pricing
- Anthropic: https://platform.claude.com/docs/en/about-claude/pricing (docs rate card) or https://claude.com/pricing
- Google Gemini: https://ai.google.dev/gemini-api/docs/pricing
A note on those prices: LLM providers reprice their APIs regularly and without notice, so every dollar figure on this page is subject to change. Always confirm current rates with the vendor before budgeting, and treat the totals here as a way to compare cost structures, not as a forecast of your invoice.
The step that replaces all modeling is real evidence: a proof of concept on your actual files. We have been doing this work since 1986, and Grooper has run at federal scale, including 39 million pages migrated for the U.S. Nuclear Regulatory Commission. A POC on your documents takes weeks, not quarters, and it answers the cost question with your documents instead of anyone’s estimates.
