EPecho-pdf docs
CLI

One command surface, same VL-first core path.

The local CLI centers the same mainline path as the package API: document metadata, page access, render reuse, and provider-backed semantic structure.

Zero-config primitives

echo-pdf document ./sample.pdf
echo-pdf structure ./sample.pdf
echo-pdf page ./sample.pdf --page 1
echo-pdf render ./sample.pdf --page 1

Provider-required semantic setup

# Cloud provider example
echo-pdf provider set --provider openai --api-key $OPENAI_API_KEY
echo-pdf model set --provider openai --model gpt-4.1-mini
echo-pdf semantic ./sample.pdf

# Local OpenAI-compatible example (Ollama / LM Studio / vLLM / LocalAI)
echo-pdf provider set --provider ollama --api-key ""
echo-pdf model set --provider ollama --model llava:13b
echo-pdf semantic ./sample.pdf --provider ollama

# LaTeX-first table and formula extraction (provider-required)
echo-pdf tables ./sample.pdf --page 1
echo-pdf formulas ./sample.pdf --page 1
echo-pdf understanding ./sample.pdf --page 1

Supported boundary

  • document, structure, page, and render work without provider configuration
  • semantic requires a configured provider and model before it runs
  • the provider may be a local OpenAI-compatible server such as Ollama, LM Studio, vLLM, llama.cpp, or LocalAI
  • slow local vision models may need a higher provider timeoutMs in echo-pdf.config.json
  • legacy document ... alias trees are not part of the supported docs path
  • workspace-writing local runs stay the mainline workflow

What stays out of the way

  • no docs-site service backend
  • no MCP or remote command families
  • no hosted dashboards or remote playgrounds
  • no domain-specific command families

This is still a local component CLI.

The supported CLI is intentionally local-first and writes workspace artifacts on the current machine. Remote service and MCP command surfaces are not part of this product boundary.