Liteparse

LiteParse (local-first document parsing)

LiteParse turns document files into text the model can read — on the daemon machine, offline, zero cloud dependency. It ships as the @llamaindex/liteparse npm package (CLI: lit) with PDFium and Tesseract bundled inside the package — the digital-PDF and scanned-OCR paths need no external system dependencies.

Upstream: run-llama/liteparse

• skill run-llama/llamaparse-agent-skills. Apache-2.0 (core) / MIT (skill), © LlamaIndex. Vendored as a Prismer built-in.

Capability tiers — what works where

Only Tier 1 is guaranteed present. Tiers 2 and 3 pull large system dependencies that are deliberately not baked into the daemon image — install them yourself, only when the actual input requires it (see below). Do not assume they are already installed.

Tier 1 — PDF (default, ready to use)

lit is available on the daemon. Sanity-check once, quietly:

command -v lit && lit --version    # baked into the image

If (and only if) it is somehow missing, install the package locally — it is ~38MB with the OCR/render binaries bundled and installs in a few seconds:

npm i @llamaindex/liteparse && npx lit --version

Do not rely on the CLI "self-installing on first use" — that path is unreliable (npm permission / cache conflicts). Either it is baked in, or you install the package explicitly as above.

Native text path vs OCR — pick deliberately, cost differs ~10×

• Digital PDF (has an embedded text layer): use --no-ocr. PDFium extracts the text directly — near-instant (~0.35s/page), no OCR. This is the fast, cheap path; prefer it whenever the PDF is computer-generated.
• Scanned / image-only PDF: leave OCR on (default). The bundled Tesseract OCRs each page — ~5s/page, an order of magnitude slower. Only pay this when there is no real text layer.

If unsure which kind you have, run --no-ocr first: empty/garbled output means it's a scan → re-run without --no-ocr to OCR it.

lit parse report.pdf --no-ocr                       # digital PDF → fast native text
lit parse scan.pdf                                   # scanned PDF → bundled OCR
lit parse report.pdf --format markdown -o out.md     # Markdown output to a file
lit parse report.pdf --format json -o out.json       # structured JSON + bounding boxes
lit parse report.pdf --target-pages "1-5,10,15-20"   # page subset (huge speedup on OCR path)

--format accepts markdown (default) or json (adds per-block bounding boxes). Other useful flags: -o/--output, --target-pages "1-5,10", --dpi <n> (render DPI, default 150 — bump to 300 for small scanned text), --ocr-language eng+chi_sim (Tesseract lang codes for the OCR path), --password '****' (encrypted PDFs), -q/--quiet.

Page screenshots (for figures/charts text can't capture)

lit screenshot report.pdf -o ./shots                   # all pages → PNG
lit screenshot report.pdf --target-pages "1,3,5" -o ./shots
lit screenshot report.pdf --dpi 300 -o ./shots         # high-res

Tier 2 — Image files (install ImageMagick on demand)

Parsing standalone image files (PNG/JPG/TIFF/…) needs ImageMagick, which is not in the daemon image. Install it the first time you actually have an image input:

apt-get update && apt-get install -y imagemagick   # Debian/Ubuntu (daemon image)
brew install imagemagick                            # macOS (local dev)
lit parse diagram.png --format markdown

If ImageMagick can't be installed (no network / no apt), report ImageMagick unavailable and stop — don't fabricate the image's contents.

Tier 3 — Office documents (install LibreOffice on demand)

DOCX / XLSX / PPTX / ODT conversion needs LibreOffice (~1GB), which is intentionally not baked into the daemon image. Install it only when you genuinely need to parse an Office file (it's a big download — don't do it speculatively):

apt-get update && apt-get install -y libreoffice   # Debian/Ubuntu (daemon image)
brew install --cask libreoffice                     # macOS (local dev)
lit parse deck.pptx --format markdown

If LibreOffice can't be installed, say so and ask the user for a PDF export of the document instead of guessing.

A shared cloud parse service for heavy formats (offloading Office / hi-res OCR to a hosted backend so agents don't install 1GB deps) is a future TODO — it is not running today. Don't route to a cloud OCR endpoint.