How to Prompt Reasoning Models: Best Practices, Patterns, and Examples

Reasoning models change what “a good prompt” needs to do.

With earlier language models, prompt engineering often focused heavily on wording: assign a role, ask the model to think step by step, provide a detailed procedure, and hope the model follows the sequence.

Modern reasoning models increasingly perform substantial reasoning internally. They can allocate more effort to difficult tasks, make multi-step plans, use tools, revisit earlier assumptions, and continue across longer workflows.

That does not make prompt engineering less important.

It changes the target.

Instead of trying to script the model's hidden reasoning process, strong reasoning-model prompts usually define the problem, evidence, constraints, decision boundaries, tool policy, verification requirements, output contract, and completion condition.

The goal is not to tell a reasoning model every thought it should have. The goal is to give it a well-specified problem and a reliable operating environment.

This direction appears across current provider guidance. OpenAI recommends keeping reasoning prompts simple and direct and explicitly says chain-of-thought prompts such as “think step by step” are unnecessary for its reasoning models. Anthropic recommends general instructions over hand-written prescriptive reasoning sequences for current Claude thinking models. Google's Gemini 3.x guidance similarly emphasizes precise, direct instructions and warns that verbose prompt engineering can cause unnecessary over-analysis.

The providers expose different controls, but the cross-model lesson is surprisingly consistent:

GOOD REASONING MODEL PROMPTING
=
CLEAR PROBLEM
+
RELEVANT EVIDENCE
+
IMPORTANT CONSTRAINTS
+
RIGHT REASONING / THINKING SETTING
+
TOOL AND ACTION RULES
+
VERIFICATION
+
USEFUL OUTPUT
+
CLEAR STOP CONDITION

This guide explains how to apply that pattern to coding, research, business decisions, extraction, tool-using agents, long-context analysis, planning, and other complex workflows.

Quick Answer

To prompt a reasoning model effectively, start with the outcome rather than the reasoning procedure.

OBJECTIVE
What should be accomplished?

CONTEXT
What information matters?

EVIDENCE
Which sources or observations should the model trust?

CONSTRAINTS
What must remain true?

AMBIGUITY
When should the model infer, verify, or ask?

TOOLS
When should it search, calculate, execute code, or call functions?

VERIFICATION
What must be checked before the result is accepted?

OUTPUT
What should the final deliverable contain?

STOP CONDITION
What proves the task is complete?

Then configure the provider's reasoning or thinking control separately where available.

As of September 2026, those controls are not standardized:

Provider / Model Example	Reasoning Control	Important Detail
OpenAI reasoning models	reasoning.effort	Supported values are model-dependent; current models can expose levels ranging from none/minimal through max. GPT-6 Astra does not support none.
Claude Fable 5.1	effort	Adaptive thinking is always on. Anthropic recommends starting at high and testing other effort levels.
Gemini 3.8 Flash	thinking_level	Supports low, medium, and high, with medium as the model-specific default.

Do not try to reproduce those runtime controls with prompt wording. Prompt design and inference configuration work together, but they are different layers.

Key Takeaways

• Reasoning models still need clear prompts; they simply need less micromanagement of hidden reasoning steps.
• Do not assume “think step by step” improves a modern reasoning model. Current OpenAI guidance explicitly recommends avoiding chain-of-thought prompting, while Anthropic recommends general reasoning instructions over prescriptive sequences.
• Define the outcome, evidence, constraints, and success criteria before adding elaborate methodology.
• Choose reasoning effort or thinking level based on task difficulty and measured performance, not prestige.
• More reasoning can increase quality on difficult tasks but can also increase latency, token use, tool calls, and cost.
• For current or uncertain facts, tell the model when it must verify rather than rely on memory.
• For tool-using workflows, define selection rules, argument requirements, authorization boundaries, result handling, failure recovery, and stop conditions.
• For long-context work, organize evidence and authority rules instead of assuming a larger context window automatically solves relevance.
• For structured outputs, separate the semantic task from the schema contract.
• For coding, define scope, verification, and what must not change.
• For decisions, require explicit criteria, evidence, uncertainty, and sensitivity analysis where assumptions can reverse the recommendation.
• For agents, distinguish reversible in-scope work from actions that need approval.
• Evaluate prompts on representative tasks. A sophisticated-looking prompt can still perform worse than a simpler one.
• Track trajectory quality for agentic workflows, not only the final answer.
• Maintain provider-specific adapters only where provider behavior or API controls genuinely differ.

Table of Contents

• What Is a Reasoning Model?
• How Reasoning Models Change Prompt Engineering
• 1. Do Not Micromanage Private Reasoning
• 2. Define the Objective Before the Method
• 3. Give the Model Evidence, Not Just Instructions
• 4. Turn Constraints Into Decision Boundaries
• 5. Define an Ambiguity and Clarification Policy
• 6. Calibrate Reasoning Effort to the Workload
• 7. Treat Tool Use as Part of the Reasoning Workflow
• 8. Make Verification Observable
• 9. Separate Reasoning From Structured Output Contracts
• 10. Structure Long Context Around Evidence and Authority
• 11. Add Autonomy and Stop Conditions for Agents
• 12. Keep the Core Prompt Portable, Then Add Model-Specific Adapters
• A Practical Reasoning Model Prompt Framework
• Practical Reasoning Model Prompt Examples
• A Production-Grade Reasoning Model Prompt
• When Not to Use a Reasoning Model
• Common Reasoning Model Prompting Mistakes
• How to Evaluate Reasoning Model Prompts
• Where PrompTessor Fits
• Reasoning Model Prompting Checklist
• Related PrompTessor Guides
• Official Provider Resources
• FAQ

What Is a Reasoning Model?

