Model identity matters
Pin the exact checkpoint and revision used in production. Family names can contain base, instruct, reasoning, quantized and provider-specific variants with different behavior.
Devstral Small 2505 is a dense software-engineering agent model developed by Mistral AI in the Devstral family. It has 24B parameters, supports 128K tokens of context, accepts Text / code and produces Text / code. Its primary role is software engineering agents, repository navigation, patch generation and code reasoning.
OpenWeightModels separates the base checkpoint from its legal conditions and from each deployment implementation. This page is designed as an operational reference for people, search systems and AI agents—not as a single-number leaderboard.
Devstral Small 2505 is a dense software-engineering agent model developed by Mistral AI in the Devstral family. It has 24B parameters, supports 128K tokens of context, accepts Text / code and produces Text / code. Its primary role is software engineering agents, repository navigation, patch generation and code reasoning.
The model belongs to the Devstral family and was released by Mistral AI. Its documented input is Text / code and its output is Text / code. The published context envelope is 128K tokens, although a provider or runtime can expose a smaller operating limit.
For SEO and machine-readable retrieval, OpenWeightModels classifies it as a dense software-engineering agent model whose primary application area is software engineering agents, repository navigation, patch generation and code reasoning. This definition describes the model itself; licensing eligibility and the practical serving stack are analyzed separately below.
Official Hugging Face model ↗Official config ↗Apache License 2.0 ↗Devstral Small 2505 is useful to evaluate because it combines a specific architecture, license and operating envelope rather than simply adding another row to a model leaderboard.
Devstral specializes a Mistral Small 3.1 backbone for agentic software engineering. The training objective targets multi-file repository tasks and interaction with coding-agent scaffolds rather than generic chat alone.
From an infrastructure perspective, the key sizing facts are 24B total parameters, 24B active parameters and 128K tokens of context. These values should be read together: weight memory, active compute and KV-cache growth describe different resource constraints.
From a governance perspective, the checkpoint is distributed under Apache License 2.0. OpenWeightModels records that independently from the fact that the weights are downloadable, because “open weight” is an access classification—not a universal statement about commercial, redistribution or derivative-work rights.
Pin the exact checkpoint and revision used in production. Family names can contain base, instruct, reasoning, quantized and provider-specific variants with different behavior.
Tool calling, structured output, safety layers, quotas and maximum context can be added or restricted by the serving layer. Store them as deployment records, not as unconditional properties of the weights.
Licenses, provider availability and runtime compatibility can change independently. Production reviews should use the official source links and a dated internal record.
Values describe the named checkpoint/family release unless a deployment implementation is explicitly named. Where the publisher does not document a value, OpenWeightModels avoids inventing one.
Devstral Small 2505 is a dense model: its stated 24B parameter count is much closer to the parameter set participating throughout inference than in a sparse MoE system. That makes raw weight-memory planning more straightforward, although precision, context, KV cache, batch size and runtime overhead still materially change the real deployment envelope.
For dense models, quantization usually provides the clearest path to lower hardware requirements. Long context can nevertheless dominate runtime memory even when the checkpoint itself is comparatively compact.
Publisher-documented architecture details for this checkpoint include the elements below. These details are more useful for deployment planning than a parameter count alone because attention layout, expert routing, modality encoders and context design can affect throughput and memory independently.
Fine-tuned from Mistral Small 3.1
Vision encoder removed; Devstral is text-only
40 layers, hidden size 5120
32 attention heads / 8 KV heads
128K context and 131K tokenizer vocabulary
Training provenance matters because two checkpoints with similar architecture can behave very differently after data selection, instruction tuning, reinforcement learning or domain specialization.
Devstral specializes a Mistral Small 3.1 backbone for agentic software engineering. The training objective targets multi-file repository tasks and interaction with coding-agent scaffolds rather than generic chat alone.
OpenWeightModels distinguishes facts explicitly published by the developer from inference based on model behavior. Dataset composition, cutoff dates and training compute are shown only when the publisher exposes them; absence of a number is not silently filled with an estimate.
Capability claims are treated as task-level evidence, not permission to deploy autonomously. Tool access, code execution and external actions always depend on the surrounding application.
Devstral Small 2505 is relevant to software engineering agents. Capability should be validated against the exact checkpoint, prompt format and runtime rather than inferred only from family branding or a benchmark headline.
Devstral Small 2505 is relevant to repository navigation. Capability should be validated against the exact checkpoint, prompt format and runtime rather than inferred only from family branding or a benchmark headline.
Devstral Small 2505 is relevant to patch generation. Capability should be validated against the exact checkpoint, prompt format and runtime rather than inferred only from family branding or a benchmark headline.
Devstral Small 2505 is relevant to code reasoning. Capability should be validated against the exact checkpoint, prompt format and runtime rather than inferred only from family branding or a benchmark headline.
Devstral Small 2505 is relevant to evaluation and research. Capability should be validated against the exact checkpoint, prompt format and runtime rather than inferred only from family branding or a benchmark headline.
Devstral Small 2505 is relevant to custom deployment. Capability should be validated against the exact checkpoint, prompt format and runtime rather than inferred only from family branding or a benchmark headline.
OpenWeightModels records benchmark evidence without collapsing heterogeneous evaluations into an overall ranking. Scores can change with checkpoint revision, prompt, sampling, scaffold, precision and evaluator version.
Where a publisher reports a useful, clearly attributable metric it is shown below. Otherwise the passport points back to the official evaluation tables instead of manufacturing a cross-model score.
| Evaluation | Metric / setup | Value | Qualification |
|---|---|---|---|
| SWE-Bench Verified | OpenHands scaffold | 46.8% | Publisher-reported score |
Apache License 2.0 is the controlling license/terms classification recorded for this checkpoint. OpenWeightModels keeps the legal layer separate from technical availability.
Includes an express patent grant. Model-specific acceptable-use policies, if separately published, are not automatically part of Apache 2.0.
Permissive open-source software license. This summary supports comparison only; the linked official text remains authoritative.
| Question | Classification | Practical meaning |
|---|---|---|
| Commercial use | Allowed | Commercial eligibility follows the named license/terms; provider and jurisdictional conditions may add requirements. |
| Modification / fine-tuning | Allowed | Weight adaptation and derivative work rights are summarized from the official license type. |
| Redistribution | Allowed with license/notice conditions | Redistribution is a separate question from the ability to download and run weights. |
| Hosted inference | License-dependent | Running a hosted service may count as distribution or trigger provider/model-specific terms; verify the official text for this checkpoint. |
| Open-weight classification | Yes | Weights are publicly obtainable; this label does not imply identical licensing freedom across models. |
Deployment is recorded as a set of implementations rather than one “self-hostable: yes” flag. A runtime can change context support, quantization, API shape, tool parsers, throughput and hardware requirements without changing the underlying model identity.
For Devstral Small 2505, the most relevant documented or established routes are listed below.
| Route | Type | Qualification |
|---|---|---|
| vLLM | Serving | Official model is tagged and documented for vLLM. |
| mistral-common / mistral-inference | Self-hosted | Mistral-native tokenizer and serving components. |
| OpenHands-style agent scaffold | Agent application | Publisher evaluation uses a coding-agent scaffold for repository tasks. |
| Local quantized deployment | Local | Mistral says the 24B model can fit a single RTX 4090 or 32GB Mac when quantized. |
Official model is tagged and documented for vLLM.
Mistral-native tokenizer and serving components.
Publisher evaluation uses a coding-agent scaffold for repository tasks.
Mistral says the 24B model can fit a single RTX 4090 or 32GB Mac when quantized.
The publisher explicitly positions Devstral as locally deployable after quantization. Repository-scale context and coding-agent tool traces can still raise memory/latency substantially compared with short completion workloads.
Real memory use includes model weights, KV cache, activations/buffers, multimodal encoders when applicable, framework overhead and batching. A published “fits on” statement is meaningful only together with precision, context, batch and host/GPU topology.
BF16/FP16 maximize fidelity but increase weight memory. FP8, INT8 and 4-bit variants can substantially lower memory, with support and quality depending on the quantization recipe and runtime.
128K tokens is a model/configuration reference, not a promise that every machine or provider can serve that context at practical latency. KV-cache growth often becomes the dominant long-context constraint.
Large dense models need tensor/pipeline parallelism; large MoE models add expert-routing and communication requirements. Smaller checkpoints can often avoid these operational complexities.
Base, instruct, reasoning, FP8, GGUF and provider-hosted variants can have different behavior, memory and provenance. Production systems should pin an exact model/revision rather than only the family name.
| Variant | Purpose | Precision / form | Status |
|---|---|---|---|
| Devstral-Small-2505 | Software-engineering instruct | BF16 | Official |
Devstral Small 2505 is most relevant when the application specifically values software engineering agents, repository navigation, patch generation and code reasoning. That should be balanced against its hardware class, context behavior, license and modality requirements.
A smaller model can be operationally superior when latency, privacy, device deployment or predictable cost matter more than peak benchmark capability. Conversely, a larger sparse model may justify its complexity when the workload benefits from higher capacity, sophisticated reasoning or agent behavior.
The selection decision should therefore compare at least five dimensions: required task quality, data/control requirements, legal eligibility, serving cost and ecosystem/runtime support. OpenWeightModels exposes these dimensions separately so a model is not selected on benchmark reputation alone.
A high-quality passport gives limitations the same visibility as capabilities. These are model- and deployment-selection notes, not generic disclaimers.
It is text-only even though it was derived from a multimodal Mistral Small backbone.
Agent benchmark performance depends on the scaffold and tools used.
Generated patches require testing, security review and sandboxed execution.
A 128K window should not be automatically filled; repository retrieval can be more efficient.
Last full review: 29 September 2026. Publisher model cards, repositories and license texts are preferred. Runtime claims are attached to the relevant runtime/provider rather than inferred from the base checkpoint.
Where documentation conflicts or a field is ambiguous, the passport uses the more conservative interpretation and explains the discrepancy instead of silently selecting the largest number.
Material changes to license, model revision, runtime support or provider limits should update both the field and this history.
Gold-standard Passport v2.0 created with SEO/GEO definition, architecture, training, capability, evaluation, license, deployment, hardware, variants, limitations and source review.
Devstral Small 2505 is a dense software-engineering agent model developed by Mistral AI in the Devstral family. It has 24B parameters, supports 128K tokens of context, accepts Text / code and produces Text / code. Its primary role is software engineering agents, repository navigation, patch generation and code reasoning.
OpenWeightModels classifies it as open-weight because weights are publicly available. The exact legal classification depends on Apache License 2.0; weight availability should not be used as a substitute for reading those terms.
Our license classification is Allowed. Review the official license and any separate use policy, provider terms and jurisdictional rules before production use.
The documented reference in this passport is 128K tokens. A runtime/provider may expose a different maximum or a smaller recommended operating range.
Yes, the open weights enable independent deployment where the license permits it. Practical feasibility depends on 24B of weights, precision, context length and the runtime routes listed above.