OCR is a routing problem now

I built a document intelligence system that classified over 60 million documents, and I still get the same question from technical leaders every few weeks: "Which OCR should we use?"

In mid-2026, that question stopped having an answer. Not because the models got worse. Because the top of the field got so good, so small, and so crowded that "which model" is no longer the decision that matters. The decision that matters is architectural: how do you route each document to the cheapest engine that can handle it?

That's the conclusion of every rigorous evaluation I've read this year, and it matches what I've seen in shipping document pipelines. Let me walk through the evidence, because the reasoning changes how you budget, staff, and decide whether to build or buy.

The scoreboard broke first

Start with the numbers vendors will show you. On OmniDocBench, the leading open benchmark for document parsing, the top three open models (PaddleOCR-VL-1.6, OvisOCR2, MinerU2.5-Pro) score between 95.7 and 96.6. That gap is smaller than the noise introduced by changing the document mix or the evaluation harness. Rankings flip depending on which version of the benchmark you run.

It gets worse when you compare leaderboards. The IDP Leaderboard, which measures a composite of OCR, table extraction, and key-information extraction, currently ranks Nanonets OCR-3 first at 85.9, then GPT-5.4, then Gemini-3-Pro. None of those three appear at the top of OmniDocBench. Two independent trackers, BenchLM and llm-stats.com, even disagree about which closed model leads the same benchmark version. Baidu, for its part, grades its new Unlimited-OCR on ParseBench, a benchmark of its own making that few outside Baidu have adopted yet.

And vendor-reported numbers diverge from independent ones. Mistral claims 93.07 on OmniDocBench for OCR 4, putting it near the top. Independent trackers place it closer to third.

None of this means the benchmarks are useless. It means they're a screening tool, not a procurement decision. If a vendor's pitch deck relies on a single leaderboard screenshot, it tells you more about the pitch than about the product.

What actually changed under the hood

Three shifts got us here, and they're worth understanding because they drive the cost model later.

End-to-end vision-language models replaced pipelines. A 2023-era OCR stack chained a text detector, a character recognizer, and a rule-based layout module. The 2026 default is a single model that reads a page image and emits structured Markdown or JSON directly: text, tables, formulas, and reading order handled jointly. Even Docling, IBM's hugely popular parsing framework with 63,000+ GitHub stars, now trails VLM-native competitors in handling complex layouts. In independent testing, it produced character errors and misaligned columns that newer models don't.

The best models got tiny. PaddleOCR-VL-1.6 has 0.9 billion parameters. OvisOCR2 is 0.8B. MinerU2.5-Pro is 1.2B. These sub-2B specialists outperform many general-purpose models 10 times their size on document parsing. Small means cheap to host, cheap to fine-tune, and viable on modest GPUs. That single fact rewrites the build-vs-buy math from two years ago.

Data beats parameters. MinerU2.5-Pro retained its predecessor's architecture and achieved benchmark-topping accuracy by scaling the training data from under 10 million to 65.5 million pages. Hold the model constant, grow and diversify the corpus. Every leading lab now runs this playbook, and it applies at a fine-tuning scale too, as we'll see.

The four tiers you're actually choosing between

Once you stop looking for one winner, the market sorts into four tiers with different jobs:

1. Frontier multimodal LLMs (Gemini 3 Pro/Flash, Claude Opus 4.8, and GPT-5.x). Zero-shot, no training, best on the genuinely hard stuff: degraded scans, handwriting, ambiguous forms. Also, the most expensive per page by a wide margin.
2. Purpose-built document APIs (Mistral OCR 4 and Document AI, Reducto, LlamaParse, plus the Azure/Google/AWS document services). Managed reliability, structured schemas, and compliance paperwork. You trade some flexibility for someone else carrying the pager.
3. Compact open-weight VLMs (PaddleOCR-VL-1.6, GLM-OCR, dots.mocr, olmOCR-2, Nanonets-OCR-s, Unlimited-OCR, and a dozen others). Self-hostable, fine-tunable, and at volume, they cost a fraction of any API.
4. Classical engines (Tesseract, lightweight PaddleOCR). Still the fastest and cheapest option alive for clean, printed, high-volume documents. Narrow, but not dead.

There's also a tier zero that people often forget: many PDFs aren't scans at all. A fast text-layer extractor, like zpdf, extracts embedded text from digitally generated PDFs at near-zero cost. Run it first and only send the pages that come back empty to an actual OCR model. In many pipelines, this one check resolves a large share of the volume before you spend a single GPU-second.

What wins in production (hint: nothing wins everything)

The most useful evaluation published this year is Ida Silfverskiöld's head-to-head in Towards Data Science: 14 engines against 93 real documents across 17 document types. Not a benchmark harness. Real bank statements, forms, receipts, handwriting, newspapers.

The findings are refreshingly unglamorous:

