text embedding models compared: prices

The wrong embedding model creates a quiet tax. You pay for extra vector storage, retrieve less relevant material, or build around an API that becomes awkward once your corpus grows. The API bill is usually the smallest part of that equation. Storage, indexing, retrieval speed, and answer quality are where the decision starts to hurt.

Pricing references link to official documentation and should be checked before purchase. This page compares published specifications, then points to the best embedding models guide for editorial picks.

Key Takeaways

• text-embedding-3-small is a low-cost default with 1,536 dimensions and an 8,191 token context window.
• Google text-embedding-004 uses 768 dimensions and offers a Free / $0.025 per 1M tokens pricing path.
• voyage-3-large has the strongest listed MTEB score, but its price is materially higher.
• jina-embeddings-v3 is the current best value for teams that care about price and retrieval quality.

The Full Comparison Table

All prices verified against official documentation as of September 2026. MTEB scores are from the public leaderboard (English retrieval subset).

How to Read This Table

Dimensions determine how much storage each vector requires. More dimensions can preserve more semantic detail, but they also make every indexed vector larger. That affects database size, memory use, and similarity-search costs. A model with a strong benchmark score can still be the wrong pick if its vectors bloat an index you need to query quickly.

Price per 1M tokens is the API cost to create embeddings. Embeddings are dramatically cheaper than generative model calls. That is why the difference between a low-cost model and a premium one often matters less during initial ingestion than it does when you re-embed a large corpus, add frequent updates, or support many tenants.

Max tokens is the context window. It describes how much text the model can accept in one embedding request. You should still chunk documents deliberately. Shorter chunks often retrieve better because each vector represents a narrower idea. Throwing an entire long document into one vector is a tidy ingestion pipeline and a messy retrieval system.

MTEB average is the model's score across the Massive Text Embedding Benchmark suite. Higher is better. The gap between the listed scores is meaningful in production retrieval systems, but benchmark leadership does not excuse weak chunking, poor metadata filters, or a badly tuned vector database.

Specs narrow the field. Your own corpus decides the winner. Build a small retrieval set from actual customer questions, include the awkward documents your team keeps avoiding, and inspect what each model brings back. The what is the best embedding model guide is useful once you are ready to move from a spec sheet to a decision.

OpenAI text-embedding-3-small: Price, Dimensions, Context Window

OpenAI text-embedding-3-small outputs 1,536 dimensions at $0.02 per 1M tokens with an 8,191 token limit and 62.3 MTEB average Related analysis. Those are the answers most teams need before they test it.

The price is low enough that it rarely blocks a prototype. The dimension count is high enough to make storage a real design consideration once your index grows. That combination is why it works well as a default: you get a model that is inexpensive to embed with, familiar to most vector database integrations, and capable enough to reveal whether your larger problem is model choice or retrieval design.

The 8,191 token limit does not mean you should use chunks anywhere near that size. A context window tells you the maximum accepted input, not the ideal retrieval unit. RAG systems work when the retrieved chunk gives the language model the precise evidence it needs. Giant chunks frequently dilute that signal with unrelated material.

Its 62.3 MTEB average also gives you a useful reference point. If another model costs more, it should produce a retrieval improvement you can observe in your own evaluations. Better-looking benchmark numbers are easy to admire. Missed customer questions are what users notice.

OpenAI text-embedding-3-large outputs 3,072 dimensions at $0.13 per 1M tokens Related analysis. That may suit teams already committed to OpenAI that want a larger representation, but the storage impact is part of the price. The API cost is only one line item.

For many teams, text-embedding-3-small is the right first production model. Start there, measure retrieval quality, then make the premium case with evidence from your own search set. Otherwise you are buying more vector without knowing whether your users can tell.

Google text-embedding-004: The 768-Dimension Free Option

Google text-embedding-004 outputs 768 dimensions, priced Free / $0.025 per 1M tokens Related analysis. Its 768-dimension output makes the storage conversation simpler than it is with models that generate larger vectors.

