# Devstral Small 2: a deprecated API and downloadable weights

Understand Devstral Small 2 API deprecation separately from its versioned open-weight artifact, local evaluation and replacement-model decisions.

Author: Retrivium team
Updated: 2026-11-03
Canonical URL: https://retrivium.ai/journal/devstral-small2-deprecated-api-open-weights/
Language: en

A deprecated hosted API model and a downloadable model checkpoint have different lifecycles. Devstral Small 2 illustrates why the status of one should not be silently applied to the other.

## Read what the deprecation notice actually covers

The [official API model page](https://docs.mistral.ai/models/devstral-small-2-25-12) marks Devstral Small 2 as deprecated and gives a deprecation date of 2026-02-27. It names Mistral Medium 3.5 as a replacement for new integrations.

That is a statement about the documented hosted product. It does not by itself say that every copy of the older weights has disappeared or that an existing local checkpoint stops generating. Deprecation also should not be translated into a guarantee that an old API alias remains accessible indefinitely.

## Identify the separate weight artifact

The [Small 2 model card](https://huggingface.co/mistralai/Devstral-Small-2-24B-Instruct-2512/raw/main/README.md) identifies Devstral-Small-2-24B-Instruct-2512, its coding scope and the selected FP8 artifact. The [dated release announcement](https://mistral.ai/news/devstral-2-vibe-cli/) provides the release context.

A local evaluation should name that repository and revision. A user-facing label such as Devstral Small is insufficient when multiple generations and hosted identifiers exist. Keep model identity separate from the route through which a request was sent.

## Build a lifecycle distinction table

| Object | Relevant question |
| --- | --- |
| Hosted model identifier | Is this API route currently supported? |
| Downloaded checkpoint | Which exact files and revision exist locally? |
| Runtime implementation | Can the selected engine load that artifact? |
| Replacement model | Does it satisfy the application's task contract? |
| Existing evaluation | Which model identity did the results actually cover? |

The replacement named by an API page should not be assumed to have the same downloadable format, license metadata or local execution path. Each item needs its own primary documentation.

## Evaluate continuity on a bounded coding task

Use an existing fictional patch fixture with source, expected behavior and protected tests. If retaining Small 2 locally, establish whether the pinned artifact and runtime still complete that task. If evaluating a replacement, repeat the same acceptance checks.

Do not mix an API migration, a prompt-template change and a new model into one unexplained result. Identify which boundary changed. A connection error on a retired route says nothing directly about the coding ability of a local checkpoint.

## Preserve a migration decision record

Record hosted identifier status, downloaded repository revision, runtime and task acceptance separately. The decision may be to continue a reproducible local experiment, adopt a supported hosted replacement or investigate a different model.

None of these decisions follows automatically from the word deprecated. The useful outcome is a clear statement of which service or artifact is being retained or replaced, what remains supported and which actual coding requirements were verified. Avoid treating a historical release announcement as current API availability.

## Related reading

- [Model aliases and revisions: provider response identity](/journal/provider-model-alias-revision-identity/)
- [Prepare a complete pinned Hugging Face snapshot for offline serving](/journal/huggingface-pinned-offline-snapshot/)