A reasoning model is a language model designed to spend additional internal computation on tasks that benefit from multi-step analysis, planning, mathematical reasoning, coding, tool use, or other forms of difficult problem solving.

The exact implementation differs by provider and model.

Some models expose a reasoning-effort control. Some use dynamic or adaptive thinking. Some preserve encrypted reasoning-related state between tool calls. Some combine reasoning with tools and agent loops. Some support low-latency modes that reduce the amount of reasoning for simpler work.

So “reasoning model” is a useful category, but it is not one standardized API behavior.

Reasoning Is Not the Same as a Long Answer

A model can reason extensively and return a short answer.

It can also return a long answer without having solved the problem well.

Do not use response length as a proxy for reasoning quality.

INTERNAL REASONING DEPTH
        ≠
VISIBLE ANSWER LENGTH

That distinction matters because many older prompting habits implicitly ask the model to expose a long reasoning trace. Current reasoning-model guidance generally points in the opposite direction: let the model reason internally, then ask for the evidence, result, assumptions, checks, or concise justification that the user actually needs.

Reasoning Models Are Often Best at Problems With Dependencies

Reasoning matters most when one decision depends on another:

• debugging a failure whose root cause is not obvious,
• planning a migration with interacting constraints,
• comparing business options under uncertain assumptions,
• researching a question across conflicting sources,
• using tools in a sequence where later actions depend on earlier results,
• analyzing a large codebase or document set,
• solving mathematical or logical problems,
• or coordinating a long-running agent workflow.

For a simple reformat, short classification, deterministic lookup, or low-latency chat turn, deeper reasoning may add little value.

How Reasoning Models Change Prompt Engineering

Traditional prompt engineering often treated reasoning as something the prompt had to manufacture.

Modern reasoning models shift more of that work into the model and inference system. The prompt can focus on what the model cannot reliably infer from the task alone: the outcome, evidence, constraints, ambiguity policy, tools, verification, output, and completion criteria.

Prompting Moves From Procedure to Contract

Old Prompting Habit	Better Reasoning-Model Pattern
“Think step by step.”	Define the problem, evidence, constraints, and required checks.
Long hand-written reasoning procedure	Describe the real workflow only where order or method matters.
“Be very careful.”	Specify what must be verified and what evidence is required.
“Do not hallucinate.”	Define source authority, freshness, uncertainty, and fallback behavior.
“Use tools when needed.”	Define when tools are required, optional, forbidden, or approval-gated.
“Give the best answer.”	Define success criteria, tradeoffs, and decision criteria.
“Keep going until done.”	Define autonomy, blockers, verification, and the stop condition.

1. Do Not Micromanage Private Reasoning

OpenAI's current reasoning-model guidance recommends keeping prompts simple and direct and says prompting models to “think step by step” or explain their internal reasoning is unnecessary.

Anthropic similarly recommends general instructions over prescriptive reasoning steps for current Claude thinking models.

Google's current Gemini 3.x guidance says its reasoning models respond best to precise, direct instructions and that verbose techniques designed for older models can cause over-analysis.

Those recommendations do not mean methodology never belongs in a prompt. They mean methodology should represent a real task requirement, not an invented chain-of-thought ritual.

Bad: Fake Reasoning Procedure

Think step by step.
First list every possible explanation.
Then analyze each one.
Then challenge yourself.
Then think of counterarguments.
Then reconsider everything.
Then choose the best answer.

Better: Observable Diagnostic Requirements

Identify the most likely root cause of the incident.

Use the logs, deployment diff, metrics, and current implementation.

For each serious hypothesis:
- state the evidence supporting it
- state the evidence against it
- identify what observation would falsify it

Before recommending a fix, verify that the explanation accounts for
both the failure and the timing of the regression.

If the evidence is insufficient, say what additional observation would
resolve the uncertainty.

The second prompt still guides reasoning, but it guides it through evidence and falsifiability rather than hidden mental steps.

Ask for the Useful Explanation, Not the Hidden Trace

If a user needs to understand a conclusion, ask for the evidence used, key assumptions, strongest alternative, material uncertainty, calculation, or a concise justification. Those are useful artifacts that can be evaluated.

2. Define the Objective Before the Method

Reasoning models are capable of choosing a method. They are not capable of knowing which business objective, user priority, or operational outcome you care about unless the prompt tells them.

<objective>
Determine whether we should migrate the billing service from Provider A
to Provider B.

Return one recommendation that accounts for reliability, migration risk,
operational complexity, latency, and three-year cost.
</objective>

Then add only the method constraints that are actually important:

<method_requirements>
Use current contract terms and internal usage data.

Run sensitivity analysis on assumptions capable of reversing the decision.

Do not treat feature-count differences as important unless they affect
one of the stated decision criteria.
</method_requirements>

Separate Objective From Output

OBJECTIVE
Choose the safer migration strategy.

OUTPUT
Return:
- recommendation
- evidence
- risks
- migration sequence
- rollback trigger

A beautifully formatted answer can still fail the objective.

3. Give the Model Evidence, Not Just Instructions

Reasoning quality depends heavily on what the model has to reason from.

A stronger reasoning model does not make missing facts appear. If the task depends on current product behavior, private company data, source documents, logs, code, policies, or other information outside the model's reliable training knowledge, supply or retrieve that evidence.

This is where reasoning-model prompting overlaps with context engineering.

Define Source Authority

<source_authority>
For product capabilities:
1. current first-party documentation
2. current official release notes
3. current first-party pricing pages
4. reputable secondary sources
5. community discussions as qualitative evidence only

If two current authoritative sources conflict, report the conflict instead
of silently choosing one.
</source_authority>

Define Freshness

