How is this different from sending the whole PDF to OCR?

Whole-document OCR bills every page including ones with readable text. Doc-router extracts those locally in-process and only sends pages the judge flags, then merges both halves in page order.

When does the Jev judge beat the local heuristic?

Jev looks at per-page evidence and catches cases rules miss, such as a bad pre-existing OCR layer, watermark-only text, or a broken ToUnicode map. The heuristic is the offline default.

What setup is needed to try it on my own PDFs?

Build with cargo build --release. Classify needs no keys or network. Run needs LITELLM_API_KEY, a --base-url gateway, an OCR model name, and optionally TYPESAFE_API_KEY for the Jev judge.

Are the reported time and cost savings reproducible?

The README reports a 155-page run where routed pages billed fewer pages and finished faster, with fewer missed OCR pages than a rules judge. Re-run the bench binary on your own corpus to confirm.

What are the measured savings over OCR-every-page?

On 19 documents and 155 pages with mistral-ocr-latest through a live LiteLLM gateway, three runs each: routed billed 87 pages instead of 155 and made 13 API requests instead of 19, finishing 1.72x faster at 20,666 ms versus 35,578 ms and 1.74x cheaper at $0.1783 versus $0.3100.

What is the trade-off versus a rules-based judge?

The judge costs about 2.5% of the OCR bill it authorises, and a cheaper bill is not automatically a better result. The routed run left 9 pages that needed OCR without it, while the rules-based judge missed 28, so the rules judge is cheaper but misses roughly three times as many pages.

Can I call it from Python?

Yes. It is Rust throughout but ships PyO3 bindings if you would rather drive it from Python, and it is a port of LiteLLM's Python document router with the same classification, decision table, and metadata keys, so a document routed by either lands on the same model.

CommunityJev Tools & CLIs

Doc Router

Rust CLI that checks each PDF page for a usable text layer, extracts text pages locally, sends only the rest to an OCR model via LiteLLM, and merges a page-ordered result.

See highlights

Open github.com

Stars: 30
Language: Rust
License: MIT
Published by: Community
Author: misbahsy
Last verified: Oct 2026

misbahsy/doc-router

User repository on GitHub

View on GitHub

A Document OCR Router to help route pages based on content.

Forks: 6
Last pushed: Updated Sep 2026

Repo stats from the GitHub API, cached Oct 2026.

About this project

Don't pay to OCR a page that already has text on it. Most PDFs are not all-scan or all-text. A contract has two signature pages scanned in the middle. A report's appendix was photocopied. An invoice batch has every third document off a flatbed. Hand the whole file to a hosted OCR model and you pay for every page — including the ones you could have read for free, instantly, with no network call.

Quoted from the project's README. Read the full README.

Tagscommunity jevbest catalog-import

Works forJev for Classification Jev for Routing Jev for Evaluation

Used inJev for Software & DevTools

Languages: Rust

Highlights

Page judge is Jev answering whether a page needs OCR, as one swappable trait with a local heuristic default.
Uses pdf-inspector for per-page structure evidence and lopdf for splitting pages for providers without a pages filter.
Classify previews routing with no keys or network; run merges local extraction with OCR output in page order.
Bench binary compares heuristic versus Jev on your corpus with cost-per-page and token-cost inputs.

Watch out

Needs Rust 1.88+ and a LiteLLM gateway with an OCR model for real runs; without a Jev key it uses the local heuristic. Copy reviewed against the repository README on 2026-10-04, not from running it.

Questions about this entry

Short answers drawn from the linked project or page.

More Jev resources like this

jevclip

Video tool where Jev scores subtitle segments and code assembles a short highlights cut plus a de-watered full cut with timestamped summaries.