# The OpenAI model family: GPT, reasoning models, and when to use each
OpenAI ships two fundamentally different kinds of behavior under one roof: fast general answering, and deliberate reasoning that thinks before it responds. Picking the wrong mode wastes either your money or your accuracy. This lesson is about routing: matching the task to the model (or the reasoning level) so you stop overpaying for trivial work and stop under-powering hard work.
Historically OpenAI split these into two named lineups: the GPT "chat" models (GPT-4o and friends) and the "o" series reasoning models (o3, o4-mini). With the GPT-5 family, that split has largely collapsed into a single model that decides how hard to think, but the underlying tradeoff is exactly the same, so the routing logic below still holds.
Fast general answering is optimized for breadth and latency. You send a prompt, tokenstokensA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.Voir la définition complète → stream back almost immediately. This mode is excellent at writing, summarizing, classification, formatting, code completion, and conversation.
Reasoning spends extra hidden compute working through a problem before emitting the final answer. That hidden work is called *reasoning *: internal steps you pay for and never see. It trades latency and cost for accuracy on multi-step problems: math, hard debugging, planning, scientific analysis, and anything where a wrong intermediate step ruins the result.
The family also comes in smaller variants (mini and nano tiers). Same general capability profile, lower cost, lower latency, slightly less depth. A mini model with reasoning turned up still "thinks," just less expensively.
The official mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Voir la définition complète → of who's who and what each is tuned for lives in the models documentation. Check it when names change; the routing logic below does not.
Ask: does this task have a verifiable chain of steps where an early mistake breaks the outcome?
Then ask a second question for cost: is this high-volume or latency-sensitive? If yes, drop to a mini/nano variant.
Task A: "Rewrite this paragraph to be more concise and confident."
This is a one-shot transformation. There is no chain to get wrong. Keep reasoning low (or off) and let it answer fast.
from openai import OpenAI
client = OpenAI()
resp = client.responses.create(
model="gpt-5",
reasoning={"effort": "minimal"},
input="Rewrite to be concise and confident:\n\n" + paragraph,
)
print(resp.output_text)Task B: "Here are three vendor contracts. Find every clause where renewal terms conflict, and tell me which contract wins under the precedence rules in section 12."
That is multi-step: extract clauses, compare them, apply precedence logic, resolve conflicts. An early misread cascades. Turn reasoning up and let it spend tokenstokensA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.Voir la définition complète →.
resp = client.responses.create(
model="gpt-5",
reasoning={"effort": "high"},
input=contracts_text + "\n\nFind conflicting renewal clauses and resolve per section 12.",
)
print(resp.output_text)Two things to notice. First, both calls use the Responses APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Voir la définition complète → (responses.create), OpenAI's current primary interface. Second, the reasoning.effort knob (minimal / low / medium / high) trades depth for cost and latency. On the GPT-5 family this is your main lever: same model, different amount of thinking. If you still target an older reasoning model like o3 or o4-mini, the same parameter applies, though those are now legacy choices in most workflows.
In the ChatGPT apps the default is now a single GPT-5 model that auto-routes: it decides internally whether to answer fast or think harder. You still get manual control:
Older o-series names (o3, o4-mini) may still appear under legacy or advanced menus for some plans, but the GPT-5 family is the default path forward.
A practical habit: start fast, escalate to explicit thinking only when you catch the model skipping logic. Thinking costs more and is slower, so do not make it your default.
Model choice, or how hard you tell it to think, changes how the rest of the ChatGPT toolset behaves.
Advanced Data Analysis (Code Interpreter). When you upload a CSV and ask for analysis, the model writes and runs Python in a sandbox. High reasoning effort is far better at planning a correct multi-step analysis (clean, join, aggregate, validate) before writing the code. A fast answer is fine for "make a quick bar chart."
Canvas. For long-form writing and code you edit side by side, fast answering keeps the loop tight. Turn reasoning up only when the *content itself* requires hard logic, like deriving an algorithm.
Custom GPTs and Projects. Your custom instructions and memory shape behavior either way, but a model thinking harder will follow multi-part instructions more reliably because it can plan around them. If your Custom GPT keeps ignoring constraint #4 of 6, the reasoning level may be the bottleneck.
The ChatGPT agent and scheduled tasks. Autonomous, multi-step work (browse, click, synthesize) leans on heavier reasoning by design, because each step depends on the last.
The pricing details change, so reason qualitatively (the live numbers are on the pricing page):
mini/nano variants exist precisely so you can run reasoning at scale without that cost exploding. For batch classification of 100k support tickets, a mini model is almost always the right call over the flagship.effort at minimal or low.A simple internal rule for teams: default to fast answering, allow high reasoning effort on an explicit allowlist of task types, and reserve the flagship at high effort for low-volume, high-stakes work.
Vérification des acquis
1. What is the fundamental distinction between general GPT models and reasoning models?
2. According to the lesson, what single question best determines whether to route a task to a reasoning model?
3. What are 'reasoning tokens' as described in the lesson?
4. Select ALL tasks that are best suited to a general GPT model rather than a reasoning model.
Sélectionnez toutes les réponses correctes.
5. Select ALL correct statements about the 'mini' and 'nano' variants.
Sélectionnez toutes les réponses correctes.
Once you turn reasoning up, your promptingpromptingPrompt engineering is the practice of designing and refining text inputs to guide large language models toward accurate, relevant, and reliable outputs.Voir la définition complète → style should change, or you waste its strength.
Stop hand-holding the steps. With fast answering you often add "think step by step." A model already reasoning internally does this on its own, and spelling out the steps can actually constrain it. Instead, state the goal, the constraints, and the success criteria, then get out of the way.
Weak prompt when reasoning is high:
> First list the clauses. Then compare them. Then apply section 12. Then conclude.
Stronger:
> Resolve all renewal-term conflicts across these contracts. Success = every conflict identified with the controlling contract named and the section-12 rule that decides it. Flag anything ambiguous rather than guessing.
Give it room and a clear finish line. A reasoning model rewards a crisp definition of "done" and explicit instructions about uncertainty ("flag, don't guess"). It also honors structured outputs well, so pair it with a JSON schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.Voir la définition complète → when the answer feeds another system.
schema = {
"name": "conflict_report",
"schema": {
"type": "object",
"properties": {
"conflicts": {
"type": "array",
"items": {
"type": "object",
"properties": {
"clause": {"type": "string"},
"winning_contract": {"type": "string"},
"rule": {"type": "string"},
},
"required": ["clause", "winning_contract", "rule"],
"additionalProperties": False,
},
}
},
"required": ["conflicts"],
"additionalProperties": False,
},
"strict": True,
}
resp = client.responses.create(
model="gpt-5",
reasoning={"effort": "high"},
input=contracts_text + "\n\nReturn the conflict report.",
text={"format": {"type": "json_schema", **schema}},
)strict: True guarantees the model returns exactly that shape, which matters most when the output flows into downstream code.
When you build with the Agents SDK or wire up function calling, the tradeoff maps cleanly onto roles:
mini model. They do narrow, single-shot jobs.This split keeps an agent both smart and affordable: think hard about *what to do*, act cheaply on *each step*. A common anti-pattern is running the flagship at high effort for every tool call, which makes agents both slow and expensive for no accuracy gain.
Before every non-trivial task, run this:
1. Chain of dependent steps? → raise reasoning effort. Single transformation? → keep it fast.
2. High volume or needs speed? → drop to mini/nano.
3. Output feeds code or another tool? → add structured outputs.
4. Reasoning turned up? → state goal + constraints + "done," not the steps.
5. Building an agent? → reason hard to plan, act fast to execute.
reasoning.effort knob rather than a separate model.mini/nano variants are your cost lever. For high-volume or latency-sensitive work, a smaller model at the right effort beats the flagship every time.Ces actions sont compilées dans le plan d'action du rôle.
effort