crunch.md — anything to Markdown

crunch.md

Anything to Markdown. PDF, DOCX, PPTX, XLSX or a URL in — clean, structured, model-ready text out.

crunch-core · deterministic
0 / 1 FREE TODAY
no file / free tier

Drop a file, or paste a URL

Drop it.

PDF · DOCX · PPTX · XLSX · XLS · HTML · CSV · MD

Drag anywhere in the frame, or O

Conversion

Measurements

0.00 SECONDS · WORKING
NATIVE FILE — tok
MARKDOWN — tok
0 STRUCTURE SCORE · /100

Markdown output

Rendered Markdown

RENDERED

Raw Markdown

RAW

Conversion failed

ready · waiting for input

Free · one conversion a day, no account. Today’s is still yours.

WHERE IT RUNS

Serious volume runs on your hardware, next to the documents.

This page converts one document at a time so you can see exactly what the engine does with yours. An estate is not converted through a browser: it is converted by the same engine, running inside your own network, across as many cores as you point at it.

LOCAL ENGINE BUILT · OPEN-SOURCE RELEASE NEXT

The Python engine on your own servers. Nothing is uploaded, and the output is deterministic — same bytes in, same Markdown out.

MCP SERVER BUILT · OPEN-SOURCE RELEASE NEXT

A crunch tool inside your agent loop, on stdio or streamable HTTP. The agent converts a document before it reads it, so the raw file never enters the context window.

HTTP API LIVE NOW

POST /v1/crunch. One synchronous call, Markdown and a structure map back. Same engine, same numbers as the panel above.

THIS PAGE LIVE NOW

The demonstration. Drop one document and watch the engine work on it, with the real measurements from the real conversion.

On the CLI and the MCP server: both are finished and both run on your own machines. They are not on PyPI or npm yet, and we would rather say that than print a command that 404s on the first thing you try. Publishing them is the open-source release — until it lands, the API above is the same engine with the same numbers, and an evaluation of the local build is a conversation rather than a download.

Throughput, per core

Conversion is CPU-bound and parallel across documents, so the honest unit is a page per core and you multiply by the cores you have. There is no GPU in this path — a DGX-class box converts an estate with its accelerators idle, and a plain 128-core server does it just as fast.

6 ms A TEXT-LAYER REPORT · PER PAGE, PER CORE
513 ms A DENSE DESIGN-HEAVY PDF · PER PAGE, PER CORE

The 86× between them is the document, not the machine — tables, columns and figures are the expensive part, and a page of plain prose is nearly free.

Pages converted per hour, by core count and document class
CoresText-layer pages/hourDense pages/hour
84,800,00056,140
3219,200,000224,561
12876,800,000898,246

10M pages · one 32-core server · one weekend

44.5 hours at the worst case this engine has: every page dense-class, tables and columns all the way through. A real estate is mostly text-layer, so the same job is an overnight run. A million pages finishes in under five hours on the same server even if every page is dense.

crunch.md per page, per core · median of 3 runs · conversion is CPU-bound and parallel across documents, so it scales with cores and uses no GPU · read 2026-09-07

THE CASE

Markdown is the format your estate can actually be read in.

Most of a SharePoint estate has no native path into a model at all, and the part that does hits a hard page wall we have now hit from the outside. Where a comparison is possible it is a price, and that price is a range rather than a number — 11.1% to 73.1% fewer input tokens a page depending on what the document is. Five claims below, each with the figure it rests on, the spread behind that figure, and where both came from.

01 · RESIDENCY

Your documents never leave your network.

Verified in the source rather than asserted in a policy document: across the whole engine, the only module that opens a socket is the URL fetcher you explicitly hand a URL to. PDF, DOCX, PPTX and XLSX extraction, normalisation and Markdown emission make zero network calls. Run it inside your perimeter and conversion costs you nothing but your own compute.

Where pages go, by conversion path
PathEgressDefault
Every text-layer format — PDF, DOCX, PPTX, XLSX, HTMLNoneOn
Local OCR (Tesseract)NoneAvailable
Azure container (read-4.0), self-hostedYour private networkOpt-in
Azure, Google or Mistral cloud OCRThird partyRefused unless enabled

The engine runs entirely inside your network — every format, including scanned pages, because the OCR engine is local too. Cloud OCR is available if you want it, off by default, and the conversion tells you which pages used it.

crunch.md verified in the source, not asserted · the only module that opens a socket is the explicit URL fetcher, which re-checks for SSRF on every redirect hop · read 2026-09-07