<freshness_policy>
Verify any fact that can change quickly, including:
- model availability
- software versions
- pricing
- plan limits
- company roles
- API support
- product features
- current incidents

Do not treat familiarity with an entity as proof that remembered
information is current.
</freshness_policy>

Separate Fact, Inference, and Recommendation

<evidence_policy>
Clearly distinguish:
- verified facts
- inference from those facts
- recommendation

Do not present inference as a source fact.

If the evidence is weak or contradictory, preserve that uncertainty in the
final result.
</evidence_policy>

4. Turn Constraints Into Decision Boundaries

“Follow the requirements” is not enough when requirements interact. A reasoning model may find a clever solution that violates an unstated boundary.

<constraints>
The migration must:
- preserve the public API
- avoid downtime
- remain backward compatible for 30 days
- require no data loss
- fit within the existing infrastructure budget

Do not:
- replace the identity provider
- introduce a second database
- change unrelated authentication behavior
</constraints>

Distinguish Hard and Soft Constraints

<hard_constraints>
Must not be violated:
- legal requirements
- security boundary
- max budget
- API compatibility
</hard_constraints>

<preferences>
Optimize when possible:
- lower latency
- smaller diff
- simpler maintenance
</preferences>

5. Define an Ambiguity and Clarification Policy

One of the most important reasoning decisions is whether the model should make an assumption, verify a fact, ask the user, or continue with a qualified answer.

<ambiguity_policy>
When information is missing:

Infer only when:
- the assumption is low risk
- it is easy to reverse
- it does not materially change the result

Verify when:
- the fact can be discovered using available tools
- freshness matters
- the answer would otherwise depend on memory

Ask the user when:
- two plausible interpretations lead to materially different outcomes
- the missing information is not discoverable
- the next action is difficult to reverse

If proceeding with an assumption, state the assumption when it materially
affects the result.
</ambiguity_policy>

6. Calibrate Reasoning Effort to the Workload

Reasoning effort is increasingly a runtime control rather than something prompt wording should simulate. The exact controls differ by provider.

OpenAI

OpenAI's current API documentation exposes reasoning.effort with supported values depending on the specific model. Lower effort favors speed and lower token use, while higher effort can improve difficult tasks by allowing more complete reasoning.

For GPT-6 Astra specifically, none is not supported. See the GPT-6 Astra Prompting Guide.

Anthropic

Claude Fable 5.1 uses adaptive thinking that is always on. Its effort control supports low, medium, high, xhigh, and max. Anthropic recommends starting at high and testing the other levels against your evaluations.

See the Claude Fable 5.1 Prompting Guide.

Google

Gemini 3 models use dynamic thinking, but supported levels and defaults vary by model. Gemini 3.8 Flash supports low, medium, and high, with medium as its current default.

See the Gemini 3.8 Flash Prompting Guide.

Use an Effort Ladder

1. PICK A REASONABLE STARTING LEVEL
        ↓
2. RUN REPRESENTATIVE TASKS
        ↓
3. MEASURE QUALITY / LATENCY / TOKENS / COST
        ↓
4. TEST ONE LEVEL LOWER
        ↓
5. TEST ONE LEVEL HIGHER FOR HARD CASES
        ↓
6. KEEP THE LOWEST LEVEL THAT MEETS THE REQUIREMENT

Higher Effort Can Change More Than Answer Quality

Depending on the model, stronger reasoning settings can also affect time to first useful output, total token use, how often tools are called, how much verification the model performs, how long an agent continues, and how much output budget remains for a large final deliverable.

7. Treat Tool Use as Part of the Reasoning Workflow

A reasoning model with tools is no longer only solving a text problem. It is choosing actions.

<tool_policy>
Use tools when they can provide evidence required to complete the task.

For current facts, prefer current retrieval over memory.

Batch independent read-only calls when possible.

Use sequential calls when a later argument depends on an earlier result.

Do not invent:
- IDs
- file paths
- URLs
- enum values
- dates
- account state
- required function arguments

If required arguments are missing:
1. retrieve them if possible
2. ask if necessary
3. otherwise explain the blocker

After a tool returns data, reason from the actual result rather than the
expected result.
</tool_policy>

For a more complete tool-policy framework, see Function Calling and Tool Use.

Interleaved Reasoning Matters

PLAN
  ↓
CALL TOOL
  ↓
OBSERVE ACTUAL RESULT
  ↓
UPDATE HYPOTHESIS
  ↓
CALL NEXT TOOL
  ↓
VERIFY
  ↓
COMPLETE

Separate Read Actions From Write Actions

<action_policy>
Read-only investigation is allowed.

Reversible in-scope changes are allowed.

Require approval before:
- sending an external message
- deleting data
- making a purchase
- issuing a refund
- deploying to production
- changing account permissions
- making another difficult-to-reverse external change
</action_policy>

Runtime permissions should enforce these boundaries as well. Prompt text is guidance, not a security boundary.

8. Make Verification Observable

“Check your work” is vague. A reasoning model performs better when verification corresponds to observable conditions.

Coding

<verification>
Before finishing:
- reproduce or explain the original failure
- run the relevant test set
- run type or build checks for the affected area
- review the changed diff for unrelated modifications
- confirm the requested behavior
- identify anything that could not be verified
</verification>

Research

<verification>
Before finishing:
- verify time-sensitive claims with current sources
- ensure each material conclusion has supporting evidence
- check whether major sources disagree
- distinguish direct evidence from inference
- list unresolved uncertainty
</verification>

Business Decision

<verification>
Before finalizing the recommendation:
- test whether a plausible change in each major assumption reverses it
- identify the strongest alternative
- check whether any hard constraint is violated
- state what additional evidence would most improve confidence
</verification>