• Gemini Flash 3.1-Lite was the overall winner on diverse production documents, and specifically on the hardest categories, forms, and handwriting, where it beat AWS Textract.
• Claude Sonnet 4.6 produced the highest raw extraction quality in the study, and was a clear outlier on latency and cost. Worth it when a wrong number costs real money. Overkill for everything else.
• Mistral OCR was the cost-effective standout for structured tables.
• Tesseract, the twenty-year-old workhorse, was the fastest engine tested and still the right choice for clean printed text. It fell apart on photographs and handwriting, exactly as you'd expect.
• PaddleOCR (pre-1.6 versions) stumbled on bank statements and tax forms, occasionally looping. DeepSeek-OCR returned empty output on some document types.

No engine won all 17 categories. Not one. Which is why the study's architectural conclusion deserves to be pinned above your team's whiteboard: classify documents by type and difficulty first, route each class to the cheapest engine that handles it, and escalate only the genuine failures to a frontier model.

I want to be direct about this because I've watched teams do the opposite. They pick "the best model," wire everything through it, and end up paying frontier-LLM prices to read pristine invoices that Tesseract would have handled for effectively nothing. The router isn't an optimization you add later. It's the system.

Fine-tuning is cheaper than you think, when it applies

Here's the part of the 2026 story that surprised me most: the sample sizes.

LightOn fine-tuned their 1B-parameter LightOnOCR-2 on roughly 707 Sinhala samples and beat Google Document AI on that task (character error rate 1.05% vs 2.06%, with Surya-OCR at 8.84%). Nanonets-OCR-s improved by 9 points on olmOCR-Bench after a single fine-tuning epoch, including a 51-point jump in headers and footers. A few hundred to a few thousand in-domain pages. That's it. For a stable document type, this is not a big-data problem.

If you're picking a base model to fine-tune, the field has genuine standouts. olmOCR-2 from Allen AI ships official training code and a public 260K-page dataset, and it's the best-documented path. GLM-OCR has a maintained LLaMA-Factory tutorial and a 0.9B footprint that keeps training cheap. LightOnOCR-2 is the proven pick for low-resource languages and unusual scripts.

Two caveats, and they're both hard-won:

Fine-tune only when the document stream is stable. The same invoice template forever? Fine-tune, and a small specialist will likely beat every commercial API at a fraction of the marginal cost. An open-ended mix of contracts, receipts, and handwriting? Skip the fine-tune and put that engineering into routing instead. Chasing open-ended diversity with a single fine-tuned model is how you burn a quarter.

Check the license before you invest. Most of the strong candidates (olmOCR-2, RolmOCR, PaddleOCR-VL-1.6, GLM-OCR, dots.mocr, LightOnOCR-2) are MIT or Apache-2.0 with clean commercial terms. ByteDance's Dolphin-v2, meanwhile, currently shows "NOASSERTION" as its license on GitHub. Don't commit engineering weeks to a base model whose commercial terms you can't name.

What does a million pages cost?

The spread here is the whole argument, so I'll just show it. Approximate cost to process 1 million pages, standard tiers, from figures gathered across current pricing pages:

That's a 300x range for the "same" job. The honest caveat: the $200 figure excludes the fine-tuning work, the infrastructure setup, and the ML engineer who owns it, and all of these numbers will drift as GPU and token prices move. But the shape of the table is stable, and the shape is the point. At meaningful volume, routing even half your pages away from the expensive tiers pays for the routing layer many times over.

The decision sequence

If I were advising a CTO starting this evaluation next Monday, here's the order of operations:

1. Characterize your document stream before looking at any model. Narrow and stable (the same forms, the same templates) points toward fine-tuning a small open model. Heterogeneous and unpredictable points toward a routing stack with a frontier LLM at the top for escalations.

2. Check for text layers. Digitally generated PDFs don't need OCR. Extract the embedded text and reserve model calls for actual scans.

3. Match the build-vs-buy call to your team, not your ambitions. High volume (10M+ pages/month), stable types, and an in-house ML team? Self-host and fine-tune. Moderate volume and limited ML headcount? A managed API like Mistral, Reducto, or LlamaParse, and spend your people elsewhere. Air-gapped or regulated? Self-hosted open models or a vendor with a real on-prem story.

4. Pilot on 50 to 100 of your own documents before signing anything. Given how much the public leaderboards disagree with each other, this small pilot is the only benchmark that counts. It will take a few days and contradict at least one vendor claim. It always does.

5. Put re-evaluation on the calendar. The open-model gap narrowed to under a point in a few months this year, and the IDP Leaderboard's top spot changed hands between May and July. Any "best model" decision you make today has a shelf life measured in months. A quarterly re-benchmark against your pilot set is cheap insurance, and the routing architecture makes swapping an engine a config change instead of a migration.

Build the router. Let the models keep leapfrogging each other underneath it. That's the one choice in this market that doesn't expire.