Scanned pages stay inside too.

OCR ships with a local engine — Tesseract, with seven languages installed: Hungarian, German, English, Polish, Romanian, Czech, Slovak. It reads page rasters on your own CPU and sends nothing anywhere. An enterprise with its own trained language data points the engine at that instead.

A cloud provider is refused before it is authenticated.

Azure, Google, Mistral and an engine you already run yourself all plug in behind one provider protocol, and a provider must declare its egress to be selectable at all. The policy defaults to local-only, so a cloud call is refused at the door rather than audited afterwards.

The result says where the pages went.

Whichever engine ran is recorded on the conversion, in the structure map and in a warning written for a person — so an operator in a regulated environment can prove where a page was read, instead of citing a policy. The optional remote token counter is separately gated behind a flag and a credential, and is off unless you switch it on.

It sizes the gap for you.

The engine fails loudly, per page, and never invents text for a page it could not read. Point it at your estate. It converts everything with a text layer and tells you precisely which pages don’t have one. That is a survey of your estate, from your estate, before anyone commits to an OCR budget.

02 · THE FORMATS WITH NO NATIVE PATH

Most of an estate cannot be uploaded at all.

Anthropic's Files API does not accept DOCX, PPTX or XLSX as document blocks. Its own documentation says to convert them to plain text first. So for the majority of what sits on a twenty-year SharePoint, conversion is not an optimisation you might take — it is mandatory, and the only question left is whether the structure survives it.

DOCX NO DOCUMENT BLOCK
PPTX NO DOCUMENT BLOCK
XLSX NO DOCUMENT BLOCK

Converted badly, they arrive as a wall of words with the grid taken out. Converted well, the deck keeps its slide titles, the workbook keeps its sheets and its headers, and the specification keeps its numbering.

Anthropic Files API — DOCX, PPTX and XLSX are not accepted as document blocks; the documentation says to convert them to plain text source ↗ · read 2026-09-07

And for PDF, which does upload: the window holds more than twice as many pages.

Pages that fit in a context window, native against crunched
WindowModelsNativeCrunchedOnly works crunched
1MFable 5.1, Opus 5, Sonnet 5358 pp755 pp359–755 pages
200KHaiku 4.580 pp211 pp81–211 pages

crunch.md measured over 16 PUBLIC PDFs, 861 pages, counted with Anthropic messages.count_tokens · corpus manifest and fetch script in the repo, so anyone can re-run it · read 2026-09-07

Anthropic PDF limits — 600 pages a request (100 below a 1M window), 32 MB a request; long context carries no per-token price premium source ↗ · read 2026-09-07

There is a page wall as well as a token wall, and we hit it from the outside.

600 pages a request, and 100 once the context window is under 1M. That is documented — but it is also now measured: three of the 16 documents in our corpus were refused outright as native uploads on Claude Haiku 4.5, and all three counted without complaint as Markdown. This is not a saving. It is the difference between working and not working.

400 invalid_request_errormessages.0.content.0.pdf.source.base64.data: A maximum of 100 PDF pages may be provided.
  • 194 pp Protocol specification rfc9110 refused natively · 126,739 tok as Markdown, inside the 200K window it was refused from
  • 114 pp Tax instruction booklet, three columns irs-i1040gi-2023 refused natively · 248,539 tok as Markdown
  • 102 pp Financial review, charts and tables bis-quarterly refused natively · 88,868 tok as Markdown, inside the 200K window it was refused from

crunch.md measured from the outside: three corpus documents of 194, 114 and 102 pages refused as native uploads on Claude Haiku 4.5, and all three counted without complaint as Markdown · read 2026-09-07

And a 32 MB cap on the request.

A dense PDF can exhaust the context window before it ever reaches the page limit, which is why a binder that "should fit" does not. The Markdown of the same binder is a fraction of the bytes.

Long context is not billed at a premium.

A 900k-token request costs the same per token as a 9k one, so this is a capacity argument rather than a pricing one: what the window decides is how much of your document the model can hold at once. §03 is where the price comes in.

03 · TOKENS

A PDF page pays twice.

Send Claude a PDF and it charges you for the text it pulls out and for a rendered image of the page. Markdown drops the image. Same words, same headings, same tables — one bill instead of two, on every page, on every pass.

NATIVE PDF · 1 page 2,792 tok
1,224 extracted text 1,568 page image
CRUNCHED MARKDOWN · 1 page 1,323 tok
words, headings, tables. No image.