9. Separate Reasoning From Structured Output Contracts

Structured output is often confused with reasoning quality. They solve different problems.

REASONING / TASK INSTRUCTIONS
What should be determined?
What evidence is valid?
What rules apply?
What uncertainty is allowed?

        +

STRUCTURED OUTPUT SCHEMA
What fields exist?
What types are allowed?
What values are required?

        +

APPLICATION VALIDATION
Are the values actually valid for the business?

See Structured Outputs for provider-specific schema behavior.

Example: Risk Classification

<task>
Classify the deployment risk based on the supplied change summary,
test results, affected services, rollback difficulty, and production impact.
</task>

<decision_rules>
CRITICAL:
A likely failure could create irreversible or severe production impact.

HIGH:
A likely failure could materially impact users and rollback is difficult.

MEDIUM:
The change has meaningful uncertainty but rollback is straightforward.

LOW:
The change is narrow, well-tested, and easy to reverse.
</decision_rules>

<evidence>
Do not infer a successful test from the absence of a failure.
Unknown evidence remains unknown.
</evidence>

Then enforce the output shape through the provider's supported structured-output mechanism.

10. Structure Long Context Around Evidence and Authority

Reasoning models often support large context windows, but capacity is not relevance. Giving a model every available document can create more conflict, duplication, stale information, and processing cost.

STABLE INSTRUCTIONS
        ↓
SOURCE / AUTHORITY RULES
        ↓
LARGE CONTEXT
        ↓
CURRENT TASK
        ↓
OUTPUT REQUIREMENTS

See Long-Context Prompting.

Example

<source_rules>
Treat the 2026 policy as authoritative when it conflicts with the archived
2025 policy.

Use incident reports as evidence of observed behavior, not as policy.

If two current policy sections conflict, report the conflict.
</source_rules>

<documents>
  <document id="policy_2026">...</document>
  <document id="policy_2025">...</document>
  <document id="incident_reports">...</document>
</documents>

<task>
Determine whether the proposed refund workflow complies with the current
policy.
</task>

11. Add Autonomy and Stop Conditions for Agents

A single-answer reasoning prompt can end when it returns a result. An agentic reasoning prompt needs to define what the model may continue doing between the initial request and final answer.

See AI Agent Prompts.

Autonomy Block

<autonomy>
Proceed with reversible in-scope work without asking the user to confirm
the original request again.

Ask before actions that are destructive, external, financially consequential,
or materially outside the requested scope.

If one workstream is blocked, complete independent work first.

Do not stop with a plan for work you can still perform.
</autonomy>

Stop Condition

<stop_condition>
The task is complete only when:
- the requested deliverable exists
- required verification is complete
- known blockers are documented
- no authorized in-scope step remains unfinished
</stop_condition>

12. Keep the Core Prompt Portable, Then Add Model-Specific Adapters

OpenAI, Claude, and Gemini now share several high-level prompting principles, but the implementations are not identical.

CORE TASK PROMPT
- objective
- context
- evidence rules
- constraints
- ambiguity policy
- tool semantics
- verification
- output
- completion

        ↓

MODEL ADAPTER
OpenAI
- reasoning.effort
- Responses API behavior
- model-specific instruction rules

Claude
- effort
- adaptive thinking behavior
- conversation / thinking-state requirements

Gemini
- thinking_level
- Gemini long-context / multimodal conventions
- tool and reasoning-state behavior

        ↓

EVALUATION
- task success
- quality
- latency
- tokens
- cost
- tool trajectory
- consistency

For a broader cross-model strategy, see How to Write Prompts for ChatGPT, Claude, Gemini, and Grok.

Do Not Force Provider-Specific Behavior Into the Core Prompt

If one model requires a runtime parameter, configure the parameter. If one provider recommends a specific message interface, use that interface. If one model has a consistent failure mode, add a small adapter for that failure mode.

A Practical Reasoning Model Prompt Framework

<objective>
What complete outcome should be delivered?
</objective>

<context>
What background, state, or domain information matters?
</context>

<source_authority>
What evidence is authoritative?
How should conflicts be resolved?
</source_authority>

<constraints>
What must remain true?
What must not be changed?
</constraints>

<ambiguity_policy>
When should the model infer, verify, ask, or qualify?
</ambiguity_policy>

<tool_policy>
When should tools be used?
What arguments must not be guessed?
What actions need approval?
</tool_policy>

<verification>
What observable checks must pass?
</verification>

<output>
What should the final deliverable contain?
</output>

<stop_condition>
When is the task actually complete?
</stop_condition>

Practical Reasoning Model Prompt Examples

Example 1: Debug a Production Regression

<objective>
Find the most likely cause of the p95 API latency regression introduced
after the latest deployment and recommend the smallest safe fix.
</objective>

<evidence>
Use:
- deployment diff
- request traces
- database timings
- infrastructure metrics
- relevant source files

Do not infer causality from timing alone.
</evidence>

<diagnostic_requirements>
For each serious hypothesis:
- supporting evidence
- contradicting evidence
- a falsifying observation

Update the hypothesis if new tool results disagree with it.
</diagnostic_requirements>

<scope>
Do not refactor unrelated performance code.
</scope>

<verification>
The final recommendation must explain:
- why the regression started at the observed time
- why the affected requests are slower
- how the fix changes that mechanism
- how to verify the improvement
</verification>

Example 2: Current Technical Research

<objective>
Determine the current production-ready options for implementing browser
automation with multimodal AI agents.
</objective>

<source_authority>
Prefer:
1. current first-party product documentation
2. current first-party API references
3. current official release notes
4. reputable technical reporting
</source_authority>

