The OpenAI model family: GPT, reasoning models, and when to use each

Reasoning models (the "o" series, e.g. o3, o4-mini, and their successors) spend extra hidden compute working through a problem before emitting the final answer. That hidden work is called *reasoning 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 →*: internal steps you pay for and never see. They trade 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.

Each family also comes in smaller variants (the mini and nano tiers). Same general capability profile, lower cost, lower latency, slightly less depth. A mini reasoning model 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.

The routing decision in one question

Ask: does this task have a verifiable chain of steps where an early mistake breaks the outcome?

• No → general GPT model. Rewrites, tone changes, drafting, extraction, summarization, simple Q&A, casual chat.
• Yes → reasoning model. Multi-constraint analysis, math proofs, ambiguous bug hunts, multi-document synthesis with logic, planning a sequence of actions.

Then ask a second question for cost: is this high-volume or latency-sensitive? If yes, drop to a mini/nano variant in whichever family you chose.

Concrete example: rewrite vs analysis

Task A: "Rewrite this paragraph to be more concise and confident."

This is a one-shot transformation. There is no chain to get wrong. Use a general GPT model, the fast default.

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. Use a reasoning model 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 →.

Two things to notice. First, both calls use the Responses API (responses.create), OpenAI's current primary interface. Second, the reasoning call exposes a reasoning.effort knob (low / medium / high) that trades depth for cost. You will not find that parameter on a general chat model, because it has nothing to deliberate about.

In ChatGPT: the picker in plain terms

In the ChatGPT apps the dropdown usually offers a smart default plus options labeled by speed vs depth. Treat the labels as the same two questions:

• The fast/default option is your general GPT model. Use it for 80% of daily work.
• The option that mentions "thinking" or reasoning (sometimes shown as "Thinking" or an o-series name) is your reasoning model. Switch to it when a fast answer keeps coming back shallow or subtly wrong.
• Newer ChatGPT builds increasingly auto-route for you: a single model decides internally whether to think harder. When that happens, your lever is the prompt ("think carefully and check each step") rather than the dropdown.

A practical habit: start fast, and only escalate to reasoning when you catch the fast model skipping logic. Escalating costs more and is slower, so do not make it your default.

Where this intersects ChatGPT's features

Model choice 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. A reasoning model is far better at planning a correct multi-step analysis (clean, join, aggregate, validate) before writing the code. A general model is fine for "make a quick bar chart."

Canvas. For long-form writing and code you edit side by side, a general model keeps the loop fast. Switch to reasoning only when the *content itself* requires hard logic, like deriving an algorithm.

Custom GPTs and Projects. Your custom instructions and memory shape behavior across both families, but a reasoning model will actually follow multi-part instructions more reliably because it can plan around them. If your Custom GPT keeps ignoring constraint #4 of 6, the model tier may be the bottleneck.

The ChatGPT agent and scheduled tasks. Autonomous, multi-step work (browse, click, synthesize) leans on reasoning-class models by design, because each step depends on the last.

Cost and latency: the real tradeoff

The pricing details change, so reason qualitatively (the live numbers are on the pricing page):

• Reasoning models cost more per task than their tokentokenA 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 → rate suggests, because they generate invisible reasoning 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 → on top of the visible answer. A "cheap" reasoning model on a hard problem can cost more than a "pricey" general model on an easy one.
• 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 a flagship.
• Latency tracks the same axis. Reasoning models feel slow because they are thinking. That is the point, not a bug. Do not put one behind a UI that needs sub-second responses unless you cap effort at low.

A simple internal rule for teams: default to a fast general model, allow reasoning models on an explicit allowlist of task types, and reserve flagship reasoning for low-volume, high-stakes work.

Reasoning models change how you prompt

Once you pick a reasoning model, 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 general models you often add "think step by step." Reasoning models already do this internally; spelling out the steps can actually constrain them. Instead, state the goal, the constraints, and the success criteria, then get out of the way.

Weak prompt for a reasoning model:

> 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. Reasoning models reward a crisp definition of "done" and explicit instructions about uncertainty ("flag, don't guess"). They are also better at honoring structured outputs, so pair them 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="o4-mini",
    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 a reasoning model's output flows into downstream code.

Reasoning models inside agents

When you build with the Agents SDK or wire up function calling, model choice maps cleanly onto roles:

• The planner (decides which tools to call and in what order) benefits from a reasoning model. Tool selection is exactly the kind of multi-step decision they excel at.
• The workers (a tool that summarizes a fetched page, formats a result, drafts a reply) can be fast general models. 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 a flagship reasoning model for every tool call, which makes agents both slow and expensive for no accuracy gain.

A quick mental checklist

Before every non-trivial task, run this:

1. Chain of dependent steps? → reasoning. Single transformation? → general.

2. High volume or needs speed? → drop to mini/nano.

3. Output feeds code or another tool? → add structured outputs.

4. Using a reasoning model? → state goal + constraints + "done," not the steps.

5. Building an agent? → reasoning to plan, fast models to execute.

Key Takeaways

• Route by structure, not by hype. If a task is a single transformation, use a fast general GPT model. If it's a chain of dependent steps where one mistake breaks the result, use a reasoning model.
• `mini`/`nano` variants are your cost lever. For high-volume or latency-sensitive work, a smaller model in the *right family* beats a flagship in the wrong one.
• Reasoning models cost more per task than their token rate implies because of invisible reasoning 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 →. Default to fast, escalate deliberately, and cap effort when latency matters.
• Prompt reasoning models differently: give goal, constraints, and a definition of "done," and tell them to flag uncertainty instead of guessing. Skip the manual "step by step."
• In agents, split roles: reasoning model to plan, fast general models for individual tool calls. Pair reasoning output with structured outputs whenever it flows into other code.