Document Parsing Gets a Router: What OpenDocRouter Means for You

On October 7, LlamaIndex launched OpenDocRouter, a hosted API that puts ten document models behind one endpoint. You send a PDF or an image, pick a model, and get markdown back. Every model is scored on the same benchmark for quality and for cost, so the trade-off sits right there in the price list.

Why should a business owner care? Because document parsing is the unglamorous first step in almost every automation that touches invoices, purchase orders, contracts or shipping paperwork. If the text and tables coming out of a PDF are wrong, everything downstream is wrong too. This launch makes it much easier to pick the right parser for each job instead of betting everything on one.

TL;DR#

• OpenDocRouter gives you five frontier and five open-source parsing models through one API, each benchmarked on ParseBench for quality and cost per 1,000 pages.
• The spread is huge: the top scorer costs about $48.82 per 1,000 pages, while models scoring in the low 70s cost under $1.
• The practical move is routing: send easy documents to cheap models, hard ones to expensive ones, and validate everything before it reaches your ERP or CRM.

What LlamaIndex actually shipped#

OpenDocRouter is a document-to-markdown service. It accepts PDFs, PNGs and JPEGs (or URLs to them) on a single parse endpoint, according to Unite.AI's launch coverage. Small jobs run synchronously up to 50 pages. Bigger jobs run asynchronously, up to 500 pages or 50MB.

At launch the lineup includes Claude Opus 5.5, Gemini 3 Flash, Gemini 3.8 Flash, GPT-5.6 Terra and GPT-6 Luna on the frontier side, plus open-source models such as MinerU2.5-Pro, PaddleOCR-VL-1.6 and dots.mocr. LlamaIndex says each model runs a "versioned recipe consisting of prompts, processing, and settings," tuned against benchmark results.

A few details matter more than the model list:

• Layout grounding. Turn on layout: true and you get bounding boxes and reading order across 15 shared element types, including table, form and key_value.
• Per-page results. Each page comes back with its own markdown, status and charge, and failed pages can be retried on their own.
• Billing. It's per token at provider prices, and failed pages aren't charged.

LlamaIndex positions it next to LlamaParse, its managed platform with schema extraction and self-hosting, rather than as a replacement.

Why document parsing is the real bottleneck#

Most businesses don't have an AI problem. They have a "someone retypes this PDF into the system" problem. Supplier invoices, bills of lading, signed order forms and compliance certificates all arrive as documents built for humans to read, not software.

Traditional OCR reads characters. It doesn't understand that a number sits in the "Qty" column of the third row of a table that continues onto page two. That's where AI document parsing earns its keep: vision-language models read the page the way a person does, then output structured markdown your code can work with.

The catch has always been choice. A new OCR model ships nearly every month, and as LlamaIndex points out, using each one means writing prompts, handling rate limits, managing deployments and running your own benchmarks. Most teams pick one model, wire it in and never revisit the decision. That's how you end up paying premium prices to parse a clean, typed invoice that a cheap model would handle perfectly.

A shared benchmark and a single API lower the cost of switching. That changes the economics of the whole pipeline.

Quality versus cost: the trade-off in numbers#

Here's how a selection of the launch models compare on OpenDocRouter's model page. The ParseBench overall score averages several categories, and the costs are estimates that will vary with your documents.

Read that table carefully. Going from about 71 to 84 costs roughly 60 times more per page. For a contract review team that needs every clause right, that might be cheap. For a warehouse processing thousands of near-identical packing slips a day, it's waste.

What the benchmark won't tell you#

A benchmark score is an average over someone else's documents. Your scanned delivery notes with coffee stains and handwritten quantities are not in it. Treat ParseBench as a shortlist tool, then test the top two or three candidates on 50 to 100 of your own real pages before you commit.

What this means for your document data extraction#

The biggest shift is architectural. Instead of "we use model X," you design a small router that decides which model handles which document:

