Same answers from your AI. For less money and far less energy.
Every time you paste a whole book into an AI, it re-reads the entire thing from scratch — burning computing power, money, and electricity you've already spent once before. Estravon transcribes the clean text a single time, right inside Zotero, so every use after that costs a fraction of the energy. Read it once, not every time.
The problem.
More and more of us now bring books into conversations with AI — asking ChatGPT or Claude to help us think through a chapter, compare arguments, or draft from a source. But a PDF is a locked box. You can't cleanly copy from it. Scanned pages won't select. Footnotes and tables turn to nonsense when you paste them. So you end up dragging a heavy file into a chat window and hoping for the best. And a few weeks later, the harder question: which book was that? Which edition? Which pages did you actually feed the model? The material behind your research scatters across downloads folders, chat windows, and screenshots — impossible to trace back.
The heart of it.
The material behind your AI research should be as traceable and well-kept as the citations in your bibliography.
For years, Zotero has been where careful readers keep their sources in order — every book, paper, and citation in one trusted, searchable library. Now that those same sources feed our AI conversations, they need that same order.
Estravon makes Zotero that home. The clean text of a book lives right beside the book itself — synced, backed up, and logged. So the sources feeding your AI stay traceable, safe, and organized, in the exact place your references already are.
How it works.
Right-click a book in Zotero.
Choose a chapter, a section, or a page range.
Estravon transcribes it into clean Markdown.
Readable, searchable, and ready to paste into any AI tool, or to open in Obsidian, Zettlr, or your notes.
The result attaches to the Zotero item.
Every extraction is written to a log note — so you always know exactly what came from where.
That's the whole workflow. One right-click, and the text is yours — filed where it belongs.
Why researchers use it.
Traceable.
Every transcription is logged with its source and page range, right there on the item. No more guessing what you fed the model, or hunting for the file later.
Safe and private.
When you use our hosted service, your files are processed on EU-based servers, deleted right after, and never used to train AI models or sold to anyone. If you self-host, they never reach us at all — and with the local engine, they never leave your machine.
Organized.
The text lives inside Zotero — attached to the source, synced across your devices, backed up with the rest of your library. Not in a lost download folder.
Built for real academic books.
Long books, dense chapters, and older scanned volumes that ordinary copy-paste simply can't handle. Estravon is purpose-built for exactly this material.
Pay only for what you use.
Buy a credit pack and start transcribing. You can choose between 3 Pay as you go packages.
Efficient by design.
Extract once, reuse forever — the sensible way to work, and a lighter footprint on both your wallet and the grid.
The version we don't make money from.
Everything above describes our hosted service: you send us a PDF, we run it, we delete it. That arrangement asks you to trust us. So we also built the version where you don't have to. The open-source backend now ships with an optional engine called MinerU, by opendatalab, that runs entirely on your own computer. No API key. No account with us or with anyone else. No payment. Your PDF stays with you.
We should be straight about what that costs you. It is slow — on our laptop is around twelve seconds a page, so a sixty-page chapter takes about twelve minutes rather than a few seconds. It wants 16 GB of memory to be comfortable, and it will refuse to start on a machine that hasn't got the room. The install is several gigabytes. Mathematical notation comes out worse than it does from our hosted pipeline.
we believe that “trust us” is a weaker promise than “you don't have to.”
Read it once, not every time.
Every time you drop a whole book or a heavy PDF into an AI, the model has to read the entire thing from scratch — and that takes real computing power. Real money, and real electricity, every single time you do it. Estravon changes the shape of that. You extract the clean text once. From then on, every time you use it — this week, next month, in whichever AI tool you like — it's the light, cheap version. You pay the heavy cost a single time instead of paying it over and over.
It saves money.
A one-time transcription costs pennies a page. Re-feeding the same locked PDF into a metered AI, again and again, does not. Do the expensive part once and reuse the result forever.
It saves energy — and not by a little.
When an AI reads a book or a scanned page, it doesn't read it as text — it reads it as a picture, which takes several times more computing power than plain words. Convert that book to clean text once, and every later use can take as much as 60–80% less work for the AI to read it in. Less money. Less electricity. Every single time. Multiply that across a whole library, a research group, a whole community, and “convert and read once” instead of “re-convert every time” is real power saved off the grid.
The scale of it.
A normal text question to an AI is about the energy of running a microwave for few seconds. But reading whole books and images in costs well above that, by Google's own figures. Estravon lets you pay that heavier cost once, then coast on the light version forever after. This isn't a guilt trip or a green sticker. It's just the sensible way to work: use the power once, keep the result, and stop asking the machine to re-convert the same book forever.
1. Google, Measuring the environmental impact of AI inference one year ago (Aug 2025): the median Gemini text prompt uses ~0.24 Wh — about a microwave for one second — and states plainly that this covers text only; image, video, and document prompts use substantially more.
2. MIT Technology Review (Aug 2025): independently notes that “feeding dozens of books into Gemini” is the kind of prompt that costs well above the median, and that the figure excludes image/video generation.
3. The 60–80% figure is the reduction in the reading/ingestion step for AI assistants that rasterise PDF pages — not a guaranteed cut to total query energy, and not universal. Anthropic's own worked example shows a 3-page PDF costs ~1,000 tokens as plain text vs ~7,000 in full visual mode (7× ratio). A 3–5× reduction is a 60–80% cut. The claim is stated as “as much as” and earns its weight through reuse at scale, not a per-user scare number.
You already trust Zotero to keep your reading in order. Now let it keep the sources behind your AI in order too.
The technical picture.
How frontier AI providers actually read PDFs — and why a dedicated OCR pass is a different thing entirely. - Jul.'26
How each provider ingests a PDF.
Every major AI provider that accepts PDFs converts each page to an image before processing it — then bills you for that image. The table below shows what that costs and what it trades away.
| Provider | Accepts PDF? | How it converts | Cost (tokens/page) |
|---|---|---|---|
| Anthropic (Claude) | Yes — API + claude.ai | Each page → image + extracted text, both fed to the model | 1,500–3,000 text + image on top |
| OpenAI (GPT) | Yes — Responses API + Chat Completions | Each page → extracted text + page image, both in context | Multiples of plain text; same dual approach as Anthropic |
| Google Gemini | Yes — native | Each page → image at a flat ~258 tokens/page; Gemini 3 also includes natively embedded text | ~258 tokens/page (low tier) up to 1,120/page (high); cheapest, but fidelity trades off |
| xAI Grok | Partial | Attaching a file activates agentic retrieval (RAG) over the doc — not full-context ingestion | Variable — only retrieved sections loaded; low per-query cost, selective reading |
| DeepSeek (V3/R1) | Core text models: No | Text models take text only — you extract yourself. V4 added native image input. | ~90 tokens/image (V4); text extraction mandatory for V3/R1 |
Why “fixed tokens per page” is real — and why it isn't OCR.
Converting to images is how every LLM “reads” a PDF. Text tokens count characters; image tokens count pixels. When an image is tokenised, the picture is scaled to a fixed canvas and divided into a fixed grid of patches, and the token count is the number of patches — a function of pixel dimensions, not of how much text is printed on the page. A blank page and a page crammed with 6-point footnotes photograph to the same number of pixels, so they cost the same. With image-based ingestion, page density does not cost more tokens — it costs accuracy. Tiny characters at low resolution still cost the same fixed amount, but they blur below the patch grid and get misread. An LLM “reading” a PDF is a resolution-bounded, single-pass, black-box vision glance — its accuracy on your hardest pages silently depends on a setting most users never touch. A purpose-built OCR (Mistral / Datalab) re-reads the pixels at full fidelity and returns a clean, inspectable, correctable Markdown artifact — not an ephemeral read. An LLM's in-context PDF read and a dedicated OCR pass are not the same operation. The first is a per-session, per-vendor, resolution-limited glance you cannot correct; the second is a one-time, auditable transcription you own.
Equations
Purpose-built OCR can invoke LaTeX cleanup and inline math detection. An LLM's resolution-bound guess cannot be audited.
Tables
Dedicated table/layout models handle structure. Google's own docs warn that vision “isn't precise at locating text or objects.”
Scanned pages
force_ocr throws away a corrupt text layer and re-OCRs from pixels. An in-context vision pass quietly misreads the small type.
Does “markdown is cheaper” generalise across providers?
They have identical text+image mechanisms. The 3–7× token premium for PDF-in-context holds. Same 32 MB / ~100-page-class request ceilings apply.
At ~258 tokens/page (older models) a Gemini PDF page can be cheaper than ~500–1,000 tokens of Markdown. But fidelity: the low/medium tiers are downscaled images, and Google's own docs warn of hallucination on handwriting and imprecise spatial reasoning — dense pages need the high tier (more tokens) to be read reliably.
Attachment handling is agentic retrieval — Grok never loads the whole book into context, so per-query token cost is low by construction. But RAG reads selectively, not linearly — the wrong model for careful, complete scholarly reading of a chapter.
Core text models can't take a PDF at all, so extracting to Markdown isn't an optimisation — it's the only way to use them.
Extract once, use anywhere, at any provider, forever.
What this means for your research workflow.
Extract once, use anywhere.
The Markdown is tool- and vendor-agnostic. You OCR a book a single time instead of re-paying — in tokens or in on-the-fly OCR quality — every time you open it, in every tool, in every session. The figure of merit is not the per-read ratio alone but read-premium × number of consultations × number of tools.
Fidelity you control.
A purpose-built OCR on a scanned academic book beats a generalist LLM's in-context vision, which every provider's docs concede degrades on tables, equations, and handwriting. You get a clean, inspectable, correctable artifact — not a black-box read that varies by model and silently drops a footnote.
Portability, persistence, greppability.
Version control. Annotations. Diffs. None of these exist for a PDF sitting in a context window, on any provider. A Markdown file in Zotero is yours — searchable, citable, and independent of whoever you're paying to run the model this month.
No vendor lock-in, and compliance by construction.
Your library isn't hostage to one vendor's PDF pricing or data-residency posture.
Estravon turns a book into a clean Markdown asset once — then it's yours, in any tool, at any provider, forever. No re-OCR, no re-billing, no lock-in.