That smaller footprint can matter when you are indexing a large knowledge base, serving a latency-sensitive search experience, or paying for vector infrastructure you would prefer to keep boring. Smaller vectors do not automatically mean worse results. They mean you have a model with a different cost and representation profile, and you should test it against your own retrieval cases.

The Free / $0.025 per 1M tokens structure also gives developers a low-friction way to evaluate the model before committing. Pricing alone should not decide the winner. If your corpus has domain-specific language, long technical documents, or multilingual content, run those examples through every serious candidate.

Google wins when its model fits the rest of your stack and its smaller vectors deliver acceptable relevance. It loses when your test set shows that a higher-performing model retrieves the crucial passage more reliably. “Acceptable” is not a benchmark score. It is whether the product answers the question without sending users back to search.

The same warning applies to any free tier. A cheap start is useful. It does not remove the need to understand what you will pay after the evaluation is over or how the provider fits into your operational setup.

Voyage AI Embeddings Pricing: voyage-3-large vs voyage-3-lite

voyage-3-large costs $0.18 per 1M tokens with a 32,000 token context window and 67.1 MTEB average Related analysis. It is the premium option in this comparison for teams chasing retrieval quality.

The 32,000 token context window gives it room for unusually long source material. That can help in ingestion workflows that need to process large documents, though it does not repeal the chunking problem. A long input limit makes pipeline design more flexible. Retrieval still depends on whether each stored vector has a clear job.

The 67.1 MTEB average is the strongest listed benchmark score here. If your search product lives or dies on subtle semantic distinctions, that may justify the price. Legal research, technical documentation, analyst reports, and large internal knowledge bases can expose quality gaps that a basic demo never shows.

voyage-3-lite costs $0.02 per 1M tokens with 512 dimensions Related analysis. It sits at the other end of Voyage's pricing range: a lower-cost model with a much smaller vector footprint.

That makes voyage-3-lite attractive for teams that want Voyage's platform but need to control index size and ingestion spend. It is also a useful comparison point. If lite returns nearly the same useful passages for your data as large, the premium model has not earned its seat at the table.

Voyage wins when its retrieval lift shows up on your difficult queries. A generic evaluation will flatter almost any decent embedding model. Use ambiguous questions, terminology that appears in several documents, and questions where the right passage is buried among close alternatives. That is where a premium model earns its fee, or fails to.

The Price-Quality Sweet Spot

jina-embeddings-v3 costs $0.02 per 1M tokens with a 65.5 MTEB average, the current best value Related analysis. It undercuts the premium Voyage option on price while posting a stronger listed MTEB score than text-embedding-3-small.

That is the spec-sheet case for Jina. It is compelling because it avoids the usual tradeoff where cheap means visibly weaker. Teams that need a cost-conscious model without treating retrieval quality as an afterthought should put it in the first evaluation round.

There is still no substitute for testing. Benchmark averages combine many tasks, while your product may depend on one narrow retrieval pattern. A support-search tool, code documentation search, and a RAG assistant over policy documents can all produce different winners from the same candidate list.

Jina's value claim is strongest when the system needs good retrieval but does not need a provider-specific ecosystem. If your stack already depends heavily on OpenAI or Google services, integration simplicity may be worth more than a benchmark advantage. If it does not, Jina deserves a serious look.

Provider-by-Provider Breakdown

Cohere: embed-v4

Cohere's latest embedding model scores 66.3 on MTEB, putting it among the top commercial options. The key differentiator is Cohere's search-specific features: embed-v4 supports separate "search_document" and "search_query" input types, which optimize the embedding differently for indexing versus retrieval.

The main limitation is the 512-token context window. Any input longer than 512 tokens gets truncated. For RAG applications where you are already chunking documents into 256-512 token pieces, this is fine. For applications that need to embed longer passages, you will need to chunk first.

Pricing at $0.10/1M tokens is mid-range. Cohere also offers a trial API key with 1,000 calls per month at no cost, making it easy to evaluate before committing.

