We created a document OCR router that can estimate the complexity of every single page and parse it with the relevant mode

• Some pages are full of native text, which can be directly handled with LiteParse
• Some pages contain scanned images or tables, which can be handled with our cost-effective or agentic tiers
• Some pages contain garbled text - it decodes to garbage - so you need a heavier-weight VLM to interpret the text elements
• Some pages contain heavy visuals like labeled/unlabeled charts or diagrams, which also require deeper visual processing

You actually get the routing capabilities for free with the is_complex toggle in LiteParse. The next step is figuring out what the relevant VLM modes are to parse varying page complexities. That’s well served by LlamaParse!

Blog: https://llamaindex.ai/blog/parse-gateway-smart-page-level-document-parser-routing…

LiteParse: https://github.com/run-llama/liteparse…

LlamaParse: https://cloud.llamaindex.ai

Parse Gateway: Smart, Page-Level Document Parsing Routing

Source: https://www.llamaindex.ai/blog/parse-gateway-smart-page-level-document-parser-routing The raise of agents has shifted the software industry’s focus from usingthebest 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 asrouting: whileearly implementationswere 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 withFusionand Sakana AI withFugu, 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 newParse Gatewaywebapp.

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 theis\_complexfunctionality, 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 reasonis\_complexsurfaces implies a baseline tier:

ReasonExplanationBaseline Tierno\-textAlmost no extractable native text, and no full-page raster behind it (a blank page, or a near-empty cover/divider).Cost EffectivescannedA single raster covers essentially the whole page and there is little or no extractable text behind it (a scanned/photographed page).Agenticsparse\-textSome real text, but it covers very little of the page. Typically a figure-heavy page with only thin captions.Agenticembedded\-imagesSubstantial embedded raster figures sit alongside the native text.AgenticgarbledThe native text decodes to garbage (broken cmap / Type3 char-code fallback), so the visible glyphs and the extracted text disagree.Agentic Plusvector\-textText 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\_complexalso 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 textandembedded imagesandgarbling 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 addinghttps://mcp\.llamaindex\.ai/mcp(orhttps://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,estimateFileComplexityuses the same algorithm that powers the Parse Gateway’s/is\-complexendpoint, 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!

LlamaIndex 🦙 (@llama_index): Not every page in your PDF needs the same treatment.

A scanned cover, a dense table, a clean text page, a figure-heavy diagram…. most parsing pipelines throw all of them at the same parser, forcing a tradeoff between cost, speed, and accuracy across the whole document.

We