Cohere Embed

The parameter you cannot skip

Cohere's current model is embed-v4.0, and the thing to understand before writing any code against it is input_type.

Most embedding APIs treat a query and a document identically. Cohere does not. You declare what the text is for, and the model embeds it differently:

The consequence is that indexing and querying use different values against the same model. Embed your corpus with search_document and your queries with search_query. Getting this backwards, or using one value for both, produces results that look plausible and rank worse than they should, with no error to tell you.

This is the single most common Cohere mistake, and it is invisible. Semantic search covers why the asymmetry helps: a question and the passage answering it are not the same kind of text, so embedding them the same way discards information.

Dimensions you choose

Output dimensions are selectable: 256, 512, 1024 or 1536. The larger vectors carry more, the smaller ones cost less to store and search.

That choice compounds with index sizing. Indexing embeddings notes that product quantization wants a dimension that is a multiple of its M parameter, and these four are all comfortable there. Pick the dimension before you build the index, since changing it later means re-embedding the corpus.

Compression is a first-class option

embedding_types accepts float, int8, uint8, binary and ubinary.

The saving is large. Cohere notes that binary compression takes a 1024-dimension vector to 128 bytes, and that you unpack it with np.unpackbits() where you need compatibility.

Work out what that means for your storage before dismissing it. Ten million vectors at 1024 float32 dimensions is around 40 GB; the same corpus in binary is closer to 1.3 GB, which is the difference between an index that fits in memory and one that does not. Recall falls, and a common arrangement is to retrieve widely with binary vectors and rerank the top results with full-precision ones.

Multilingual, and multimodal in one vector

Cohere supports over 100 languages, which is the usual reason teams choose it over an English-first model. A single index serves users writing in different languages without a translation step.

embed-v4.0 also embeds images, passed as base64 data URLs, and can put text and images in a single vector. That is the property worth noticing: it is joint embedding, so a text query can retrieve an image directly, which is the approach LlamaIndex for multimodal apps contrasts with captioning.

The image limits: payloads up to 20 MB, up to 96 images per request, and dimensions from 56×56 up to 2,458,624 pixels.

Choosing it

Reach for Cohere Embed when you need strong multilingual retrieval, when storage at scale is the constraint and the compression options solve it, or when you want text and images in one searchable space.

Look elsewhere when you want to run the model yourself, since sentence-transformers is the local answer, and embedding models covers the selection question across providers.

Whatever you choose, record which model and which input_type produced each stored vector. A corpus embedded with two different settings is not searchable as one corpus, and nothing in the data will tell you that is what happened.

Further reading

• Cohere, Embeddings: input_type, the dimension options, embedding_types and the image limits.
• Embedding models: choosing between providers.
• Semantic search: why query and document embeddings differ.
• Indexing embeddings: what your dimension choice costs downstream.