<freshness>
Verify current model names, API status, preview/GA status, pricing, and
tool support before relying on memory.
</freshness>

<evidence_policy>
Separate:
- verified capability
- documented limitation
- your inference
- recommendation
</evidence_policy>

<output>
Return:
- comparison table
- important differences
- deployment risks
- best option by use case
- unresolved uncertainty
</output>

Example 3: Business Decision With Sensitivity Analysis

<objective>
Recommend whether the company should build or buy the new support
automation platform.
</objective>

<criteria>
Evaluate:
- implementation time
- three-year cost
- reliability
- security
- vendor lock-in
- integration complexity
- operational ownership
</criteria>

<hard_constraints>
- customer data must remain in approved regions
- launch cannot slip beyond Q1
- ongoing operational headcount cannot exceed 1 FTE
</hard_constraints>

<sensitivity>
Identify assumptions capable of reversing the recommendation.

For each:
- current assumption
- plausible alternate value
- whether the recommendation changes
</sensitivity>

<output>
Return one recommendation, the strongest alternative, major assumptions,
sensitivity analysis, confidence, and the next evidence worth collecting.
</output>

Example 4: Long-Context Policy Analysis

<source_rules>
The current policy takes precedence over archived versions.

Official policy text is authoritative.
Support tickets are evidence of implementation problems, not policy.
</source_rules>

<documents>
... current policy ...
... prior policy ...
... support ticket sample ...
</documents>

<task>
Identify changes that materially affect refund eligibility, renewal,
termination, or customer communication.
</task>

<evidence_policy>
Cite the source identifier for each material finding.
If the current policy is internally inconsistent, report the inconsistency.
</evidence_policy>

<output>
Return:
- change
- old rule
- new rule
- evidence
- operational impact
- unresolved ambiguity
</output>

Example 5: Structured Data Extraction With Reasoning

<task>
Extract the commercial terms from the supplied agreement.
</task>

<interpretation_rules>
Do not infer a value that is not stated.

If a term is conditional, preserve the condition.

If two sections define different values for the same term, return both and
mark the conflict.

Normalize dates only when the source date is unambiguous.
</interpretation_rules>

<fields>
- effective_date
- renewal_type
- renewal_term
- cancellation_notice_days
- minimum_commitment
- payment_terms
- liability_cap
- governing_law
- conflicts
</fields>

Example 6: Tool-Using Operations Agent

<objective>
Resolve the customer's access issue if it can be resolved safely with the
available account and subscription tools.
</objective>

<tool_policy>
Retrieve current account state before making account-specific claims.

Verify subscription state before changing entitlements.

Do not invent IDs or account values.

Batch independent read-only lookups.
</tool_policy>

<authorization>
Read-only investigation is allowed.

Account writes are allowed only when they are reversible and directly
required by the user's request.

Refunds, plan cancellation, external messages, and destructive changes
require the authorization defined by the application.
</authorization>

<recovery>
Before retrying a failed write, verify whether the first attempt actually
succeeded.

Never report success when state is unknown.
</recovery>

<stop_condition>
Finish when the issue is resolved or the next step genuinely requires
unavailable information or authorization.
</stop_condition>

Example 7: Migration Planning

<objective>
Create a migration plan from Framework 14 to Framework 16 that minimizes
production risk.
</objective>

<constraints>
- preserve existing behavior
- no big-bang rewrite
- production must remain deployable throughout the migration
- identify incompatible dependencies before framework changes
</constraints>

<planning_rules>
Order steps by real dependency.

Do not include work only because it is generally considered a best practice.

For each phase define:
- prerequisite
- change
- verification
- rollback condition
</planning_rules>

<output>
Return:
- dependency map
- staged migration plan
- major compatibility risks
- verification gates
- rollback triggers
</output>

Example 8: Quantitative Analysis

<objective>
Determine whether the observed conversion-rate increase is large enough to
justify shipping Variant B.
</objective>

<data_rules>
Use only the supplied experiment data.

Check sample sizes, exposure imbalance, confidence interval, and whether the
stopping rule was respected.

Do not turn statistical significance into a business recommendation without
considering practical effect size.
</data_rules>

<decision_rule>
Recommend shipping only if:
- the result meets the agreed statistical threshold
- the practical lift is large enough to matter
- no guardrail metric materially regresses
</decision_rule>

<output>
Return:
- statistical result
- practical interpretation
- guardrail check
- recommendation
- uncertainty
</output>

A Production-Grade Reasoning Model Prompt

The following example combines the most important reasoning-model prompting patterns into one research-and-decision workflow.

Example: Technical Due-Diligence Agent

<objective>
Evaluate whether Product X is suitable as the company's primary AI agent
runtime for the next 24 months.

Deliver a recommendation that can be reviewed by engineering leadership.
</objective>

<decision_criteria>
Evaluate:
- reliability and operational maturity
- tool / function support
- model flexibility
- state and context handling
- observability
- security and permissions
- deployment options
- vendor lock-in
- implementation effort
- three-year cost
</decision_criteria>

<source_authority>
For current product capabilities:
1. official current documentation
2. official API references
3. official pricing and release notes
4. current provider announcements
5. reputable independent technical sources
6. community reports as qualitative evidence only

For internal requirements:
1. supplied architecture requirements
2. supplied security policy
3. supplied usage data
4. existing implementation notes

If authoritative current sources conflict, report the conflict.
</source_authority>

<freshness_policy>
Search or retrieve current sources for:
- model support
- tool support
- API status
- pricing
- deployment availability
- product limitations
- security or governance features

Do not treat recognition of a product name as proof that remembered
information is current.
</freshness_policy>

<ambiguity_policy>
Infer only low-risk assumptions that do not materially change the decision.

Verify discoverable facts with tools.

