Skip to main content
Lesson 5 of 18 · Embeddings, RAG, and Semantic Search

The codestral-embed Model

Lesson 5 of 18 Updated November 2, 2026 Developer
On this page
  1. Specialized Embeddings for Code
  2. Technical Specifications
  3. Basic Usage
  4. The output_dimension Parameter
  5. The output_dtype Parameter
  6. Combining Dimension and Dtype
  7. Supported Languages
  8. Key Takeaways

Specialized Embeddings for Code

While mistral-embed is designed for natural language, codestral-embed is an embedding model optimized specifically for programming languages. It understands code syntax, semantics, and logic, making it significantly superior to a generic text model for any task involving source code.

You can see the difference in a simple case. Two functions that do the same thing—one written with a for loop and the other using list comprehension—share almost no tokens. A text model sees them as two distinct blocks of punctuation; a model trained on code brings them together because it has learned that these two forms express the same intent.

Technical Specifications

The codestral-embed model differs from mistral-embed in several key ways:

Featurecodestral-embedmistral-embed
Default Dimensions15361024
Maximum Dimensions3072 (double the default)—
Output Typesfloat, int8, uint8, binary, ubinary—
OptimizationTrained on multi-language source codeNatural language

This flexibility in dimensions and output types is what truly sets the two models apart in practice. A code index quickly reaches a million vectors, and being able to cut their weight by four changes the infrastructure bill.

Basic Usage

The API is identical to mistral-embed, except for the model name codestral-embed. Nothing else changes in your calling code, which lets you run both models in the same project by tweaking just one parameter.

from mistralai.client import Mistral

client = Mistral(api_key=api_key)

# Encode code snippets
response = client.embeddings.create(
    model="codestral-embed",
    inputs=[
        "def fibonacci(n): return n if n <= 1 else fibonacci(n-1) + fibonacci(n-2)",
        "function fibonacci(n) { return n <= 1 ? n : fibonacci(n-1) + fibonacci(n-2); }",
        "public int fibonacci(int n) { return n <= 1 ? n : fibonacci(n-1) + fibonacci(n-2); }",
    ],
)

for i, data in enumerate(response.data):
    print(f"Snippet {i+1}: vector of {len(data.embedding)} dimensions")
# Snippet 1: vector of 1536 dimensions
# Snippet 2: vector of 1536 dimensions
# Snippet 3: vector of 1536 dimensions

Notice that all three snippets implement the same logic (Fibonacci) in three different languages. Their embeddings will be very close despite the syntactic differences. This property enables cross-language search: on a polyglot codebase, a Python developer can find the Java implementation they need without knowing a word of Java.

The output_dimension Parameter

You can reduce vector size to save storage space, at the cost of a slight loss in precision:

# Reduced dimensions (512 instead of 1536)
response = client.embeddings.create(
    model="codestral-embed",
    output_dimension=512,
    inputs=["def hello(): print('Hello, World!')"],
)

embedding = response.data[0].embedding
print(f"Dimensions: {len(embedding)}")  # 512

The first dimensions of the vector are the most informative. The model is designed so that the first n dimensions retain the maximum amount of information, allowing this reduction without catastrophic loss. In other words, truncating a vector isn’t like randomly throwing away a third of the meaning: you keep the core signal and lose the nuance, which remains perfectly viable for an initial filtering pass.

Choosing a Dimension

Use the following values as guidelines based on your project context. High-precision search on a modest corpus requires different settings than an index running on a resource-constrained machine:

# Recommendations by use case
DIMENSIONS = {
    "high_precision_search": 3072,   # Maximum quality
    "general_use": 1536,             # Default, good compromise
    "large_volume": 768,             # Storage/quality trade-off
    "prototype": 512,                # Rapid development
    "embedded": 256,                 # Strict memory constraints
}

The output_dtype Parameter

The output type controls the precision and size of the values. Where output_dimension reduces the number of values, output_dtype reduces the weight of each one. These two levers are independent and cumulative.

# Float (default) - maximum precision
response_float = client.embeddings.create(
    model="codestral-embed",
    output_dtype="float",
    inputs=["def add(a, b): return a + b"],
)

# Int8 - 4x more compact than float32
response_int8 = client.embeddings.create(
    model="codestral-embed",
    output_dtype="int8",
    inputs=["def add(a, b): return a + b"],
)

# Binary - extremely compact
response_binary = client.embeddings.create(
    model="codestral-embed",
    output_dtype="binary",
    inputs=["def add(a, b): return a + b"],
)

Combining Dimension and Dtype

You can combine both parameters for precise control. The two calls below encode the same SQL query and illustrate the extremes of the spectrum: the first targets a lightweight index queried continuously, while the second serves a reference search where every point of precision counts.

# Compact and fast: 512 dimensions in int8
response = client.embeddings.create(
    model="codestral-embed",
    output_dimension=512,
    output_dtype="int8",
    inputs=["SELECT * FROM users WHERE active = true"],
)

# High quality: 3072 dimensions in float
response = client.embeddings.create(
    model="codestral-embed",
    output_dimension=3072,
    output_dtype="float",
    inputs=["SELECT * FROM users WHERE active = true"],
)

Here is a rule to establish right now: vectors in your index and vectors in your queries must share exactly the same parameters. Encoding a corpus in 512 dimensions and then querying in 1536 doesn’t just yield poor results; it produces an error or meaningless scores.

Supported Languages

codestral-embed works with all common programming languages. On the application side, it covers Python, JavaScript, and TypeScript, as well as Java, C, C++, C#, Go, and Rust. For data and presentation, the model handles SQL, HTML, and CSS. For tooling and configuration, it manages Shell/Bash, YAML, and JSON—and many others, effectively any language present in the training data. In practice, a typical repository mixing Python, HTML templates, SQL migrations, and YAML manifests can be fully indexed with a single model.

Key Takeaways

  • codestral-embed is optimized for source code, not natural language
  • 1536 dimensions by default, scalable up to 3072
  • The output_dimension parameter lets you reduce vector size
  • The output_dtype parameter controls precision (float, int8, binary, etc.)
  • The model understands code semantics regardless of the language