Modelso3-mini-high Explained: A Model Name That Is Really a Setting
o3-mini-high is o3-mini with reasoning effort pinned to high. What that changes in cost and failure modes, how to measure whether high effort helps, and its shutdown date.
People search for o3-mini-high as if it were a separate model with its own weights and benchmark table. It is not. OpenRouter's own description is that openai/o3-mini-high is the same model as o3-mini with reasoning_effort set to high. OpenAI never published a separate API model ID for it.
That distinction is worth getting right, because it changes how you think about cost, latency and failure. You are not choosing a smarter model. You are choosing to let the same model spend more hidden tokens before it answers. It also means the deadline is shared: OpenAI shuts down o3-mini in the API on 23 October 2026, and o3-mini-high goes with it.
Where the name came from
The name started in ChatGPT. When o3-mini launched on 31 January 2025, free users got it at medium effort and paid subscribers got an extra picker entry, o3-mini-high, that ran the same model at high effort. The model was identical; only the amount of thinking per answer differed.
Aggregators then exposed the ChatGPT naming as a slug, so that clients without a reasoning-effort control could still request high effort. OpenRouter's catalogue lists it with the same 200K context, 100K maximum output and $1.10 input / $4.40 output per million tokens as plain o3-mini at the time of writing. The per-token price is identical. The bill is not.
Where the extra cost actually comes from
Reasoning models generate tokens you never see. OpenAI's reasoning guide is explicit that these reasoning tokens count against the context window and are billed as output tokens. Raising effort to high tells the model to produce more of them.
So the cost of o3-mini-high is not visible in a price table. Two requests with the same prompt and the same 400-token answer can differ several-fold in billed output depending on effort. The only way to know your multiplier is to measure it: read reasoning_tokens from the usage details on each response and compare medium against high on the same inputs.
Latency moves the same way. More reasoning tokens means more time before the first visible token, which matters far more in an interactive tool than in a background job. For the general shape of this trade, reasoning models explained covers why thinking longer helps on some problems and only adds cost on others.
The truncation trap at high effort
The failure mode that catches people is the output cap. On Chat Completions, o-series models take max_completion_tokens, and that limit covers reasoning tokens and visible output together. Set it too low at high effort and the model can spend the whole budget thinking.
OpenAI's guide warns that this can happen before any visible output is produced, which means you pay for the reasoning and get no answer. Its recommendation is to reserve at least 25,000 tokens for reasoning and output when you start experimenting, then tune down once you know what your prompts consume.
If you are migrating code that was written for a non-reasoning model with a tight max_tokens of 1,000 or so, this is the first thing to fix. A small limit that was fine at medium effort can start producing empty responses at high.
When high effort earned its keep
High effort pays off when the task has a checkable answer and several dependent steps: a maths problem, an algorithmic bug, a tricky SQL query, a proof-like argument about code behaviour. These are the cases where an extra pass of reasoning catches a wrong intermediate step.
It earns little on tasks that are mostly recall or formatting: summarising, rewriting, extracting fields, classifying short text. There the model already knows the answer and more thinking just costs money. A sensible rule is to default to medium and escalate to high only for request types where you have measured a better pass rate.
How to test effort on your own work
Do not decide this on intuition. A minimal experiment:
- Pick twenty real requests with answers you can grade automatically, such as unit tests or exact-match fields.
- Run each at medium and at high effort, three times each, to see variance.
- Record pass rate, total output tokens including reasoning, and time to first token.
- Compute cost per correct answer, not cost per request.
If high effort lifts the pass rate on a category of request, route only that category to it. Model routing covers the pattern, and it works just as well for effort levels as for different models.
After 23 October
The same experiment is how you choose the replacement's effort setting. OpenAI's recommended successor for o3-mini is gpt-5.6-sol, and newer models support a wider range of effort values with their own defaults, so do not assume that what was high on o3-mini maps to high on the new model. The o3-mini guide has a short migration checklist for the base model.
Common questions
Is o3-mini-high a different model from o3-mini?
No. It is o3-mini with reasoning effort set to high. The name came from the ChatGPT model picker, and aggregators such as OpenRouter expose it as a separate slug for clients that cannot set the effort parameter themselves.
Why does o3-mini-high cost more if the price per token is the same?
High effort makes the model generate more hidden reasoning tokens, and those are billed as output tokens. The rate is unchanged but the number of billed output tokens per request goes up, sometimes by a large multiple.
Why am I getting empty responses from o3-mini-high?
Usually the output limit is too low. The max_completion_tokens cap covers reasoning and visible output together, so at high effort the model can exhaust it before writing an answer. OpenAI suggests reserving at least 25,000 tokens while you experiment.
