Embedding a corpus costs real money exactly once per text — and this calculator prices it before you commit: by raw tokens, or by documents and average length, across eight current embedding models, with batch-API discounts and re-indexing projections included.
How the Cost Is Calculated
Providers charge per million tokens embedded. In corpus mode the token count is estimated from your document statistics with the standard English heuristic:
The stored model table (standard / batch price per 1M tokens): OpenAI text-embedding-3-small 0.01, text-embedding-3-large 0.065, Voyage voyage-4-lite 0.0134, voyage-4 0.0402, voyage-4-large 0.0804, Cohere embed-v4 0.15 / 0.02 / —. Batch pricing — submitting asynchronous jobs — halves OpenAI and Google prices and cuts Voyage's by a third; Cohere and Jina show no batch rate in the table, and selecting batch for them flags it unavailable rather than inventing a discount. Results include cost per document and per thousand documents, an annual figure if you re-index monthly (×12), and a high-cost flag at $20.
Worked Example — a 15-Million-Word Company Wiki
10,000 documents averaging 1,500 words → 15,000,000 words → 19,950,000 tokens:
| Model | Standard | Batch | | --- | --- | --- | | OpenAI 3-small | 0.20** | | OpenAI 3-large | 1.30 | | Gemini embedding-001 | 1.50 |
Cost per thousand documents on batch 3-small: about **2.39. These are the numbers that surprise every first-time RAG builder: embedding generation is the cheap part of semantic search. The spend that matters lives elsewhere — vector database storage and serving, the LLM calls that consume the retrieved chunks, and engineering time.
Planning a Real Embedding Budget
Three realities belong in any honest estimate. Chunking multiplies documents, not tokens: splitting texts into 500-word chunks with overlap raises the token count by the overlap fraction (10–20% overlap is typical), and the tokens are what you pay for — estimate from tokens when precision matters, using the raw-token mode with a price you enter directly. Model switches cost a full re-embed: vectors from different models live in incompatible spaces and cannot be mixed in one index, so changing models means paying the corpus cost again in full (and re-indexing downtime) — cheap at wiki scale, a real line item at a billion tokens. Dimensionality is a storage decision, not a generation one: larger models emit longer vectors, which cost the same to generate per token but more to store and search; the generation prices here do not capture that, nor any database costs at all. For generation-side spend on the chat models that will use your embeddings, the LLM API Cost Calculator is the companion tool.
Frequently Asked Questions
Why is embedding so much cheaper than chat generation?
Embedding models run a single forward pass that maps text to a vector — no sequential token-by-token generation, no enormous reasoning model. Providers price that lightness honestly: embedding a million tokens costs roughly what generating a few thousand tokens does on a frontier chat model.
Should I use batch pricing?
If your workload tolerates asynchronous completion (typically within 24 hours), yes — it is the same embeddings for 33–50% less. Initial corpus loads and periodic re-indexes are perfect batch candidates; only interactive, embed-this-now user flows need the real-time price.
Does the estimate include storing and searching the vectors?
No — generation only. Storage and query serving in a vector database (hosted services like Pinecone, or self-hosted Qdrant/Weaviate/pgvector) is a separate, usually larger, ongoing cost that depends on vector count, dimensionality, and query volume.