53% fewer input tokens a page — 1,469 tokens a page that stop being billed. Page-weighted mean over 16 public documents; per document it runs 11.1% to 73.1%, and the table below says which is which.

Against what, exactly. A native document upload on Claude — Fable 5.1, Opus 5, Sonnet 5 — where a PDF page is charged as a page image plus its extracted text. That is the comparison every figure on this page is stated against.

53% is a corpus mean. Your document type decides where you land in it.

The same 16 documents, one row each, nothing averaged away and nothing left out — the worst document in the corpus is in this table. The median document reduces 55.4%; the floor is 11.1% and the ceiling is 73.1%. That spread is not noise. It is document type, and it is the part of this measurement you can actually apply to your own estate.

the notch in every bar is the published corpus mean, 53% — bars past it beat the headline, bars short of it do not

63.4% – 73.1% Prose under headings

Reports, memos, standards, briefs, specifications — pages someone wrote to be read. Little text under a full-page picture, so dropping the picture removes most of the bill.

  • Scanned technical memo, typewritten 73.1% nasa-tm-x-3181 · 23 pp · 2,095 → 564 tok/pp
  • Legal brief, scanned court pages 68.2% scotus-brown · 14 pp · 2,342 → 745 tok/pp
  • Security framework standard 67.9% nist-csf2 · 32 pp · 2,287 → 733 tok/pp
  • Protocol specification 63.6% rfc9110 · 194 pp · 2,405 → 876 tok/pp
  • Technical guideline, long prose 63.4% nist-sp800-63b · 80 pp · 2,425 → 888 tok/pp

44.6% – 59.6% Mixed pages

Statutes, statistical releases, charts and tables, research papers — and anything not in English, which tokenises worse on both sides of the comparison.

  • Statute, scanned session law 59.6% statute-79-pg437 · 10 pp · 2,814 → 1,138 tok/pp
  • EU regulation (GDPR), English 59.3% eurlex-gdpr-en · 88 pp · 2,792 → 1,136 tok/pp
  • Central-bank statistical release 56.4% fed-h41 · 11 pp · 2,602 → 1,135 tok/pp
  • Financial review, charts and tables 54.4% bis-quarterly · 102 pp · 2,532 → 1,155 tok/pp
  • Regulation, a single page 52.5% cfr-40-1-1 · 1 pp · 3,007 → 1,427 tok/pp
  • Research paper, long 51.7% arxiv-gpt3 · 75 pp · 2,784 → 1,345 tok/pp
  • EU regulation (GDPR), Hungarian 46.2% eurlex-gdpr-hu · 88 pp · 3,605 → 1,941 tok/pp
  • Research paper, two columns of mathematics 44.6% arxiv-attention · 15 pp · 2,557 → 1,415 tok/pp

11.1% – 38.3% Dense grids and forms

Three-column instruction booklets, coordinate-positioned forms, equation-heavy papers. Reproducing a grid as Markdown costs close to what the page image saves. Better learned here than after converting an estate.

  • Research paper, equations and figures 38.3% arxiv-resnet · 12 pp · 3,562 → 2,197 tok/pp
  • Tax instruction booklet, three columns 31.3% irs-i1040gi-2023 · 114 pp · 3,614 → 2,483 tok/pp
  • Tax form, field labels on a grid 11.1% irs-f1040-2023 · 2 pp · 3,320 → 2,952 tok/pp

crunch.md all 16 documents, one row each, native and crunched totals · nothing averaged away, nothing left out — the worst document in the corpus is in this table · read 2026-09-07

What you save is the page image, and it barely moves.

Dropping the picture is the whole mechanism, and the picture is a flat charge — it does not care what is printed on the page. 13 of the 16 documents save between 1,365 and 1,676 tokens a page, inside 15% of the 1,568-token page image, while their percentages run 38.3% to 73.1%. The percentage moves because the other half moves: a sparse memo has little text, so the constant is most of its bill; a dense booklet has a lot, so the same constant is a small share of it.

The 3 that save less — 368 to 1,141 tokens a page — are the densest layouts in the corpus: a two-column paper of mathematics, a three-column instruction booklet and a coordinate-positioned tax return. Rebuilding a grid as Markdown costs close to what dropping the picture saved.

So estimate your own estate in tokens, not in percent: 1,469 tokens a page stop being billed across this corpus, and 13 of the 16 sit within a fifth of that. What your percentage is depends only on how much text was sitting under the picture.

The same statute, in two languages.

The GDPR is in the corpus twice — the English and the Hungarian text of one regulation, the same 88 pages. English reduces 59.3%. Hungarian reduces 46.2%. Same pages, so the same page image: 1,613 tokens against 1,610, measured.

