OpenAI’s o-series models — o1, o3, and o4-mini — are trained to think for longer before responding. Rather than generating an answer token by token in a single forward pass, they produce an internal chain of thought before committing to a final output. This makes them significantly more capable on tasks that require sustained multi-step reasoning: mathematics, competitive programming, scientific analysis, and complex agentic workflows.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/openai/openai-cookbook/llms.txt
Use this file to discover all available pages before exploring further.
The o-series model lineup
o1
The first reasoning model. Best for structured tasks with clear correct answers. Strong on math and coding benchmarks. Use o3 or o4-mini for new projects where possible.
o3
The most capable reasoning model. Top of the line for difficult multi-step problems, long agentic rollouts, and tasks requiring deep exploration. Higher latency and cost than o4-mini.
o4-mini
A smaller, faster, cheaper reasoning model that retains most of o3’s capability on coding and math tasks. The recommended starting point for most latency-sensitive reasoning applications.
When to use reasoning models
Reasoning models outperform standard models most clearly when the task requires:- Multi-step arithmetic or algebra — problems where intermediate results feed into later steps.
- Competitive programming — algorithm design and implementation under constraints.
- Formal reasoning — logic puzzles, proof verification, structured inference.
- Long-horizon agentic tasks — workflows where the model must plan and execute across many tool calls without losing track of the goal.
- Scientific or technical analysis — interpreting experimental results, reviewing code for subtle bugs, or drafting technical documents where accuracy is paramount.
For straightforward tasks — translation, summarization, simple question answering — standard models like GPT-4o are faster and cheaper. Use reasoning models when accuracy on hard tasks justifies the additional cost and latency.
Calling a reasoning model
The Responses API is the recommended interface for o-series models. It persists reasoning tokens between tool calls within a turn, which leads to better decisions about when and how to use tools.reasoning.encrypted_content back into subsequent requests lets the model refer to its previous reasoning trace without reconstructing a plan from scratch after each tool call. This improves both accuracy and latency.
Reasoning effort
All o-series models expose areasoning_effort parameter with three settings:
| Setting | Use when |
|---|---|
low | Latency matters more than peak accuracy; task is well-defined and relatively straightforward |
medium | Default; suitable for most production use cases |
high | Accuracy matters most; task is complex, ambiguous, or requires deep exploration |
Writing effective developer prompts
In o-series models, the system prompt is automatically converted to a developer message internally. For clarity and correctness, treat all top-level instructions as the developer prompt.Context and role setting
Begin with a clear role and the set of actions available to the model:Tool call ordering
Reasoning models are trained to accomplish goals with tools but can make mistakes in ordering. For well-defined workflows, specify the sequence explicitly:Tool use boundaries
Define when the model should and should not use tools:Writing effective function descriptions
A function’s description is the primary signal the model uses to decide when and how to call it. Put the most important constraints first:Avoiding common pitfalls
Do not prompt reasoning models to reason more
Do not prompt reasoning models to reason more
Unlike standard models, reasoning models already produce an internal chain of thought. Asking them to “plan extensively before each step” or “think step by step” adds overhead without improving results — and may hurt performance by interfering with the model’s internal reasoning process.
Guard against hallucinated tool calls
Guard against hallucinated tool calls
o3 in particular can occasionally promise to call a function in a future turn without actually doing so. Add an explicit instruction to prevent this:Also enable
strict: true on all tool schemas to ensure the model always produces valid arguments.Manage long conversation histories
Manage long conversation histories
If the conversation history grows very long with tool call outputs that are no longer relevant, the model may produce terse or incomplete responses. Prune stale tool outputs from the context and replace them with a concise summary in the user message. Starting a new conversation thread for unrelated topics also helps.
Keep tool schemas flat when possible
Keep tool schemas flat when possible
Deeply nested parameter objects can cause the model to omit or misuse arguments. Prefer flat schemas where all fields are at the top level. When nesting is necessary for domain reasons (configuration payloads, rich search filters), use strict schemas and clear field descriptions to guard against invalid combinations.
Tool count and schema complexity
As of mid-2025, o3 and o4-mini handle up to approximately 100 tools with up to 20 arguments each within their training distribution. Beyond those limits, performance degrades. Even within those bounds:- Clear function descriptions become more critical as the tool list grows.
- Overlapping tool purposes introduce ambiguity — disambiguate them in the developer prompt.
- Adding an explicit rule like “Only use tools X, Y, Z. Do not invent tool calls or defer them to future turns.” prevents hallucination as tool sets grow.
Choosing between o3 and o4-mini
Start with o4-mini for most reasoning tasks. It is faster and cheaper than o3 and retains most of its capability on coding and math. Move to o3 when:- The task requires sustained deep exploration across many reasoning steps.
- You are running long agentic rollouts where the model needs to revisit and revise earlier decisions.
- Accuracy on very hard problems (top-tier math olympiad, complex proof verification) is the primary requirement and latency is acceptable.