The raise of agents has shifted the software industry’s focus from using the best model for every task to looking for the best combination of models that can carry out each specific task rapidly, reliably and at a relatively contained price.
The concept behind this shift is known as routing: while early implementations were already circulating a few years ago, especially in the world of RAG. With the recent surge in token spend the idea has really taken off again.
Many players in the field have already started offering routing as a core part of their platform, such as OpenRouter with Fusion and Sakana AI with Fugu, and one pattern emerges from these services: a good orchestrator/dispatcher is the element that determines the success of a routing system when carrying out a task.
While most of the routing world is focused on language models powering agents, we decided to apply this same concept and learnings to something closer to us: document parsing, with our new Parse Gateway webapp.
You don’t always need the best parser
Document processing pipelines often tend to oversee the parsing complexity needs for each file, let alone for each page in a file.
There are, instead, two widespread approaches:
- Use the best parser, sacrificing cost and latency in favor of output quality
- Use the fastest parser, losing output quality in favor of reduced latency and costs
These strategies are often “flat”, meaning that they apply to all documents that flow through the pipeline without any nuance or distinction. Even in those systems where some differentiation is applied, it is mostly applied at the file level, and humans or VLMs are the ones determining complexity and routing to the appropriate pipeline, implying higher costs and longer processing times that discourage companies from adopting this approach.
With Parse Gateway, we decided to take a different path, following the introduction, in LiteParse v2.2.0, of the is_complex functionality, which estimates the complexity of a document at the page level, determining the need for OCR and the reasons why more advanced parsing techniques might be needed, also informed by layout complexity signals.
The idea is simple: when a file gets uploaded, LiteParse estimates its complexity at the page level, and each page is routed to a LlamaParse tier based on why — and how severely — it needs more than a cheap text-only pass. Each reason is_complex surfaces implies a baseline tier:
| Reason | Explanation | Baseline Tier |
|---|---|---|
no-text |
Almost no extractable native text, and no full-page raster behind it (a blank page, or a near-empty cover/divider). | Cost Effective |
scanned |
A single raster covers essentially the whole page and there is little or no extractable text behind it (a scanned/photographed page). | Agentic |
sparse-text |
Some real text, but it covers very little of the page. Typically a figure-heavy page with only thin captions. | Agentic |
embedded-images |
Substantial embedded raster figures sit alongside the native text. | Agentic |
garbled |
The native text decodes to garbage (broken cmap / Type3 char-code fallback), so the visible glyphs and the extracted text disagree. | Agentic Plus |
vector-text |
Text is painted as filled vector outlines, outside the text layer, so no native text items represent it. | Agentic Plus |
But we don't stop at the baseline. is_complex also returns the magnitude behind each reason: how little of the page is actually covered by text, how much of a garbled or vector-text page is affected, how many separate images are interleaved with the body text… and Parse Gateway uses these metrics to escalate a page past its baseline tier when the signal says the page is harder than the reason alone would suggest. A page with three or more reasons firing at once is escalated too, since problems compounding across dimensions (say, sparse text and embedded images and garbling on the same page) tend to be harder than any single reason in isolation. On top of that, layout complexity signals (multi-column reading order, ruled or borderless tables, dense figure coverage) are folded in independently: a page can need no OCR at all and still get bumped up a tier if its structure is complex enough to trip up a single-pass extraction.
If no OCR is needed and the layout is simple, the page is routed to LiteParse (which can output Markdown, as of v2.1.0). In this way, you don't parse an entire file with one parser, but you scatter its pages across different tiers based on how difficult each one actually is, driving down cost and latency for non-OCR pages (LiteParse runs in-process, for free), without losing accuracy for more complex pages that get routed through more capable LlamaParse tiers.
Here is an animation of the routing flow:
Routing for everyone — including your agents
The intelligent routing available in the Parse Gateway isn't limited to the web app: we've also brought the same capabilities to our MCP server.
By adding https://mcp.llamaindex.ai/mcp (or https://mcp.llamaindex.ai/parse/mcp , if you just want the subset of tools specific for parsing) as an MCP server for your agent, you'll gain access to two additional tools:
-
estimateFileComplexity— predicts whether a document requires full parsing or can be handled by LiteParse. -
parseWithLiteParse— lets your agent explicitly route compatible documents to LiteParse for lower latency and zero-cost, in-process parsing.
This enables agents to make parsing decisions automatically: they can first estimate a document's complexity and then choose the most appropriate parsing tier, striking the right balance between speed, cost, and extraction quality without requiring any hardcoded heuristics.
Under the hood, estimateFileComplexity uses the same algorithm that powers the Parse Gateway's /is-complex endpoint, ensuring routing decisions are consistent whether you're using the web interface or an MCP-powered agent.
What this means for document processing
Complexity-based routing might be the missing link in your document processing pipelines: PDFs and other unstructured documents are not homogeneous blocks of pages, they often contain a mixture of pages with perfectly clear text, images, tables and scanned content.
In this sense, a one-size-fits-all approach inevitably brings along a set of tradeoffs that favor one vertex of the cost-latency-accuracy triangle, while losing ground on the others. Inferring the complexity of a page and parsing it with a dedicated tier is a first step towards a solution that embraces all three vertices, without noticeable sacrifices in any of them.
You can try out Parse Gateway in the web app demo, and find the code in the GitHub repository: https://github.com/run-llama/parse-gateway.
Let us know what you think!