Open-Source Options: BGE, E5, GTE, Nomic

All four of these models are free to download and run locally. BGE-large-en-v1.5 (from BAAI) and GTE-large-en-v1.5 (from Alibaba) are the strongest performers, scoring 63-65 on MTEB. Nomic-embed-text-v1.5 offers the longest context window (8,192 tokens) among open-source models with competitive quality.

The cost calculation for self-hosting: a single A10G GPU (~$0.75/hour on AWS) can process roughly 500-1,000 embeddings per second. At that rate, self-hosting becomes cheaper than API calls only when you exceed about 10-15 million embeddings per month. Below that threshold, a paid API is both cheaper and simpler to maintain.

Which Embedding Model to Pick by Budget

Pick Google text-embedding-004 when vector size and a Free / $0.025 per 1M tokens path are the central constraint. Pick text-embedding-3-small when you want a familiar OpenAI baseline at $0.02 per 1M tokens. Pick jina-embeddings-v3 when you want the strongest price-quality argument in the table.

voyage-3-large belongs in the evaluation when retrieval quality has a direct commercial cost. If a missed result means a support agent gives the wrong answer, a researcher misses relevant evidence, or a customer abandons a search flow, cheaper embeddings can become expensive fast.

Do not choose based on a single benchmark score or price cell. Put each candidate behind the same chunking strategy, metadata filters, vector database settings, and evaluation questions. Then inspect the retrieved passages, rather than only a headline quality metric. The best vector databases guide can help when the model decision starts colliding with index performance.

A Practical Evaluation Approach

Start with the corpus your product will use in production. Synthetic examples are fine for checking that an API works. They do little to expose the language quirks, duplicated documents, stale material, and vague user questions that make real retrieval difficult.

Create a set of representative questions from customer conversations, support tickets, or internal search logs. Include direct questions, partial questions, and the oddly phrased searches that users type when they do not know your taxonomy. Then decide what source passage should rank near the top for each one.

Run the same documents and questions through every candidate. Keep chunk size and metadata constant. Otherwise you are testing a mixture of model behavior and pipeline changes, which is how teams end up defending a choice they cannot reproduce later.

Inspect failures closely. If a model retrieves the wrong material because chunks are too broad, switching providers may do little. If it retrieves related material but misses the exact answer, a stronger model may help. If it finds the correct passage but the final answer is weak, your problem may sit downstream in prompting or generation.

Storage is the next practical check. Dimensions are not decoration. A 1,536-dimension model and a 768-dimension model create different index footprints. If your application needs low latency across a large corpus, test the whole retrieval path. The model with the cleanest benchmark result can lose if the production system becomes slow or too expensive to operate.

Model choice also changes over time. Keep the evaluation set. Re-run it whenever a provider updates a model, pricing changes, or your corpus shifts toward new types of content. The team that can compare candidates quickly has an advantage over the team that needs to rebuild its test harness every time a release lands.

The best embedding model is the one that retrieves the right evidence for your users at a cost and latency your product can sustain. Right now, jina-embeddings-v3 is the current best value, text-embedding-3-small is a practical OpenAI baseline, Google text-embedding-004 gives you smaller vectors and a Free / $0.025 per 1M tokens option, and voyage-3-large is the premium quality bet. Which one survives your hardest retrieval queries?

Practical Cost Examples

To make the pricing concrete, here is what it costs to embed common workloads.

Notice the scale. Even embedding 1 million documents with the most expensive option (Voyage AI) costs $90. The real expense in a RAG system is the generative model call that answers the user's question, not the embedding that retrieved the context. Optimizing embedding cost matters only at massive scale (billions of vectors).

Related Resources

Sources

• PE Collective embedding model specs: $0.02 per 1M tokens and 1,536 dimensions
• PE Collective embedding model specs: Free / $0.025 per 1M tokens and 768 dimensions
• PE Collective embedding model specs: $0.18 per 1M tokens and 67.1 MTEB average