Decision Tree — Which Model for Which Use Case
On this page
The practical selection guide
You now know the entire Mistral catalog, and the natural next question is action: which model should you use for your project? This lesson offers a structured selection process, supported by a mapping table between use cases and models. The goal isn’t to give you a ready-made answer, but to enable you to justify your choice to an architect or a CFO.
Start with the need, not the model
The most common mistake is choosing the “most powerful” model right away and applying it to everything. A team that plugs a frontier model into a simple ticket classification task pays ten times the necessary price, waits several seconds for a response a small model would have delivered instantly, and ends up dependent on an API where a local model would have sufficed. Power doesn’t compensate for a mismatch; it makes it expensive.
The right approach works in reverse and involves three steps. First, identify your main task—the one that represents the bulk of the volume, not the exotic case that happens once a month. Next, evaluate your real constraints: budget, acceptable latency, data sensitivity, and available infrastructure. You select the model only last, at the intersection of this task and these constraints. A model is never good in absolute terms; it is either suited or unsuited to a specific intersection.
Decision table by use case
| Use case | Recommended model | Tier | Why |
|---|---|---|---|
| Chatbot / Assistant | Mistral Small 4 | Open | Hybrid instruct+reasoning, 256K context, optimal price/performance ratio |
| RAG (long documents) | Small 4 + Mistral Embed | Open + Premier | Large context window + quality embeddings |
| Code completion (IDE) | Codestral | Premier | FIM, low latency, 80+ languages |
| Autonomous code agent | Devstral 2 | Open | End-to-end task resolution, code exploration |
| Speech synthesis / TTS | Voxtral TTS | Open | Voice cloning, streaming, multilingual |
| Audio transcription | Voxtral Transcribe 2 | Premier | Diarization, context biasing, high accuracy |
| Document extraction | OCR 3 | Premier | Structure, tables, multi-page |
| Image + text analysis | Mistral Large 3 | Open | Frontier multimodal, best quality |
| Mathematical reasoning | Magistral Medium 1.2 | Premier | Deep chain-of-thought, specialized reasoning |
| Mobile/edge deployment | Ministral 3 (3B) | Open | Ultra-compact, multimodal, offline |
| Content moderation | Moderation 2 | Premier | Jailbreak detection, custom guardrails |
Walk through the decision in three steps
The first step is to categorize your need. General text—conversation, writing, summarization—falls under the Small, Large, and Medium family. Anything code-related belongs to the Codestral and Devstral family. Audio, whether input or output, goes to Voxtral. Handle documents and images with OCR 3 or Large 3 depending on whether you want structured extraction or interpretation. Complex reasoning calls for Magistral, and security questions fall under Moderation 2. This categorization eliminates three-quarters of the catalog right away.
The second step pits this candidate against your constraints, and this is where decisions are really made. A tight budget points toward Open models for self-hosting or toward Small 4 via the API. Sensitive data mandates self-hosting an open model, regardless of API convenience. A strict latency requirement pushes you toward Ministral 3 locally or toward Codestral for IDE completion. A quest for maximum quality justifies Large 3 or Magistral Medium 1.2. Finally, a team without infrastructure to administer should stick with the Premier API, even if it costs more. These constraints often contradict each other: explicitly trading off is better than discovering the conflict in production.
The third step is the one people skip most willingly and should never skip: prototype validation. Never choose a model based solely on benchmarks. Build a test set of twenty to fifty representative examples, run two or three candidates on them, compare result quality, latency, and cost, then iterate. This verification rarely takes more than half a day, and it’s the only one that tells you something about your own context rather than an average calculated elsewhere.
Winning combinations
In mature architectures, you don’t choose a model but an assembly, with each component doing what it does best. A complete RAG system chains Mistral Embed for indexing, Small 4 for generation, and Moderation 2 to filter outputs. A document pipeline starts with OCR 3 for extraction, moves to Small 4 for analysis, and relies on Mistral Embed for search. A developer assistant combines Codestral in the IDE, Devstral 2 for complex tasks, and Codestral Embed for code search. A voice application, finally, enters via Voxtral Transcribe, processes with Small 4, and exits via Voxtral TTS. The total cost of these chains is almost always lower than that of a single model attempting to do everything.
Key takeaways
- Always start with the use case, not the model
- Evaluate the task / constraints / budget triad before choosing
- Multi-model combinations are often more effective than a single model
- Always test with your own data before committing
- Mistral Small 4 is the default starting point for most cases