The OCR Fork: Two Paths to One-Shot Hundred-Page Document Parsing

You’re a data engineer at a consulting firm. On your desk is a 200-page scanned industry report — a mix of tables, charts, multi-column layouts, and dozens of pages of handwritten annotations. The task is clear: turn this report into structured data and feed it into the analytics pipeline.

What would you have done a few years ago? Write a script that slices the PDF into 200 images, feed each page into an OCR engine, then stitch 200 text segments back together — likely losing column headers on cross-page tables in the process, scrambling multi-column reading order, and possibly truncating sentences at page boundaries.

On June 23, 2026, two posts appeared simultaneously on the Hacker News front page: Baidu’s open-source Unlimited OCR (428 points) and Mistral’s OCR 4 (420 points). Two things colliding on the same day, pointing to the same signal: the era of long-document OCR has arrived. But how it arrives — that’s where the two camps gave completely different answers.

An Old Problem: Why Is Long-Document OCR So Hard?

OCR itself is not a new problem. Tesseract has been around for forty years, and cloud vendors’ document recognition APIs have been running for years. But all these solutions hit the same wall when faced with long documents: KV cache explosion.

The rough idea behind using large language models for OCR is: encode the document image into a sequence of visual tokens, and have the LLM “read” the text token by token. For every token generated, the model must look back at the states of all previous tokens — these states are stored in a structure called the KV cache. The longer the document, the more content generated, and the KV cache grows linearly O(N) until VRAM runs out.

The industry’s standard response to this problem is the “page-splitting and stitching” approach mentioned earlier — chop the long document into individual pages, process each one, and manage the flow with an external scheduler. HN user robotswantdata nailed it in the Unlimited OCR discussion: “Developers are forced to write janky code that chops PDFs into individual pages, processes them one by one, and glues the text back together.”

It works, but it’s not true long-document understanding. Cross-page context is lost, tables get fragmented, reading order is scrambled — these are all the costs of “engineering patches.”

Baidu’s Path: Compressing KV Cache to Constant with R-SWA

The core innovation in Baidu’s Unlimited OCR is called Reference Sliding Window Attention (R-SWA) — an attention mechanism that compresses KV cache from O(N) to O(1).

Let’s skip the formulas and use intuition.

Imagine you’re transcribing a book. You keep your eyes on the original text (Reference) while writing down words (Generation). You don’t need to re-read everything you’ve already transcribed every time you write a new word — you only occasionally glance at the last few lines to make sure you haven’t skipped or duplicated anything. The original text stays in front of you the whole time — it doesn’t blur, it doesn’t disappear.

That’s what R-SWA does. It splits the attention pathway into two:

• Global Reference pathway: every generated token always attends to all visual tokens (i.e., the document image) and the prompt — the original text remains sharp forever, cross-page context is never lost.
• Local Generation pathway: every generated token only attends to the most recent 128 generated tokens — short-term memory only needs a sliding window; older token states can be safely forgotten.

The key design choice is that visual tokens don’t participate in “state updates.” They’re only read, never modified. This avoids a classic pitfall of sliding window attention: visual features gradually “blurring” as state updates accumulate, eventually degrading recognition accuracy.

The result: KV cache stays constant throughout the entire decoding process. Throw a 40-page PDF at the model, and it reads the whole thing in one inference pass — no page-splitting, no external scheduler, no need to write that “dirty page-stitching code.”

On the technical side, Unlimited OCR uses DeepSeek OCR as a baseline, retaining its DeepEncoder’s 16× compression ratio, but replaces all attention layers in the decoder LLM with R-SWA. The model has 3B parameters but only activates 500M at inference (MoE architecture), achieving a 93% composite score on OmniDocBench v1.5 — 6 percentage points above the DeepSeek OCR baseline.

The paper is on arXiv, the code is on GitHub (MIT license), and the model weights are on HuggingFace and ModelScope. Classic academic playbook: publish a paper, open-source the code, release the weights, let the community extend it.

Mistral’s Path: Defining Document Intelligence Through a Productized Solution

Mistral released OCR 4 on the same day, a year since their last OCR product update.

OCR 4’s selling point is the completeness of engineering delivery. It upgrades OCR from “extracting text” to “understanding document structure”: the output is no longer just text, but includes bounding boxes (locating each text block’s position on the page), block classification (categorizing headings, tables, formulas, signature areas), and inline confidence scores (per-character or per-word confidence).

It supports 170 languages across 10 language families. A single container handles self-hosted deployment. It scores 85.20 on OlmOCRBench, with a 72% average win rate in human preference tests.

From Mistral’s positioning, OCR 4 is an “ingestion component” in their document intelligence pipeline — paired with Search Toolkit for enterprise search, RAG, and domain retrieval. Bounding boxes let search results be highlighted in the original document; confidence scores drive human review workflows; structured block output makes downstream data pipelines more reliable.

Closed-source, commercial API, pay-per-token — classic product-company playbook.

The HN Comment Section’s Detour: Is Handwritten Address Routing the Real OCR Miracle?

The Mistral OCR 4 comment section took an interesting turn. The top-voted comment came from ericyd:

“I’ve always thought the US Postal Service is a technological marvel. They manage to recognize and route billions of pieces of mail with incredibly non-standard addressing — the same address can be written in several different forms…”

Then idoubtit followed up with an even more extreme story: his father received a letter from Algeria in the 1970s with only three words on the envelope — his name, the city “Créteil,” and “France.” In an era without the internet, without centralized databases, the postal system got it delivered.

To this author, there’s a subtle tension between these stories and Mistral OCR 4’s launch. They remind practitioners: OCR’s ultimate goal is that kind of wildly non-standard, heavily context-dependent recognition task. Handwritten address routing may have been the earliest form of “long-document OCR” — it’s just that the “document” was an envelope, and the “model” was a postal worker’s memory of the neighborhood.

The Fork in the Road: Dimensions of Choice

To this author, Baidu’s Unlimited OCR and Mistral’s OCR 4 represent two different delivery philosophies on the same track.

Choose Baidu’s path, and you get: a paper you can read, a codebase you can modify, a general-purpose attention mechanism you can transfer to other tasks (the paper mentions ASR and translation). The cost: you need to deploy it yourself, tune it yourself, handle the engineering problems yourself. Ideal for teams with engineering muscle, academic research, or scenarios where you need to fine-tune.

Choose Mistral’s path, and you get: an API endpoint, structured JSON output, a document intelligence pipeline that works out of the box. The cost: you can’t see the model weights, can’t modify the internal logic, and you pay per token. Ideal for enterprise deployment, rapid integration, production scenarios that need bounding boxes and confidence scores.

The two aren’t mutually exclusive. A single company’s document pipeline might use both: optimize long-document processing efficiency with the Unlimited OCR approach, then use OCR 4’s structured output for downstream localization and retrieval.

The Real Inflection Point: From “Can Read” to “Can Read in One Shot”

Whichever path you choose, June 23, 2026 is a day worth remembering. Not because two products hit the HN front page on the same day — that’s just the surface. It’s because the OCR field officially crossed a line: from “barely usable” to “zero-shot long-document parsing.”

A year ago, having a single model read a 40-page scanned document in one go was fantasy. Today, it’s the shared starting point for two different technical approaches. R-SWA proved that mathematical innovation in attention mechanisms can open new possibility spaces; OCR 4 proved that structured-output engineering polish can integrate OCR into real production pipelines.

For that engineer facing the 200-page report, the answer is no longer “write a for-loop to split and stitch.” Whether to use the open-source R-SWA approach or call the Mistral API — that’s a different story.