Cohere Embed 5: Pro and Fast Embedding Models Compared

Embed 5’s most useful design choice is that Pro and Fast share an embedding space. A team can evaluate higher-quality corpus indexing and faster query embedding without maintaining two incompatible indexes within that family. The choice still needs testing on the actual documents and questions; shared space is not a guarantee of equal retrieval quality.

Written October 1, 2026 and dated September 30, 2026, using the dated announcements cited below. Later product developments are outside this article’s scope.

Cohere’s September 30 launch lists Embed 5 Pro at $0.12 per million text tokens and Fast at $0.08; image tokens cost $0.40 per million for either. The model documentation and dated release note describe a shared space, 128K context, text/image inputs and more than 100 languages. The launch announcement supplies the prices; these are vendor rates, not a measured workload bill.

The supported dimensions are 256, 512, 768, 1024, 1536 and 2048, with float, int8 and binary outputs. Select a consistent representation for the index and query path. A vector database may impose its own requirements on dimensions, distance metric and supported formats.

An embedding is a numerical representation used to compare a query with stored material. When two models produce compatible representations, the index built with one can be queried with the other as documented. Cohere recommends Pro for indexing and Fast for queries, which separates an infrequent corpus operation from repeated interactive traffic.

Do not generalize compatibility beyond the stated family. An existing index made with another embedding model should be treated as a separate migration. Matching vector length alone does not prove that distances have the same meaning. Keep the old index until the replacement has passed retrieval and application checks.

A 128K context window allows larger inputs, but the best retrieval unit may still be a section, page or other coherent chunk. A whole document can contain several unrelated answers. If the stored representation blends them together, the system may retrieve a broadly relevant document without locating the passage needed for a precise response.

Compare chunking strategies on actual questions. Include queries that require a table row, an exception clause or information near the end of a long document. Preserve identifiers that let the application link a retrieved vector back to the right source location. A high similarity score is less useful when the user cannot inspect the evidence.

For visually structured documents, compare parsed text with the supported image or mixed-input path. Use the same relevance judgments and keep parsing failures visible. The model cannot recover information that a preprocessing step removed before embedding.

Use human relevance judgments where the answer matters, and inspect failures by category. An average can hide poor results for one language or one document format. Keep permissions and metadata filters in the evaluation too: a relevant document that the user is not allowed to access is a failed application result.

Illustratively, embedding 100 million text tokens at the listed rates costs $12 with Pro or $8 with Fast, excluding every other charge. That $4 difference may be small beside the cost of parsing, storing and reviewing the corpus. For frequent query traffic, latency and repeated usage can matter more. Recalculate from your actual volumes.

The model-routing guide explains accepted-result economics; the agent-memory guide places retrieval in a larger system. Keep the access boundary fixed while testing. Our AI transformation service supports those controlled evaluations.

A shared embedding space makes one comparison cheap, and the guide’s sections exist because it is easy to run a different comparison and read it as that one. The illustrative evaluations below each measure something other than useful retrieval. They are design examples drawn from the documentation’s own distinctions, not teams we have worked with.

Each evaluation would have produced a score and left the question the guide asks, whether useful retrieval improved, unanswered. The record in the next section fixes the inputs first and keeps every result against them.

The migration table asks a team to freeze its inputs, build a candidate, judge retrieval and decide, and a record per candidate holds the evidence each step produces. The inputs: a versioned document sample and a representative query set, including queries that need a table row, an exception clause or information near the end of a long document. The candidate: model, dimensions, output format, chunking and the source identifiers that link a vector back to its location. The pairing: which variant indexed and which queried, since Cohere recommends Pro for the corpus and Fast for queries within the shared space. The judgments: relevant results and important misses, inspected by language and document format rather than averaged, with permissions and metadata filters applied as the application would apply them. The costs: the token rates multiplied by actual volumes, with parsing, storage and review time beside them. And the decision, with the old index kept until the new pipeline has passed both the useful answers and the difficult misses.

An illustrative record for a policy-document corpus reads: inputs, a frozen sample across three languages and a query set with twelve exception-clause questions; candidate, Pro for indexing at 1024 dimensions in int8, section-level chunks with page identifiers; pairing, Fast for queries against the Pro index; judgments, improved on two languages, unchanged on the third, with two exception-clause misses traced to a chunk boundary and fixed by re-chunking; costs, the listed rates applied to the real token count, with parsing the larger line; decision, run in parallel with the existing index for a further month.

The record is also what makes the Pro and Fast comparison meaningful. The two variants can be judged against the same index and the same relevance judgments, and the record is where that shared denominator is kept when the numbers are read later.

Latency belongs in the record beside quality, because the Fast variant exists for the interactive path. Measure the query embedding time as the application observes it, at the dimensions and output format the index actually uses, and record it with the relevance result from the same run. A variant that retrieves marginally better and responds noticeably slower is a trade the application owner should see as two numbers, not as one verdict.

The cost line should be the full one. The illustrative token arithmetic in the migration section suggests the embedding charge may be small beside parsing, storage and review, and the record is where that proportion is confirmed on real volumes rather than assumed. Record the token count the service billed, the storage the chosen dimensions and format consumed, and the hours spent on relevance judgments, so that the decision to switch or to wait is made against the cost that will recur.

A parsing failure is a record entry too. The model cannot recover information that a preprocessing step removed before embedding, so a miss traced to a table that was flattened or a page that was dropped is a pipeline fault rather than a model result, and the record should say so. Keeping those misses in their own category stops a candidate model from being blamed for a parser, and stops a parser fix from being credited to a model change.