Inbox / upload
     |
 classify doc type -> clean, typed?  -> cheap model (e.g. ~$1 per 1k pages)
     |                  messy, scanned? -> stronger model
     |                  high stakes?    -> top model + human review
     v
 markdown + layout boxes
     |
 extract fields -> validate (totals, PO match, required fields)
     |
 pass -> post to ERP / CRM      fail -> human review queue

Three practical points come out of this:

1. Parsing isn't extraction. Markdown is the middle step. You still need code or a model that pulls out the fields you care about, like invoice number, line items and totals, into a fixed schema.
2. Validation is where trust comes from. Check that line items add up to the total, that the PO number exists and that the supplier matches. A cheap model plus strong validation often beats an expensive model with none.
3. Grounding helps reviewers. Bounding boxes let you show a person exactly where a value came from on the page, which makes human review fast instead of painful.

How to act on it: a checklist#

If documents feed any of your core workflows, here's a sensible path:

1. List your document types and volumes. Invoices, POs, contracts, IDs, shipping docs. Note how many per month and what a mistake costs.
2. Collect a test set. Pull 50 to 100 real pages per type, including your ugliest scans.
3. Write down the ground truth. For each test page, record the correct values for the fields you need.
4. Run two or three candidate models. Compare accuracy on your fields, not just overall scores, and log cost per page.
5. Set routing rules. Start simple: document type plus a confidence or validation check decides the model.
6. Add validation and a review queue. Nothing posts to your ERP, accounting or CRM until it passes checks.
7. Keep your data rules in view. Know where pages go, how long they're cached (OpenDocRouter caches for 24 hours when enabled) and whether that fits your compliance needs.
8. Re-benchmark quarterly. Models change fast. A versioned setup makes swapping one in a config change, not a rebuild.

How MagicMakers Lab approaches this#

We treat document parsing as one stage in a pipeline, not the whole project. Our AI integration and automation work usually starts with your real documents, builds a small routing and validation layer, and connects the clean output to the systems you already run, whether that's Zoho, Shopify or Stripe. It's the same approach behind Framico, where 200+ orders a day now ship with zero manual steps.

Key takeaways#

• OpenDocRouter puts ten parsing models behind one API with shared quality and cost benchmarks.
• Quality costs real money: the top model scores about 13 points higher than the cheapest strong options at roughly 60 times the price.
• Route documents by type and risk instead of using one model for everything.
• Parsing produces markdown; reliable automation still needs field extraction, validation and a human review path.
• Test on your own documents before you trust any benchmark.

FAQ#

What is document parsing?#

Document parsing is the process of turning a document built for people, like a PDF invoice or a scanned form, into structured text software can use. Modern AI document parsing uses vision-language models that read layout, tables and headings, then output markdown or JSON. It's usually the first step before extracting specific fields and pushing them into business systems.

How do I convert PDF to markdown for AI workflows?#

For a few files, open-source tools and desktop converters work fine. For business workflows, use a document parsing API that handles scanned pages, tables and multi-page layouts, then returns markdown per page. Services like OpenDocRouter let you pick the model per request, so you can balance accuracy against cost depending on how messy the document is.

Is AI document parsing accurate enough for invoices?#

Often, yes, but only with validation around it. Even top models make mistakes on poor scans, handwriting and tables that span pages. Check that line items sum to the total, match the PO number and supplier against your records, and send anything that fails to a human. That combination is what makes automation trustworthy.

How much does document parsing cost per page?#

It depends heavily on the model. On OpenDocRouter's published estimates, costs range from about $0.80 per 1,000 pages for GPT-6 Luna to about $48.82 per 1,000 pages for Claude Opus 5.5. Your real cost depends on page density and layout, so measure it on your own documents.

If your team still retypes documents into your systems, a short conversation can usually show where routing and validation would cut the manual work and which documents to automate first. Book a free audit.

Sources#

• Introducing OpenDocRouter (LlamaIndex)
• LlamaIndex Launches OpenDocRouter, a Unified API for Document Parsing (Unite.AI)
• OpenDocRouter models and benchmarks
• OpenDocRouter API documentation