The three embedding bills, and why only one of them is obvious
Embedding is the cheapest line in most retrieval systems and the one most often mis-budgeted, because it arrives as three separate charges with different shapes.
The one-off ingestion is the obvious one: every chunk in the corpus goes through the API once. It is a single, predictable number — items times tokens per item times price — and for a mid-size knowledge base it is usually smaller than people expect. Forty million tokens at a typical small-model price is well under a dollar.
The recurring charge has two halves that behave differently. New and edited content grows roughly with your publishing rate. Query embedding grows with traffic, and it is the half that surprises teams, because every single search embeds its query text before it can search. Twenty tokens per query looks negligible until you multiply by a million queries a month.
The re-embedding charge is the one that has no natural trigger in a budget cycle. Stored vectors are only comparable to vectors from the same model, produced from the same chunk boundaries. Change the embedding model, change the chunk size, change the overlap, and every stored vector becomes meaningless — not degraded, meaningless, because it lives in a different vector space. The fix is a complete pass over the corpus at current size, which is always at least as expensive as the original ingestion and usually more, since the corpus has grown.
How the arithmetic works and where the token count comes from
The formula is a unit conversion. Providers list a price per million input tokens, so you count tokens, divide by 1,000,000, and multiply. There is no output charge: an embedding request returns a fixed-length float vector, and its length is a property of the model rather than of your text. A 1,536-dimension model and a 3,072-dimension model can charge the same per token, and the larger one costs you more only in storage, which the vector database storage calculator handles separately.
Getting the token count right is the whole job. Three rules matter. First, count the units you actually send: in a chunked pipeline that is chunks, not source files, and the RAG chunking calculator converts one into the other. Second, remember that overlap is paid for. If your chunks overlap by 12.5%, you send roughly 1.14 tokens to the API for every source token, and the corpus figure you enter here should be the chunked total, not the raw document total. Third, count edits as new work. An edited document re-embeds all of its chunks, so a corpus with high churn has a much larger monthly figure than its net growth suggests.
Query tokens follow the same rule with a different multiplier. A bare user question is often 10–30 tokens. If you rewrite or expand queries before embedding — appending conversation history, generating a hypothetical answer to embed instead — the per-query token count can rise by an order of magnitude, and it is worth entering the real figure rather than the raw question length.
Worked example: 50,000 chunks, 2,000 new per month, 200,000 queries
You have a 50,000-chunk knowledge base averaging 800 tokens per chunk. You add 2,000 chunks a month, serve 200,000 searches a month at about 20 tokens per query, pay $0.02 per million tokens, and plan one model upgrade at the end of the year.
- Corpus tokens. 50,000 × 800 = 40,000,000 tokens.
- One-off cost. 40,000,000 ÷ 1,000,000 = 40 million-token units, × $0.02 = $0.80. Per chunk that is $0.80 ÷ 50,000 = $0.000016.
- Monthly new content. 2,000 × 800 = 1,600,000 tokens.
- Monthly queries. 200,000 × 20 = 4,000,000 tokens — two and a half times the ingestion volume.
- Monthly cost. (1,600,000 + 4,000,000) ÷ 1,000,000 × $0.02 = 5.6 × $0.02 = $0.112. Twelve months of that is $1.344.
- The re-embed. By month 12 the corpus has grown to 40,000,000 + 12 × 1,600,000 = 59,200,000 tokens, so the full re-embedding run costs 59.2 × $0.02 = $1.184.
- Year one, all in. $0.80 + $1.344 + $1.184 = $3.328.
Two things are worth reading off that. The single re-embedding run costs more than the entire original ingestion — $1.184 against $0.80, a ratio of 59.2 ÷ 40 = 1.48, exactly the corpus growth. And query embedding is 4.0 of the 5.6 million monthly tokens, so this system's recurring embedding cost is driven by search traffic rather than by content.
How to read the result and when embedding cost matters at all
Compare the first-year total against the rest of the pipeline before optimising it. Embedding is almost always the smallest line: generation tokens typically cost hundreds of times more per token than embedding tokens, and vector storage on a managed service is usually a larger monthly figure than the embeddings that filled it. If your embedding bill is a few dollars a year, the correct action is to stop thinking about it and go price the generation calls with the LLM API token cost calculator.
Embedding cost becomes material in three situations, and it is worth checking which one you are in. Very large corpora — billions of tokens — put the one-off run into the hundreds or thousands of dollars, which makes chunking decisions expensive to reverse. Very high query volume moves the recurring line into the same territory. And frequent re-embedding, whether from model churn or from tuning chunk parameters in production, multiplies the corpus cost by however many times you do it.
Read the monthly split to know which lever applies. When queries dominate, cache embeddings for repeated query text — in most products a small number of queries account for a large share of traffic, and an exact-match cache on the query string is cheap to build. When new content dominates, the lever is deduplication and change detection: hash each chunk and skip re-embedding chunks whose text has not changed, which turns a document edit from a full re-embed into a few chunks.
Treat the re-embedding figure as the real cost of a model change and budget it explicitly, alongside the engineering time to run a dual index during the migration. Vectors from two models cannot be compared, so a zero-downtime migration means building the new index in full before switching over — which for a period doubles your storage as well.
One-off embedding cost by corpus size and price
| Corpus tokens | $0.01 / 1M | $0.02 / 1M | $0.10 / 1M | $0.13 / 1M |
|---|---|---|---|---|
| 1 million | $0.01 | $0.02 | $0.10 | $0.13 |
| 10 million | $0.10 | $0.20 | $1.00 | $1.30 |
| 100 million | $1.00 | $2.00 | $10.00 | $13.00 |
| 1 billion | $10.00 | $20.00 | $100.00 | $130.00 |
| 10 billion | $100.00 | $200.00 | $1,000.00 | $1,300.00 |
As a rough conversion, 1 million tokens is about 750,000 words of English prose, or roughly 1,250 chunks of 800 tokens.
What makes an embedding budget wrong
- Counting documents instead of chunks. A 5,000-document corpus split at 512 tokens with overlap is 15,000 or more API items. The token total is what you pay for, and overlap adds 10–20% on top of the source text.
- Forgetting query embeddings entirely. Search traffic embeds text too. At high volume this is routinely the largest half of the recurring bill, as it is in the worked example above.
- Mixing per-1K and per-1M prices. A price sheet quoting $0.00002 per 1,000 tokens is $0.02 per million. Entering the per-1K figure in a per-1M field understates the bill by a factor of a thousand.
- Assuming re-embedding costs what ingestion cost. It costs what the corpus is worth today, which is larger. In the example above the ratio is 1.48 after one year of growth.
- Ignoring rate limits and retries. Bulk ingestion of a large corpus is throttled, and failed batches that are retried are billed on each attempt where tokens were processed. Budget wall-clock time as well as money.
- Treating a dimension reduction as free. Models that support shortened output vectors save storage, not embedding cost — you still send the same input tokens.
Hosted APIs versus self-hosted embedding models
Open-weight embedding models run on your own hardware, which converts a per-token charge into a fixed hourly one. The break-even is straightforward: a GPU instance costs the same whether it embeds one token or a billion, so self-hosting wins above a throughput threshold and loses below it. Work out your monthly token volume from this page, price it against the hourly cost of an instance that can sustain your throughput, and compare. The self-host vs API breakeven calculator sets up that comparison, and GPU-hours cost calculator prices the instance side.
Two considerations usually matter more than the arithmetic. Self-hosting removes the re-embedding charge almost entirely — a full corpus pass becomes a few hours of GPU time you already own — which changes the economics of experimenting with chunk sizes and models. Against that, hosted models are updated by the provider, and a silent model update on the provider's side is a compatibility event for your index; check your provider's version-pinning policy, because an index built against an unpinned model name is fragile.
Whichever you choose, the downstream numbers are unaffected. The vector count and dimensionality determine storage, which the vector database storage calculator sizes, and neither depends on what you paid to produce the vectors. Per-user economics, where embedding cost sits alongside generation cost, are covered by the LLM cost per user per month calculator.