What ingesting 46,844 documents with an LLM actually costs

Direct answer: the cost of a mass LLM ingest is not calculated from the number of documents, but from the number of calls your pipeline makes per document — which in knowledge-extraction systems is typically 2 to 5 times the number of chunks, not documents. Across 46,844 parliamentary speeches, the gap between the naive estimate and the real one is two orders of magnitude, and the free tier you prototyped on is unusable: 20 requests per day means over fifteen years of processing.

TL;DR

The naive estimate is «documents × price per call». It is wrong: entity/relation extraction systems make several calls per chunk, and chunks outnumber documents.
Across 46,844 realistic documents you easily reach over 100,000 model calls.
With a frontier-tier model at list price ($5 per million input tokens, $25 output), the order of magnitude is a few thousand dollars for a single complete ingest.
A cheap model's free tier (20 requests/day) turns the same job into ~15 years.
The free tier is not a fallback plan: it is a prototyping environment with capacity that does not scale.
There is exactly one number to estimate before launching: total calls. Everything else is multiplication.

The moment you notice

The real context: 46,844 parliamentary speeches to ingest into a knowledge-graph engine for OpenLegis. The prototype worked. It worked on two hundred documents, with a cheap model, on the free plan.

Moving to real scale produced two consecutive walls, in this order:

Frontier-tier model: credit exhausted. Not halfway through the job — far earlier.
Falling back to a cheap model: free-plan limit of 20 requests per day.

The second wall is the instructive one, because it is not a wall of money: it is a wall of time. And time, in that case, was measured in years.

The naive estimate and why it is wrong

Almost everyone estimates like this:

46,844 documents × 1 call × cost per call = total bill

The result looks manageable, so the job gets launched.

The problem is that «1 call per document» is almost always false. In a knowledge-extraction pipeline — the kind that turns text into entities and relations — the real sequence per document is:

Chunking: the document is split. An average parliamentary speech produces more than one chunk.
Extraction: one call per chunk, identifying entities and relations.
Gleaning: many engines make a second pass over the same chunk to recover what the first missed.
Description merging: when the same entity appears across dozens of chunks, the system calls the model again to fuse the descriptions into one coherent entry.

The real multiplier is not 1. It is typically between 2 and 5 — and step 4 is the one almost nobody includes, because it scales not with documents but with entity recurrence, which you do not know until you are done.

The calculation done properly, with explicit numbers

The assumptions below are stated on purpose: the point is not the final number, it is the method. Swap in your own assumptions and redo the maths before launching.

Step	Assumption	Result
Documents	—	46,844
Average tokens per document	~1,500	~70M source tokens
Chunks per document	~1.2 (~1,200-token chunks)	~56,000 chunks
Calls per chunk	2 (extraction + gleaning)	~112,000 calls
Input tokens per call	~2,000 (chunk + system prompt)	~224M input tokens
Output tokens per call	~600	~67M output tokens

At list price for a frontier-tier model — $5 per million input tokens, $25 per million output (Anthropic pricing for Claude Opus 5, September 2026) — the bill is:

Input: 224M × $5 / 1M = ~$1,120
Output: 67M × $25 / 1M = ~$1,675
Subtotal: ~$2,800

To which you add entity merging, which on a corpus with strong recurrence (the same members of parliament, the same topics, over years) easily adds 30–50%. Real order of magnitude: $3,500–4,000 for a single complete ingest. Re-run it because you changed the extraction prompt, and it doubles.

Now the free tier. Same 112,000 calls, at 20 requests per day:

112,000 ÷ 20 = 5,600 days ≈ 15 years and 4 months

That is not a joke: it is why the job never ran.

The lesson beyond this case

The free tier makes you believe you have a working system when you have a working prototype. They are different things, and the difference is invisible until you multiply.

Three rules I took from this and have applied since:

Estimate calls, not documents. It is the only number that counts. If you do not know how many calls your pipeline makes per document, instrument a 100-document sample and count them for real before launching.
Run the sample on the paid plan, not the free one. A hundred documents on the real plan gives you a measured cost per document, not an estimated one. It costs a few dollars and saves you the surprise.
Set a spend cap before pressing enter. A 112,000-call job going wrong is a job that burns a quarter's budget while you sleep.

There is an architectural choice underneath as well: not all of the corpus deserves the same model. In a mass ingest, the mechanical work (chunking, structured extraction from regular text) is fine on a cheap model; real judgement — disambiguating ambiguous entities, deciding whether two relations are the same — is where the good model earns its cost. Treating the whole corpus identically is the fastest way to spend a lot for an average result. It is the same reasoning I apply when deciding whether to put an agent in the middle of a flow: if the step is deterministic, a model is just cost and variance.

FAQ

Why does an ingest cost more than one call per document?

Because knowledge-extraction pipelines split each document into chunks, make at least one call per chunk, often a second recovery pass, and then further calls to merge descriptions of recurring entities. The real multiplier is typically 2 to 5 calls per chunk.

How do I estimate cost before launching the job?

Instrument the pipeline on a sample of 100 real documents, count the actual calls and the input and output tokens, then scale by the ratio between the full corpus and the sample. It is the only way to get a measured number rather than an imagined one.

Can the free tier be used for a mass ingest?

No. Free-plan limits are designed for development, not throughput: even an apparently generous limit turns into years of processing once calls number in the hundreds of thousands. The free tier is a prototyping environment.

Is it worth using a cheaper model for the whole corpus?

It is worth splitting. Mechanical work on regular text is fine on a cheap model; disambiguation and merge decisions benefit from a more capable one. Applying the same model to everything is the quickest way to spend a lot for average quality.

If you are assessing a mass ingest and want to know what it will actually cost before you launch — or you have a job that went wrong — let's talk. It is the kind of estimate I make often as a Fractional CTO.