Ask the user only when missing information:
- cannot be discovered
- materially changes the recommendation
- or is required before an irreversible action

For unresolved but non-blocking uncertainty, continue and label it.
</ambiguity_policy>

<tool_policy>
Use web, documentation search, internal files, calculator, and code execution
when they provide evidence required for the decision.

Batch independent research queries where practical.

Use sequential calls when the next query depends on a previous result.

Never invent:
- prices
- limits
- product support
- API parameters
- benchmarks
- internal usage data

After tool results arrive, update the analysis from the results rather than
the expected outcome.
</tool_policy>

<evidence_policy>
For every material conclusion:
- identify supporting evidence
- distinguish fact from inference
- note important contrary evidence

Do not use benchmark numbers unless the evaluation setting is sufficiently
clear to make the comparison meaningful.

Do not treat vendor marketing language as independent validation.
</evidence_policy>

<risk_policy>
Identify:
- integration risk
- operational risk
- pricing risk
- vendor-dependency risk
- migration / exit risk
- security or permissions risk

Separate likelihood from impact.
</risk_policy>

<sensitivity_analysis>
Identify assumptions capable of reversing the recommendation.

For each material assumption:
- state the current value or belief
- give a plausible alternative
- explain whether the recommendation changes
</sensitivity_analysis>

<verification>
Before finalizing:
- verify current time-sensitive facts
- confirm each decision criterion has evidence
- check for major contradictory sources
- test major assumptions
- identify the strongest alternative
- identify the most important unresolved uncertainty
- confirm that no hard internal requirement is violated
</verification>

<output>
Return:

1. Executive Recommendation
2. Decision Summary Table
3. Evidence by Criterion
4. Major Risks
5. Sensitivity Analysis
6. Strongest Alternative
7. Unresolved Uncertainty
8. Next Evidence to Collect
9. Final Confidence

Keep the executive recommendation concise.
Use detail in the evidence sections where it improves auditability.
</output>

<stop_condition>
The task is complete when:
- every decision criterion has been assessed
- material current facts have been verified
- major uncertainty is visible
- sensitivity analysis is complete
- one recommendation is made
- the strongest alternative is explained
</stop_condition>

Why This Prompt Works

Block	What It Controls	Failure Mode It Reduces
Objective	Decision target	Interesting research with no usable recommendation
Decision criteria	What “better” means	Feature-count comparisons and arbitrary weighting
Source authority	Evidence hierarchy	Using stale or low-quality sources as equal evidence
Freshness policy	Current verification	Authoritative-sounding stale facts
Ambiguity policy	Infer vs verify vs ask	Too many questions or hidden assumptions
Tool policy	Research execution	Guessed data and inefficient tool use
Evidence policy	Fact vs inference	Unsupported synthesis
Risk policy	Downside analysis	Recommendation based only on capabilities
Sensitivity	Decision robustness	Recommendation that collapses under a small assumption change
Verification	Pre-completion checks	Stopping after plausible analysis
Output	Communication contract	Unstructured answer that is hard to review
Stop condition	Completion	Ending before all decision work is done

Notice what the prompt does not contain: “think extremely hard,” “use maximum intelligence,” a fake 25-step private reasoning script, or instructions to repeatedly reconsider the same answer.

When Not to Use a Reasoning Model

A reasoning model is not automatically the best model for every request. Deeper reasoning can be wasteful when the task is simple and the correct transformation is obvious.

Good Candidates for Lower-Reasoning or Faster Models

• simple classification,
• basic extraction,
• format conversion,
• short rewriting,
• deterministic templating,
• routine customer responses with retrieved facts,
• simple search-result summarization,
• high-throughput low-risk tasks,
• latency-sensitive chat turns.

Good Candidates for More Reasoning

• complex debugging,
• non-trivial coding changes,
• multi-source research,
• planning under constraints,
• quantitative analysis,
• multi-step tool use,
• long-running agents,
• decisions with meaningful tradeoffs,
• ambiguous problems where assumptions matter.

What is the lowest-cost, lowest-latency configuration that reliably meets the task's quality and risk requirements?

Common Reasoning Model Prompting Mistakes

1. Treating “Think Step by Step” as a Universal Upgrade

Modern reasoning models already reason internally. Define observable requirements instead.

2. Using Maximum Effort for Everything

Higher reasoning settings can increase latency, cost, and tool use without meaningful quality gains on routine tasks.

3. Writing a Long Prompt Without Defining the Actual Objective

More instruction text cannot compensate for an unclear success condition.

4. Specifying Method Instead of Evidence

Tell the model what information should determine the answer, not merely what mental sequence to perform.

5. Asking for Confidence Without Defining Uncertainty

A numeric confidence score is often arbitrary unless the task has a calibrated interpretation. Ask for evidence gaps and decision-changing uncertainty.

6. Saying “Do Not Hallucinate” Without a Source Policy

Define authoritative sources, freshness requirements, and what to do when information is missing.

7. Giving Tools Without Tool Rules

Reasoning ability does not automatically create safe argument handling, authorization, retry logic, or completion behavior.

8. Using Prompt Text as a Security Boundary

Permissions, approvals, schemas, and destructive-action restrictions should also be enforced in the application.

9. Letting the Model Guess Tool Arguments

IDs, dates, file paths, enums, account values, and other required arguments should be discovered or requested.

10. Mixing Task Semantics With JSON Formatting

Use prompt instructions for meaning and structured-output mechanisms for schema conformance.

11. Sending Huge Context Without Source Authority

A million-token window can still contain conflicting and irrelevant information.

12. Asking an Agent to “Keep Going” Without Boundaries

Define what is authorized, what requires approval, and what actually counts as done.

