The token economics of RAG over live web data

Most RAG cost is not the model, it is what you feed it. A measured look at raw HTML versus a readable document, and where the money actually goes.

Retrieval-augmented generation has an unglamorous cost centre. Everyone budgets for the model. Almost nobody budgets for the retrieval, and when the source is the live web rather than a tidy internal corpus, the retrieval is usually where the money went.

This post is the arithmetic, with numbers measured against a real page rather than estimated.

The measurement

Take a page with real substance to it: the Wikipedia article on retrieval-augmented generation. About 8,400 words, plenty of structure, the sort of source a research agent would legitimately pull into context.

curl -s -X POST https://api.lyrenth.com/v1/public/aidocument \
  -H "Content-Type: application/json" \
  -d '{"url":"https://en.wikipedia.org/wiki/Retrieval-augmented_generation"}'

The economics block on that response, measured on 24 August 2026:

That is a 66.2 percent reduction, and the cost basis is the mid-tier frontier model class rather than a cheap one or a flagship, so treat it as the middle of the range rather than a best case.

Two thirds of that page, as delivered by an HTTP fetch, is navigation chrome, scripts, inline styles, edit links, and markup. It costs real money for a model to read it and it contributes nothing to any answer.

Why it compounds

One page at nine hundredths of a cent is not a business problem. RAG does not read one page.

A single research question typically touches somewhere between five and twenty sources. Call it ten. If your pipeline feeds raw HTML, that one question costs about $1.33 in input tokens instead of about $0.45. The difference is $0.88 per question.

Now put that behind a product:

Those are input tokens only, on one measured page, at one price point. Your pages will differ, and mostly in the direction that helps. Three pages read the same morning:

The article at the bottom is the encyclopedia's best case: dense prose, little furniture, and it still sheds two thirds. The documentation page at the top is the one to look at, because it is the shape most technical sources take now, and nineteen twentieths of it was never the answer. The ratio is the part that travels: content density on the open web is stubbornly low, and the closer a page is to a modern application, the worse the ratio gets.

The three costs people forget

Reading the same page twice. In most pipelines every user's question triggers its own fetch. Two hundred users researching the same topic in the same week pay two hundred times for one page that did not change. Retrieval is the one part of RAG where the work is genuinely shareable, and it is the part most often built per-caller.

Paying for the fetch itself. Fetching is not free even when the tokens are cheap. It is latency in front of a user who is waiting, it is a request against someone else's server, and increasingly it is a request that can be refused. We wrote about what an index promises about freshness because that promise is what lets you skip the fetch honestly rather than by hoping.

Paying twice, once to embed and once to prompt. In a pipeline that indexes before it answers, every token is billed on the way in as well as on the way out. Embedding is cheaper per token than generation, which is exactly why it gets ignored, but it is charged on the full document rather than on the part that matched. Chunking and embedding 44,000 tokens of markup means storing the markup, searching the markup, and retrieving chunks that are partly markup. The saving compounds through every stage that touches the text, not just the final prompt.

Context you did not need. A 15,000 token document is better than a 44,000 token one, and still worse than the 800 tokens that actually answer the question. Extraction gets you the first saving. Selecting sections, using the page's own heading structure, gets you the second one, and it is usually larger. A document that arrives with its structure intact makes that selection possible; a wall of text does not.

What to actually do about it

Extract before you embed, and before you prompt. Whatever else you change, stop putting raw HTML in front of a model. This is the two thirds, and it is the easiest of the three to fix.

Read from an index, not from the origin, when the answer is knowledge rather than a live number. The fetch happens once for everybody instead of once per user, and the read comes back in milliseconds. For anything genuinely time-sensitive, force a refresh explicitly, which costs what a live fetch costs and is worth it exactly when it matters.

Use the structure you were given. Around a tenth of pages carry usable JSON-LD, and when a publisher has already declared the price or the publication date as a field, reading the field beats inferring it from a sentence. It is cheaper and it is right more often.

Log the ratio you actually get. The economics block comes back on every read, so this number is available for your own pages rather than estimated. The next section is the one-minute version of taking that measurement.

Measuring your own ratio, in about a minute

Estimates are not worth much here, because the ratio depends entirely on what your sources look like. A documentation site and a news homepage are not in the same business. The measurement is cheap enough that you should just take it.

for url in \
  "https://example.com/docs/getting-started" \
  "https://example.com/pricing" \
  "https://example.com/blog/some-post"
do
  curl -s -X POST https://api.lyrenth.com/v1/public/aidocument \
    -H "Content-Type: application/json" \
    -d "{\"url\":\"$url\"}" \
  | python3 -c "
import json,sys
e = json.load(sys.stdin)['aidocument']['economics']
print(f\"{e['raw_html_tokens_approx']:>7} -> {e['output_tokens_approx']:>6}  \"
      f\"({e['token_savings_percent']*100:.0f}% saved)\")
"
done

Run that over ten URLs your product actually reads. If the average saving is around two thirds, the arithmetic above applies to you almost directly. If it is higher, your sources are heavier than average and the case is stronger. If it is much lower, you are already reading clean sources and your money is going somewhere else, which is worth knowing before you spend a sprint on retrieval.

One caveat on reading these numbers honestly: the token counts are approximations, and the dollar figures are an illustration at one price point rather than your invoice. Tokenisers differ between model families and prices change. The ratio is the durable part; treat the cost column as an order of magnitude rather than an accounting entry.

The part that is not about money

Cheaper retrieval is the obvious win and the smaller one. The larger one is that a model given 15,000 tokens of clean prose and structure gives better answers than one given 44,000 tokens of the same content wrapped in markup, because the markup is not neutral. It is a distraction with a cost, and attention spent on a cookie banner is attention not spent on the paragraph you needed.

Token economics is the measurable proxy for a quality argument. The budget is what makes people act on it.

If you want the ratio for your own pages, the quickstart returns the economics block on the first call, for any public URL, without an account. Read three pages you actually use and you will know within a minute whether this is worth your attention.