Embeddings are the cheapest line item in the agent stack by a comfortable margin, and also the one where the pricing decision matters most. Both things are true at once, and the tension between them is the whole point of this post.
First, the raw numbers from our catalog. Embedding APIs bill per token processed, quoted per million tokens. Routed prices (provider list plus 20%, methodology in the pricing docs):
| Provider / model | Routed price per 1M tokens | Catalog quality score |
|---|---|---|
| DeepInfra bge-large | $0.012 | 79 |
| OpenAI text-embedding-3-small | $0.024 | 84 |
| Mixedbread mxbai-embed-large | $0.072 | 86 |
A 6x spread from floor to ceiling, which sounds dramatic until you multiply it by anything.
The math for real corpus sizes
Per-million-token prices are abstract, so let me translate into corpora. Assume an average document chunk runs around 500 tokens, which is typical for RAG pipelines.
A small knowledge base. 10,000 chunks, about 5M tokens. Embedding the whole thing costs $0.06 on DeepInfra, $0.12 on OpenAI, $0.36 on Mixedbread. The entire corpus, on the most expensive provider, costs less than a coffee.
A serious corpus. 2 million chunks, about 1B tokens. Now it is $12 versus $24 versus $72. Still small next to what the same pipeline spends on LLM calls to generate answers from the retrieved chunks.
Query traffic. Every search embeds the query too, but queries are tiny. A million 20-token queries is 20M tokens: $0.24 to $1.44 depending on provider. Per month, for a million searches.
The honest conclusion from the arithmetic: for most teams, embedding spend is a rounding error, and picking the cheapest provider to save $60 on a billion-token corpus is optimizing the wrong thing. This is the category where I tell people to weight the quality axis heavily. Our scores put Mixedbread’s mxbai-embed-large at 86 and OpenAI’s 3-small at 84, and retrieval quality compounds: every downstream LLM call is only as good as the chunks retrieval hands it. The comparison is laid out per-provider on the embedding comparison page.
There is one exception where price genuinely matters, and it is worth naming: continuous re-embedding at scale. If your corpus churns constantly (fresh documents, edits, expiring content) and you are re-processing hundreds of millions of tokens monthly, the 6x spread stops being a coffee and starts being a budget line. Those pipelines should do the math above with their own churn numbers.
Why this cheap decision is the stickiest one you’ll make
Here is the part that per-token math does not capture: embeddings are lock-in in a way almost nothing else in the stack is.
Vectors from different models do not mix. An embedding is only meaningful relative to the model that produced it; a query embedded with bge-large cannot be searched against a corpus embedded with text-embedding-3-small. The numbers are the same shape, the comparison is garbage. Different dimensions, different spaces, different geometry. There is no adapter, no conversion, no gradual migration.
Contrast this with every other category I route. Swap search providers and the next query just goes elsewhere. Swap scraping providers mid-incident and nothing downstream notices. Swap embedding providers and your entire vector store is invalidated. Migration means re-embedding the full corpus (tolerable, per the math above), re-indexing it, and re-validating retrieval quality against your evals, because a new model ranks things differently and every relevance threshold you tuned is now stale. The compute cost is the small part; the pipeline and evaluation work is the real bill.
Some practical discipline that follows from this:
- Store the model name with every vector. When (not if) you end up with mixed generations during a migration, the metadata field is what keeps queries routed to the right index. Our normalized embedding schema keeps the model explicit for exactly this reason.
- Pin the model, not just the provider. “Whatever the provider’s latest embedding model is” is a silent corpus invalidation waiting to happen.
- Choose upfront like it is permanent. Spend your effort on retrieval evals before committing, not on saving a few dollars per billion tokens after.
Where routing fits, and where it doesn’t
I will be straight about the limits of my own product here: cheapest-first failover across embedding models is the one routing pattern that does not work, for the reasons above. A failover that silently swaps models mid-corpus corrupts your index. What routing does give you in this category is one key and one schema across providers while you evaluate, unified billing with the exact price on every response, and failover within your pinned model where multiple hosts serve it. The general one-schema tradeoff is a thing I wrote up in normalized APIs vs provider lock-in.
Embedding pricing is the easiest math in the stack: small numbers, per-token, no surprises. The decision attached to it is the least reversible one you will make. Spend accordingly. Current prices and quality scores for all three providers are on the embedding API comparison page.