13. Over-Checking Low-Risk Work

Verification should scale with the risk and difficulty of the task.

14. Evaluating Only the Final Answer of an Agent

A good final answer can hide bad tool selection, unsafe actions, unnecessary loops, or failures that happened earlier.

15. Copying One Provider's Reasoning Control to Another

OpenAI, Claude, and Gemini expose different models, defaults, levels, APIs, and state behavior.

16. Changing Prompt and Reasoning Effort at the Same Time

If you change multiple variables together, you cannot tell which change improved or degraded the result.

17. Assuming a Longer Prompt Is a Better Prompt

Every instruction should correspond to a real requirement, failure mode, or communication need.

How to Evaluate Reasoning Model Prompts

Reasoning prompts should be evaluated against the behavior you actually care about. See AI Prompt Evaluation.

Build Representative Test Cases

• normal cases,
• ambiguous cases,
• missing-information cases,
• conflicting-evidence cases,
• tool failures,
• edge cases,
• and tasks where the model should stop or ask instead of continuing.

Measure More Than Correctness

Dimension	Question
Task success	Did the result actually solve the requested problem?
Evidence	Are material conclusions supported?
Constraint adherence	Did the model preserve hard requirements?
Ambiguity handling	Did it infer, verify, or ask appropriately?
Tool behavior	Were the right tools called with valid arguments?
Recovery	Did the model respond correctly to tool failures or contradictory data?
Verification	Did it perform the checks required by the task?
Completion	Did it finish the full requested scope?
Latency	How long did the task take?
Token use	How much input, reasoning-related output, and final output was consumed?
Cost	What was the cost per successful task?
Consistency	Does behavior remain reliable across repeated trials?

Evaluate Prompt and Effort Separately

BASELINE PROMPT @ BASELINE EFFORT
          ↓
CHANGE PROMPT ONLY
          ↓
MEASURE
          ↓
CHANGE EFFORT ONLY
          ↓
MEASURE
          ↓
COMBINE ONLY IF BOTH HELP

For Agents, Evaluate the Trajectory

Review tool selection, call arguments, call order, parallel vs sequential behavior, state changes, permission handling, recovery, verification, and whether the agent stopped at the right time.

Where PrompTessor Fits

PrompTessor fits at the prompt-design and iteration layer.

ROUGH TASK / EXISTING PROMPT
          ↓
PrompTessor
├ Generate
├ Analyze
├ Optimize
├ Refine
├ Compare iterations
└ Save reusable prompts
          ↓
REASONING MODEL PROMPT CANDIDATE
          ↓
TARGET APPLICATION
├ model
├ reasoning / thinking setting
├ tools
├ schemas
├ context
├ permissions
└ runtime state
          ↓
REAL OUTPUT / TRAJECTORY
          ↓
EVALUATION
          ↓
REFINE / VERSION / RETEST

PrompTessor can help identify prompt-level problems such as an unclear objective, missing context, weak constraints, ambiguous output requirements, insufficient evidence rules, unclear model fit, or instructions that are unnecessarily verbose or contradictory.

PrompTessor does not configure OpenAI reasoning effort, Claude effort, Gemini thinking level, production tools, provider-native schemas, permissions, subagent orchestration, or evaluation infrastructure in your application.

Use PrompTessor to improve the instruction artifact, then validate that prompt with the exact reasoning model, effort level, tools, and context it will use in production.

Reasoning Model Prompting Checklist

• Is the real objective explicit?
• Does the prompt define success rather than merely request “a good answer”?
• Have unnecessary “think step by step” instructions been removed?
• Does any prescribed method correspond to a real workflow requirement?
• Is the relevant evidence actually available?
• Are authoritative sources identified?
• Are fast-changing facts required to be verified?
• Are facts, inference, and recommendations distinguishable?
• Are hard constraints separated from preferences?
• Does the model know what it must not change?
• Is there an ambiguity policy for infer vs verify vs ask?
• Is the reasoning or thinking setting appropriate for the workload?
• Has the effort level been evaluated rather than chosen by intuition?
• Are provider-specific reasoning settings kept out of the generic core prompt?
• If tools are available, are selection rules clear?
• Must required tool arguments be discovered instead of guessed?
• Are read-only and write actions distinguished?
• Are high-impact actions protected by runtime authorization?
• Does the model update its plan from real tool results?
• Are verification criteria observable?
• Does verification scale with task risk?
• For structured output, are semantic rules separate from schema enforcement?
• For long context, are sources clearly delimited?
• Are source priority and conflict rules defined?
• For agents, is reversible in-scope autonomy explicit?
• Is there a clear stop condition?
• Can blocked workstreams be separated from independent work?
• Are representative and edge-case evals available?
• Are prompt changes and effort changes tested separately?
• For agents, is trajectory quality evaluated in addition to the final answer?
• Are latency, token use, and cost measured per successful task?

Related PrompTessor Guides

• GPT-6 Astra Prompting Guide
• Claude Fable 5.1 Prompting Guide
• Gemini 3.8 Flash Prompting Guide
• How to Write Prompts for ChatGPT, Claude, Gemini, and Grok
• Context Engineering
• System Prompts
• Function Calling and Tool Use
• AI Agent Prompts
• Long-Context Prompting
• Structured Outputs
• AI Prompt Evaluation

Official Provider Resources

• OpenAI — Reasoning Models
• OpenAI — Reasoning Best Practices
• OpenAI — Prompt Engineering
• Anthropic — Claude Prompting Best Practices
• Anthropic — Effort
• Anthropic — Prompting Claude Fable 5.1
• Google AI for Developers — Prompt Design Strategies
• Google AI for Developers — Gemini 3 Developer Guide
• Google AI for Developers — Gemini 3.8 Flash