What differs is the text, and it differs on both sides of the comparison. The same statute costs 1.69× as many tokens to extract in Hungarian (1,995 a page against 1,179) and 1.71× as many to write as Markdown. So the flat image charge is a smaller share of a Hungarian page's bill, and dropping it saves a smaller percentage.

The tokens hardly notice: 1,656 a page saved in English, 1,665 in Hungarian. If your estate is not in English, that is the number to plan with: the lower percentage is arithmetic, not a worse conversion.

crunch.md the same regulation, both language versions, same 88 pages, same counter · per-document rows in docs/measurements/native-token-cost.md · read 2026-09-07

crunch.md measured over 16 PUBLIC PDFs, 861 pages, counted with Anthropic messages.count_tokens · corpus manifest and fetch script in the repo, so anyone can re-run it · read 2026-09-07

Anthropic PDF support — the system converts each page into an image, and extracts the text alongside it source ↗ · read 2026-09-07

Anthropic vision — a page image is billed in 28×28 pixel patches, capped at 1,568 visual tokens on the standard tier source ↗ · read 2026-09-07

On Gemini, send the PDF.

Google bills a PDF page at a flat 258 tokens and Gemini 3 does not separately charge for the text it extracts, so our Markdown costs about 5.1× more there. Route by model: crunch for Claude, upload natively for Gemini. On Gemini what crunch.md buys you is structure, and §05 is where that argument lives.

Google document processing — each PDF page counts as a flat 258 tokens, and Gemini 3 does not separately charge for the text it extracts source ↗ · read 2026-09-07

1,568 is measured, not assumed.

Subtract a plain text dump from the native cost of the same document and what remains is the page image: a median of 1,569 tokens a page on Opus 5 and 1,568 on Haiku 4.5 — the same number on both sides of a supposed visual-tier boundary. So the high-resolution 4,784 figure does not describe a rendered PDF page. The cheapest check needs no arithmetic at all: a one-page PDF in the corpus costs 3,007 tokens in total on Opus 5, and a page cannot cost less than its own image. Anthropic's worked example implies about 2,333 tokens a page — the same order as the 2,792 we counted.

crunch.md measured page-image cost: native document cost minus a plain text dump of the same pages, same model · median 1,569 on Opus 5 and 1,568 on Haiku 4.5 · docs/measurements/native-token-cost.md · read 2026-09-07

Markdown is not free, and it is not meant to be.

Pipes, hashes and dashes cost 1.07× a bare text dump — 1,323 tokens against 1,239. There is no saving against plain text and we do not claim one: what the extra buys is the grid, the heading tree and the numbering, and that is what turns an extraction into something a model can navigate.

04 · MONEY

One pass over the estate.

Input tokens only, at published list prices, on the model you pick. The multiplication is printed underneath so you can check it — and it is the cost of reading the corpus once. It applies the corpus mean to your page count; if your estate is mostly reports or mostly forms, §03 says how far either way that moves.

1,000,000

List price for input tokens, standard rates. Output is the same either way, so it is not counted here.

AS NATIVE DOCUMENT UPLOAD $13,960 1,000,000 × 2,792 tok = 2,792,000,000 tok × $5.00/M
AS CRUNCHED MARKDOWN $6,615 1,000,000 × 1,323 tok = 1,323,000,000 tok × $5.00/M

YOU KEEP $7,345 on every pass

Anthropic published list prices, input tokens, standard (non-batch) rates · a snapshot, they move source ↗ · read 2026-09-07

crunch.md measured over 16 PUBLIC PDFs, 861 pages, counted with Anthropic messages.count_tokens · corpus manifest and fetch script in the repo, so anyone can re-run it · read 2026-09-07

AND A CORPUS IS NOT READ ONCE

  • Document Q&A over the corpus
  • Contract and filing analysis
  • Agent workflows that re-open files
  • Fine-tuning context preparation
  • Evaluation runs, every time the suite is run

Every re-index, every model change, every evaluation run reads the corpus again, and the saving lands again with it. We publish no multiplier — there is no honest figure for how often your estate is re-read — so the number above is one pass and the multiplication is yours.

Batch halves both sides.

A batch API halves the native column, the crunched column and the saving alike. The ratio between them does not move, so the figure above holds at either rate.

Prompt caching does not close the gap.

It scales both columns proportionally rather than closing the distance between them, and its lifetime is minutes to an hour — so a corpus re-read days apart never hits it at all.

