Prompting a reasoning model

Lesson rewritten on November 2, 2026. This lesson previously covered the Magistral system prompt, which was retired on July 31, 2026. Current reasoning documentation (Reasoning) no longer requires a dedicated system prompt: reasoning_effort is sufficient. The following sections distinguish what the Magistral documentation stated, what has changed, and the prompting rules that remain useful.

What has changed since Magistral

Magistral performed best with a default system prompt, which the documentation reproduced (now archived on the Native reasoning (deprecated) page). Essentially, it instructed the model to draft its reasoning first, like an internal monologue, followed by a standalone response; to write in Markdown, using LaTeX for equations; and to reply in the language of the query. It even included a reasoning template, in the form of a thinking fragment placed in the system message. A parameter, prompt_mode, allowed you to force this default prompt ("reasoning") or disable it (None).

With current models, none of this is necessary: the reasoning page mentions neither a dedicated system prompt nor prompt_mode. You enable reasoning with reasoning_effort, and your system prompt reverts to a standard system prompt, dedicated to role, method, and expected format. If you are migrating from Magistral, remove the reasoning template from your system messages and prompt_mode from your calls, then compare the results (Lesson 8).

Separating reasoning from the response

The model now has two distinct spaces: the reasoning, which the user often does not see, and the final response. A good prompt accounts for this. It describes the expected method, what a domain expert would verify, and it sets the response format: the response must be understandable without the reasoning, since the reasoning will generally be hidden.

import os
from mistralai.client import Mistral

client = Mistral(api_key=os.environ["MISTRAL_API_KEY"])

system_prompt = """You are a senior Python debugging expert.

METHOD
- Read all the code before formulating a diagnosis.
- Formulate at least two hypotheses before concluding.
- Verify that your fix does not create a new problem.

FINAL RESPONSE
1. The precise diagnosis
2. The root cause
3. The corrected code
4. A test that proves the fix"""

response = client.chat.complete(
    model="mistral-small-2603",
    messages=[
        {"role": "system", "content": system_prompt},
        {"role": "user", "content": "My code crashes with a RecursionError: def fibonacci(n): return fibonacci(n-1) + fibonacci(n-2)"},
    ],
    reasoning_effort="high",
)

On this fibonacci function lacking a base case, the requirement for two hypotheses rules out the reflex diagnosis “increase the recursion limit” and leads to the actual cause.

Adapting by domain

The same skeleton, method then response format, adapts to the specific domain. In mathematics, the method focuses on hypotheses and the type of proof:

math_prompt = """You are a rigorous mathematician.

METHOD
- State the hypotheses before every proof.
- Explicitly choose between induction, contradiction, or direct calculation.
- Verify the result on a specific case.

FINAL RESPONSE
Formal proof: hypotheses, justified steps, conclusion."""

In strategic analysis, it focuses on stakeholders and quantification, and the expected response becomes a recommendation accompanied by a plan:

strategy_prompt = """You are a strategy consultant.

METHOD
- Evaluate each option based on feasibility, impact, and risk.
- Quantify whenever possible, even if only as an order of magnitude.
- Seek the strongest objection to your own recommendation.

FINAL RESPONSE
A clear recommendation, the pros and cons of each option, an action plan with dated steps."""

Three common mistakes

The prompt is too vague. “You are a helpful assistant” says nothing about the method: the model reasons according to its habits rather than yours. Describe what an expert would verify.

The prompt is contradictory. “Be very concise. Detail every step in depth.” places the model before an impossible injunction. Resolve the contradiction by distributing roles: detail belongs in the reasoning, conciseness in the final response.

good_prompt = """Be concise in your final response: conclusions and essential figures only.
Explore details in your reasoning, not in the response."""

Requesting the process in the response. Asking to “reason step by step” in the visible response makes the model write a second time what it has already done in its reasoning: the response lengthens, and you pay twice for the same steps in output tokens. Only request steps in the response if the user needs to read them, for example in an educational tutor.

Key takeaways

• The default system prompt and prompt_mode were specific to Magistral: they are no longer necessary
• Enable reasoning with reasoning_effort, and keep the system prompt in its classic role
• Describe the expected method and the format of a response readable without the reasoning
• Distribute roles: detail in the reasoning, conciseness in the response
• Do not make the model rewrite the process in the response if no one needs to read it