Prompting reasoning models effectively requires a different mental model than prompting standard language models. The core difference: reasoning models do their own thinking, so your job is to give them a clear problem and the right output format — not to prescribe a reasoning process. Prompts that work well with standard models (step-by-step instructions, chain-of-thought scaffolding, detailed role-play personas) often interfere with reasoning models’ internal processes. This guide covers what actually works, what does not, and the specific patterns that get the best results from models like o3, o4-mini, DeepSeek R1, and Claude with extended thinking.
The Fundamental Shift: Problem Statement, Not Process Prescription
With a standard language model, you often need to guide the reasoning process explicitly: “first analyse X, then consider Y, then synthesise a conclusion.” This helps because standard models do not have an internal deliberation mechanism — they need the reasoning structure imposed externally. Reasoning models have an internal deliberation process. Telling them how to think is like telling a skilled mathematician “first, write down the givens; second, recall relevant theorems; third, attempt a proof by contradiction…” — it is well-intentioned but may actually interrupt a more efficient reasoning path the model would have found on its own. The effective approach is to describe the problem clearly and completely, specify the output format you want, and let the model figure out how to get there. The reasoning is its job; the problem specification is yours.
Be Precise About the Problem, Not the Solution
The single most impactful prompt improvement for reasoning models is precision in the problem statement. Vague problems produce vague reasoning. Every relevant constraint, every piece of background information the model needs, every ambiguity you want resolved in a specific way — put it in the prompt. “Solve this optimisation problem” is worse than “Find the values of x and y that minimise f(x,y) = x² + y² subject to the constraint x + 2y = 10, where x and y must be positive real numbers.” More words in the problem statement is not a sign of a bad prompt — it is a sign that you have done the work of specifying the problem precisely, which the model can then solve precisely. Ambiguous prompts cause reasoning models to spend thinking tokens resolving the ambiguity rather than solving the problem, sometimes resolving it differently than you intended.
Specify the Output Format Separately
Reasoning models produce a thinking trace and a final answer. The final answer can range from a single number to a multi-page document, and without guidance the model chooses a format based on what seems natural. Specify the output format explicitly and separately from the problem: “After working through this, give me your final answer in exactly this format: [answer only, no explanation]” or “Show your complete working, then box the final numerical answer.” Separating the format instruction from the problem statement helps the model understand that the format constraint applies to the output, not the thinking process. For structured outputs (JSON, bullet lists, specific headings), describe the exact structure you want in the final answer, not in the thinking.
Do Not Add Chain-of-Thought Instructions
Appending “Let’s think step by step” or “Think carefully before answering” to a prompt sent to a reasoning model is usually unnecessary and sometimes counterproductive. The model already reasons by default. Adding explicit chain-of-thought instructions can constrain the model to a specific reasoning pattern that may not be optimal for the problem. If the model’s default reasoning is “try multiple approaches and pick the best,” telling it to “work through this step by step” may push it toward a more linear single-attempt approach. The exception: if you want the model to show its work in the final output (not in the thinking trace, which is often hidden), then an instruction like “Show your working in the final answer” is appropriate — but that is a formatting request, not a reasoning instruction.
Avoid Over-Constraining the Reasoning Process
Instructions that constrain how the model reasons — “first check X, then verify Y, then conclude Z” — often reduce quality compared to leaving the reasoning open. The model may have identified a more efficient reasoning path that your prescribed structure does not allow. A good test: if you removed the reasoning instructions and only kept the problem statement and output format, would the output be worse? For most well-specified problems with reasoning models, the answer is no. Reserve process constraints for situations where you have a specific reason — for example, “verify your answer by substituting it back into the original equation before giving the final answer” is a useful constraint because it adds a verification step the model might skip, not one that restricts its approach.
Figure 1 — Reasoning model prompt patterns: what works vs what interferes
System Prompts: Keep Them Minimal
Reasoning models are less dependent on elaborate system prompts than standard models. A simple system prompt — “You are a helpful AI assistant. Answer the user’s questions accurately.” — is typically sufficient. Elaborate personas (“You are an expert mathematician with 30 years of experience who always…”) add tokens without improving reasoning quality. Reasoning models get their “expertise” from the training process, not from prompts telling them to act expert. One place system prompts do help: specifying domain context that affects how to interpret the user’s questions, or specifying constraints on the output format that apply across all queries in a session. System prompts that impose reasoning constraints (“always cite your sources before concluding,” “never speculate beyond what the data shows”) can be useful if the constraint is genuinely important, but should be written as constraints on the output rather than constraints on the reasoning process.
Asking for Verification
Explicitly asking reasoning models to verify their answers is one of the most reliable ways to improve accuracy on tasks with checkable answers. “Verify your answer by [specific verification method]” — such as “substitute back into the original equation,” “check that your code produces the correct output for inputs X, Y, and Z,” or “verify that your proof does not assume what it is trying to prove” — adds a specific checkpointing requirement that the model’s default thinking might skip if the budget is limited. This works because it adds a checkable step with a clear pass/fail criterion, which is exactly the kind of step reasoning models are good at executing reliably. It is different from prescribing a reasoning process: you are not telling the model how to solve the problem, only requiring a specific verification of whatever solution it produces.
Multi-Turn Conversations with Reasoning Models
In multi-turn conversations, reasoning models do not retain their thinking traces across turns — only the final answers are in the conversation history. This means that if the model made an error in a thinking trace five turns ago, it cannot access that reasoning when you ask a follow-up question. For multi-turn reasoning tasks, you may need to summarise relevant conclusions from earlier turns in your follow-up prompt, rather than assuming the model has access to its earlier thinking. A good practice: when a reasoning model produces an important intermediate result in a long problem-solving session, extract that result and explicitly include it in the context for subsequent turns. Treating reasoning model output as context for the next turn, rather than assuming continuous memory, is more reliable.
Prompting for Structured Outputs
When you need structured output (JSON, tables, specific headings), specify the exact structure clearly in the prompt and include an example if the structure is non-obvious. Reasoning models are reliable at producing structured final answers, but the structure instruction needs to be in the prompt and clearly labeled as applying to the final answer. “Think through the problem as you need to, but produce your final answer in the following JSON format: {…}” separates the reasoning freedom from the output constraint. For very strict formatting requirements, adding “Do not include any text other than the JSON in your final answer” prevents the model from appending explanatory prose that breaks JSON parsers.
What Still Works from Standard Model Prompting
Several standard prompting techniques transfer well to reasoning models. Few-shot examples still help for domain-specific output formats — if you need answers in a specific notation or structured in a specific way, showing examples of the desired format in the prompt is effective. Explicit constraints on the final answer remain important: “your answer must be a single integer,” “respond in exactly three bullet points,” “keep the response under 200 words.” Role framing for domain expertise is somewhat useful for directing the type of reasoning to apply — “approaching this as a security auditor, identify…” can direct the model’s attention usefully. Negative examples (“avoid the common mistake of assuming X when Y”) can help the model avoid known pitfall patterns. The key distinction from standard models: these techniques shape the output and direct attention, rather than scaffolding a reasoning process the model lacks.
Prompting reasoning models well is primarily about problem specification and output definition, not reasoning scaffolding. Give the model a precise, complete problem statement. Specify the format you want for the final answer. Add a verification instruction for important results. And then step back — the reasoning is the model’s job, and giving it the space to do that job without excessive constraints is what produces the best results. The biggest prompt engineering improvement for most users coming from standard models is subtracting elements, not adding them.