Where this arithmetic does not apply.

Bulk vector indexing is the exception: an embedding pass takes text only, with no page image, so Markdown costs more there than a plain extraction. Index from the text, read from the Markdown. And on Gemini the ledger runs the other way: a million-page pass costs about $2,130 more crunched than native. Route by model.

05 · STRUCTURE

The table survives, so the answer does.

Fewer tokens is the argument people check. This is the one that decides whether the answer is right. Headings, tables, lists and footnotes come through as headings, tables, lists and footnotes — so a chunk stays citable, a number stays attached to its row, and an answer can be traced back to the place it came from.

TEXT DUMPcolumns gone
Tenor EUR USD GBP
1 year 3.10 4.45 4.20
5 year 3.75 4.60 4.35
10 year 4.05 4.72 4.48
CRUNCHED MARKDOWNcolumns kept
| Tenor   | EUR  | USD  | GBP  |
| ------- | ---- | ---- | ---- |
| 1 year  | 3.10 | 4.45 | 4.20 |
| 5 year  | 3.75 | 4.60 | 4.35 |
| 10 year | 4.05 | 4.72 | 4.48 |

Illustration — the same rows, formatted two ways. Not a measurement.

This is the argument that holds on every model, at every price, including the ones where the token count runs against us. A rate, a dose or a tolerance that has come loose from its row is not a formatting problem — it is a wrong answer with a citation attached.

  • Headings give a chunker a place to cut. Chunks stop starting mid-sentence.
  • Tables keep a value in its row and its column, so a figure can be quoted safely.
  • Numbering stays nested, so clause 8.2.1 still knows what it hangs off.
  • Lists stay enumerable, so "how many steps" has an answer.
  • Footnotes stay attached, so a caveat travels with the claim it qualifies.

HOW WE MEASURED

16 public multi-page PDFs — arXiv papers, NIST standards, an RFC, the GDPR in two languages, IRS forms, a Federal Reserve statistical release, scanned court and statute pages — 861 pages in total. Not our own documents: public ones, listed by URL and sha256 in the repo, so the corpus is something you fetch rather than something you take our word for. Token counts come from Anthropic messages.count_tokens, Claude's own counter for the model being quoted, not a third-party tokenizer or a heuristic. Mean 1,224 tokens of extracted text a page in, 1,323 tokens of Markdown out. Every one of those 16 documents is printed on this page with its own result, in §03, rather than summarised into a single percentage: a mean over an arbitrary corpus is not a benchmark result, and the worst document in the corpus is in the table with the best. Speed is stated per page per core — 6 ms for a text-layer report, 513 ms for a dense design-heavy one, a 86× spread that belongs to the document rather than the machine. Run the whole thing yourself: crunch bench.

Every figure on this page is either ours and reproducible from that corpus, or a named vendor's with the URL and the date we read it. Prices are a snapshot and they move; the date under each one is when we last checked it. Last checked 2026-09-07.

WHO THIS IS FOR

Six industries, and the document that actually lands on the desk

A token count is abstract until it is your document. Pick the desk you recognise. The panel says what arrives, what it costs to hand a model the file as it is, which part of the structure a plain text dump destroys, which surface fits the workflow — and the one thing crunch.md will not do for you on that desk.

Financial services Reports, prospectuses, KYC packs 02 / 06
THE DOCUMENT

A 200-page prospectus: rate tables by tenor and currency, a fee schedule, risk factors, and four pages of footnotes that every figure above depends on.

WHAT IT COSTS
558K tok 265K tok
200 pages as a native upload, at 2,792 tok a page — 558,400. Crunched, at 1,323 — 264,600.

One document, and the page images alone outweigh everything else you were going to put in the request. Multiply by the shelf, then by every re-read of it.

WHAT SURVIVES
THE RATE TABLE

Every cell keeps its row label and its column header. In a flat dump 3.75 arrives as a bare number and the model infers which tenor and which currency it belonged to — the one thing on the page nobody may infer.

WHERE IT RUNS
CLI

Run the engine inside the perimeter, on your own servers. The base path is deterministic and makes no model call, so the prospectus never leaves the building in order to become Markdown, and the same bytes always produce the same output.

THE CATCH

A cell merged across two columns is flattened into one. The conversion does not hide it: the response carries a warning naming the table, so you know which one to check by eye.

Health & life sciences Protocols, submissions, labels 03 / 06
THE DOCUMENT

A 90-page clinical protocol: inclusion and exclusion criteria, a schedule-of-assessments grid, and a dosing table banded by weight.

