Embedding APIs look like a rounding error — pennies per million tokens, the cheapest line on any provider's price sheet. Then teams ship a RAG system and discover the truth about LLM embedding costs: the API call was never the bill. The bill is storing millions of high-dimensional vectors in a managed database forever, re-embedding the entire corpus every time you change models or chunking, and paying query-time costs on every single search. Cheap to make, expensive to keep — that's the embedding economy in one line.
This guide breaks the cost into its four real components, shows the dimension math most teams skip, and lays out when local embedding models quietly beat the API on every axis that matters.
Embedding a 10-million-token corpus (~40 MB of text, roughly 7,500 pages) at typical API rates costs single-digit to low-double-digit dollars. One-time. This is the number everyone quotes and the least important one in the stack. If your corpus is static and small, stop reading — you have no cost problem. Everyone else, keep going.
A single 1,536-dimension float32 vector is 6 KB. That's the tax nobody prices in: embed 10M tokens as ~20,000 chunks of 500 tokens and you hold 120 MB of vectors — trivial. Embed 100M documents, or chunk aggressively, and you're storing terabytes of floats plus an index (HNSW graphs add their own memory multiple) in a managed vector database that charges by the GB-month, forever. Storage is a recurring cost attached to a one-time act. Dimensions are the multiplier: cutting 1,536 → 512 dims (via Matryoshka-style truncation, now standard on modern models) cuts storage and search compute ~3×, usually for a couple of points of retrieval quality. Most products should take that trade, and int8 quantization of stored vectors takes another 4× off with negligible loss. If you haven't run dimension math, you're storing someone's default, not a decision.
Vectors are frozen opinions of one specific model. Switch embedding models, change your chunking strategy, or upgrade to the provider's new version — and every stored vector is stale. Re-embed everything. The "one-time" cost from Component 1 turns out to be per-decision, and teams iterate on chunking a lot in year one. This is also the hidden lock-in: the switching cost of leaving a provider isn't the new API, it's re-processing your entire corpus through it. Budget re-embedding as a recurring line — three or four full passes in the first year is normal, not failure.
Every search embeds the query (tiny) and scans the index (not tiny). Query embedding costs are per-use and grow with traffic; vector-DB read units and the compute behind approximate-nearest-neighbor search grow with both traffic and corpus size. A RAG feature that gets popular multiplies all of it. Put your own corpus size, chunking, dimensions, and query volume into the free embedding cost calculator — then price the full pipeline, retrieval plus generation, with the RAG cost calculator. The two together are the honest quote. (New to the architecture? Start with RAG explained for AI agents.)
Here's what the pricing pages don't advertise: open-weight embedding models in the small-to-mid range now sit at or near the top of retrieval benchmarks, run comfortably on consumer GPUs — even CPUs — and embed thousands of chunks per second at a marginal cost of zero. Local embedding turns Component 1 free, makes Component 3 painless (re-chunk whenever you like, re-embed overnight), and keeps your corpus — which is your business, written as text — off a third party's logs. Pair a local embedder with a local vector store and the only real cost left is disk, which you own. This is exactly how QADIR OS treats memory: a sovereign, local-first agentic OS whose search and recall run on your own hardware — full-text and semantic retrieval over everything your agents know, with zero per-query meter and nothing leaving the machine.
Small static corpus + low traffic → API embeddings, don't overthink it. Large corpus, high churn, high query volume, or sensitive content → local embeddings win on cost within months and on privacy from day one. In between → embed locally, serve from whichever store your ops can actually maintain. Whatever you pick: choose dimensions deliberately, version your embeddings from day one, and price the re-embed before you commit to a model.
Price the whole iceberg, not the tip. Run your corpus through the free embedding cost calculator, or make the meter irrelevant — join QADIR OS early access and keep your knowledge, and your vectors, on your own machine. No card required.