FAQ

What is reasoning model prompting?

Reasoning model prompting is the practice of designing instructions, context, evidence rules, constraints, tool policies, output requirements, and verification criteria for models that perform internal multi-step reasoning or expose reasoning-effort controls.

How is prompting a reasoning model different from prompting a normal LLM?

Reasoning models generally need less micromanagement of hidden reasoning steps. The prompt should focus more on the problem, evidence, constraints, action boundaries, verification, and expected result.

Should I tell a reasoning model to think step by step?

Usually not. OpenAI's current reasoning-model guidance explicitly recommends avoiding chain-of-thought prompts, and Anthropic recommends general reasoning instructions over prescriptive reasoning steps. Define observable requirements instead.

Should I ask a reasoning model to explain its reasoning?

Ask for the evidence, assumptions, calculation, concise justification, strongest alternative, or uncertainty that is useful to the user. A private chain-of-thought transcript is not necessary for most applications.

Does a longer prompt make a reasoning model reason better?

No. Prompt length is not a measure of quality. Add instructions only when they define a real requirement, constraint, failure mode, evidence rule, action boundary, or communication need.

What should a reasoning-model prompt contain?

For a complex task, useful components include objective, context, source authority, constraints, ambiguity policy, tool policy, verification, output requirements, and a stop condition.

What is reasoning effort?

Reasoning effort is a model or provider control that trades additional internal reasoning against latency, token use, and cost. The available levels and defaults differ by model.

Should I always use the highest reasoning effort?

No. Start with an appropriate level, evaluate the task, and use the lowest level that reliably meets the quality requirement. Higher effort can add cost and latency without helping routine tasks.

Is reasoning effort standardized across OpenAI, Claude, and Gemini?

No. OpenAI exposes model-dependent reasoning effort, Claude Fable 5.1 uses effort with always-on adaptive thinking, and Gemini models expose model-specific thinking levels and defaults.

How should I prompt a reasoning model for current information?

Give it access to a current search or retrieval source and explicitly require verification for facts such as pricing, model availability, versions, policies, current roles, or fast-changing product capabilities.

How should I prompt a reasoning model for coding?

Define the requested behavior, relevant code context, scope, what must not change, tool behavior, testing requirements, verification, and completion condition. Avoid generic instructions to “think harder.”

How should I prompt a reasoning model for research?

Define source authority, freshness requirements, evidence standards, conflict handling, fact-vs-inference rules, and the exact decision or synthesis the research must support.

How should I prompt a reasoning model for business decisions?

Define decision criteria, hard constraints, evidence, assumptions, sensitivity analysis, strongest alternative, and what evidence would change the recommendation.

How should I prompt reasoning models to use tools?

Specify when tools are required, which arguments must be discovered instead of guessed, when calls can be parallel, how failures should be handled, what actions need approval, and when the task is complete.

Do reasoning models eliminate hallucinations?

No. Stronger reasoning can improve analysis, but a model can still reason from stale, missing, or incorrect premises. Reliable workflows need current evidence, source authority, verification, and application-level validation.

Do reasoning models need structured outputs?

They can benefit from structured outputs when downstream software needs a stable schema. The prompt should define the semantic task, while the provider's structured-output feature should enforce the supported response shape.

How should I handle long context with reasoning models?

Provide only relevant context, delimit sources, define source authority and conflict handling, place the current task clearly, and preserve important instructions and state across long workflows.

What is the difference between reasoning prompting and context engineering?

Prompting defines the task and behavioral instructions. Context engineering determines what instructions, evidence, memory, state, tools, and retrieved information are available to the model at the right time.

What is the difference between a reasoning prompt and an agent prompt?

A reasoning prompt can ask for a single complex result. An agent prompt must additionally define action boundaries, tool behavior, state, recovery, autonomy, approvals, and completion across multiple steps.

How do I evaluate a reasoning-model prompt?

Use representative test cases and measure task success, evidence quality, constraint adherence, tool behavior, verification, completion, latency, tokens, cost, and consistency. For agents, evaluate the full trajectory as well as the final answer.

Should I optimize the prompt and reasoning effort at the same time?

Prefer testing them separately first. Otherwise you may not know whether the behavioral change came from the prompt or from additional reasoning compute.

Can one reasoning prompt work across OpenAI, Claude, and Gemini?

A strong core task contract can often transfer, but provider-specific reasoning settings, tool interfaces, message semantics, and model behaviors may require small adapters.

Can PrompTessor optimize prompts for reasoning models?

PrompTessor can help generate, analyze, optimize, refine, compare, and save prompt candidates with model-aware context. The final prompt should still be evaluated with the exact model, reasoning setting, tools, context, and permissions used in production.

Conclusion

Reasoning models do not eliminate prompt engineering. They make the most valuable parts of prompt engineering more obvious.

The model can handle more of the internal problem-solving process. Your job is to make the problem worth solving correctly.

STRONG REASONING MODEL PROMPT
=
CLEAR OBJECTIVE
+
RIGHT CONTEXT
+
TRUSTED EVIDENCE
+
EXPLICIT CONSTRAINTS
+
AMBIGUITY POLICY
+
CALIBRATED REASONING
+
TOOL RULES
+
OBSERVABLE VERIFICATION
+
USEFUL OUTPUT
+
CLEAR COMPLETION

For simple work, that may fit in a few lines. For a long-running coding agent, research system, or high-impact decision workflow, the prompt becomes part of the operating contract that keeps reasoning connected to evidence, actions, and a measurable definition of success.

The best reasoning prompt is not the one that tells the model how to think the most. It is the one that makes it easiest to determine what a correct, useful, and complete result actually requires.