WHAT IT COSTS
251K tok 119K tok
90 pages as a native upload, at 2,792 tok a page — 251,280. Crunched, at 1,323 — 119,070.

Multiply it by every amendment and every sister protocol in the study folder, before the first question is asked.

WHAT SURVIVES
THE DOSING TABLE

A dose stays bound to its weight band and its unit. Flattened, 12.5 floats free of the band it belongs to — and a misattributed dose is not a formatting problem.

WHERE IT RUNS
API

POST /v1/crunch from inside the pipeline. The base path is deterministic — same input, same Markdown, same structure map — which is what a validated system has to be able to say about a step.

THE CATCH

Figures are not read. A structure diagram or a gel image comes back as a placeholder holding its position in the document, never as a description we generated for it.

Public sector Tenders, legislation, consultations 04 / 06
THE DOCUMENT

A tender pack of about 300 pages: an ITT in PDF, the requirements matrix as XLSX, a question-and-answer addendum in DOCX, and two annexes nobody mentions until day nine.

WHAT IT COSTS
838K tok 397K tok
300 pages as a native upload, at 2,792 tok a page — 837,600. Crunched, at 1,323 — 396,900.

That is the pack once. A bid team goes back into it a dozen times.

WHAT SURVIVES
THE REQUIREMENTS MATRIX

Requirement id, mandatory or desirable, and the response cell stay one row you can answer down. Flatten it and every M and D comes loose from the requirement it graded.

WHERE IT RUNS
WEBCLI

Drop one document here to see what comes back. Then run the engine over the whole folder: four formats, one command, one Markdown tree the entire bid team can search.

THE CATCH

A 1998 photocopy of a statutory instrument goes through the local OCR engine, in seven languages, without leaving your network. What OCR cannot do is promise a clean read of a bad scan — so low-confidence lines are flagged per page and you get a list of pages to check, not a tidy document that is quietly wrong.

Engineering & manufacturing Specs, standards, datasheets 05 / 06
THE DOCUMENT

A 60-page component datasheet: parameter tables with min, typical and max columns, test conditions in footnotes, and dimension drawings at the back.

WHAT IT COSTS
168K tok 79K tok
60 pages as a native upload, at 2,792 tok a page — 167,520. Crunched, at 1,323 — 79,380.

A part library holds hundreds of these, and every one of them gets revised.

WHAT SURVIVES
THE MIN / TYP / MAX TABLE

The units row stays attached and a footnote marker stays in the cell it qualifies. Flattened, 2.7 3.3 3.6 is three numbers with no column and no test condition.

WHERE IT RUNS
CLIMCP

Run the engine across the library and rebuild it when a revision lands — the output is deterministic, so the diff is the revision. Point an MCP client at the result and an engineer can ask across the whole set instead of one datasheet at a time.

THE CATCH

A dimension drawing is a figure placeholder. Its callouts live inside the image on a page that already has a text layer, so OCR is never invoked for them — the tolerances you can cite are the ones that were in a table.

Software & AI teams RAG corpora, internal docs, attachments 06 / 06
THE DOCUMENT

Whatever the ticket has attached: a 40-page vendor PDF, an exported wiki page, a spreadsheet of test cases — arriving mid-conversation, in four formats, unannounced.

WHAT IT COSTS
112K tok 53K tok
40 pages as a native upload, at 2,792 tok a page — 111,680. Crunched, at 1,323 — 52,920.

For one attachment, on one turn, inside an agent loop that had other things to spend a window on.

WHAT SURVIVES
THE HEADING TREE

Headings come back as a structure map, so chunks can break where the document breaks instead of every thousand characters. A table survives inside the chunk that cites it.

WHERE IT RUNS
MCPAPI

The agent calls the crunch tool before it reads. The model sees Markdown; the raw file never enters the context window at all.

THE CATCH

crunch.md does not chunk, embed or store anything. It returns Markdown and a structure map — the splitter, the index and the retrieval are still yours to write.

READ THE DOCUMENTS AS ILLUSTRATIONS

The six documents above are typical shapes, not files we converted, and nobody named here is a customer. The token figures are arithmetic on the same two per-page numbers the rest of this page uses: 2,792 tokens for a native document upload on Claude — 1,224 tokens of text the model extracts, plus a 1,568-token page image, both measured — against 1,323 tokens of crunched Markdown. Change the page count and the arithmetic follows. Read the catches as the part we would rather you found here than after you uploaded something.

A Digital One product. Files deleted after conversion · never used for training