When OpenAI shipped o1 in late 2024, it landed as a new category: a model that reasons before it answers. Anthropic, Google, and DeepSeek followed with their own variants. The pitch is obvious — better answers on hard problems — and the price tag is obvious too: roughly 3-6× the cost per output token of a frontier model like GPT-4o or Claude 3.5 Sonnet.
This is a practical post. It’s the framework we use internally when deciding whether a workload should pin a reasoning model, default to auto, or stay on a value-tier model forever. It is not a benchmark — benchmarks are easy to game and the field moves too fast for them to stay current. It’s the questions to ask.
What “reasoning model” means here
A reasoning model emits a chain-of-thought (CoT) trace before producing its final answer. The CoT is hidden from the API caller in OpenAI’s o1 family; DeepSeek R1 exposes it as reasoning_content. Either way, the model is spending tokens — sometimes a lot of tokens — on internal scratchpad work that the caller never sees (and never pays attention to, but does pay for).
The mechanical consequence: reasoning models emit more tokens per answer. A simple question that GPT-4o-mini answers in 50 output tokens might cost o1 500 output tokens — 450 of them chain-of-thought reasoning, 50 in the final answer. Per-token, o1 is 100× more expensive than mini ($60 / 1M vs $0.60 / 1M output). The reasoning trace stacks on top: 10× more tokens × 100× per-token = roughly 1,000× the cost for the same question. Three cents on o1; three ten-thousandths of a cent on mini.
Whether the answer is better — and how much “better” is worth — is the entire decision.
When reasoning models earn their cost
Reach for a reasoning model when all three are true:
- The problem is genuinely hard. Multi-step math, non-trivial code generation with edge cases, formal logic, complex dependency resolution. If your prompt is “summarize this support ticket,” GPT-4o-mini will do it as well as o1 for one-thousandth the cost.
- The cost of a wrong answer is high. A wrong reply suggestion is a small embarrassment. A wrong architectural recommendation in a code-review tool is a production incident. The higher the cost of being wrong, the more a reasoning model’s accuracy advantage is worth.
- Latency is acceptable. Reasoning models take seconds to tens of seconds per response. They are the wrong choice for any interactive feature where the user is waiting.
A canonical good fit: automated code review on pull requests. The PR is already asynchronous — the developer isn’t blocked on a sub-second response. A missed bug or a bad suggestion is expensive in review churn. The reasoning trace can be exposed to the developer as “why did the reviewer flag this?” which is genuinely useful. SchneeAI’s own code review integration uses reasoning-tier models for exactly this.
Another: production-incident root-cause analysis. Feed the model the alerts, logs, and recent deploys, and ask it to form hypotheses. Latency doesn’t matter; correctness does.
When reasoning models are the wrong choice
Skip them when any of these apply:
- The task is high-volume and structurally simple. Classification, routing, summarization, extraction, translation, PII detection — these are tasks where value-tier models (GPT-4o-mini, Claude 3.5 Haiku, Gemini 1.5 Flash) are within a few percentage points of frontier models, at 10-40× lower cost. The reasoning model’s CoT doesn’t help; the task isn’t hard enough to need it.
- You’re routing user-facing chat. Users will not wait 12 seconds for a reply. They will wait 600ms. Reasoning models are for background work and async features.
- Your prompt is badly specified. A reasoning model with a vague prompt produces more elaborate wrong answers, faster. Fix the prompt first, on a cheap model. Only escalate to a reasoning model once the prompt is crisp and you’re still hitting quality limits.
- You’re benchmarking on a saturated task. If your existing model already scores 95%+ on your eval set, a reasoning model won’t get you to 100%. It’ll get you to 96% for 6× the cost.
A decision flow
In practice, we route workloads like this:
- Default to
auto. SchneeAI’s Gateway routing policy resolvesautoper request based on feature tag, budget, and PII policy. For most workloads this lands on a value-tier model. That’s correct — the median task is structurally simple. - Pin a frontier model (GPT-4o / Sonnet / Gemini 1.5 Pro) when the task is moderately complex but latency-sensitive. Code completion in an IDE, reply suggestions in a support tool, RAG over a complex knowledge base.
- Pin a reasoning model when the task is hard, async, and high-cost-of-error. Code review, design analysis, root-cause investigation, formal verification.
The boundary between (2) and (3) is the interesting one. We’ve found the reliable signal is: does the task benefit from the model showing its work? If a CoT trace would be useful to a human reviewer of the output — yes. If the output is consumed by a machine (a JSON field, a classification label, a routing decision) and never read — no.
Cost modeling
Rough numbers, as of mid-2026 (see our LLM Pricing Benchmark for the current table):
| Model | Input / 1M | Output / 1M | Notes |
|---|---|---|---|
| GPT-4o-mini | $0.15 | $0.60 | Value tier; most workloads should live here |
| Claude 3.5 Haiku | $0.80 | $4.00 | Value tier, stronger than mini on nuanced tasks |
| Gemini 1.5 Flash | $0.075 | $0.30 | Cheapest option that’s still useful |
| GPT-4o | $2.50 | $10.00 | Frontier default for interactive |
| Claude 3.5 Sonnet | $3.00 | $15.00 | Frontier; stronger on code and analysis |
| Gemini 1.5 Pro | $1.25 | $5.00 | Frontier; cheapest at this tier |
| o1-mini | $1.10 | $4.40 | Reasoning; cheaper than full o1 |
| o1 | $15.00 | $60.00 | Reasoning; expensive |
| o3-mini | $1.10 | $4.40 | Reasoning; competitive with o1-mini |
| DeepSeek R1 | $0.55 | $2.19 | Reasoning; cheapest in class |
Two patterns worth internalizing:
- DeepSeek R1 is the cost breakout. At $0.55 / $2.19, it’s cheaper than frontier models while delivering reasoning-tier performance. For async reasoning workloads where you can tolerate DeepSeek’s idiosyncrasies, R1 is often the right answer.
- o1 is a premium product. At $60 / 1M output, o1 should be reserved for workloads where the reasoning quality difference between o1 and DeepSeek R1 is worth 30× the cost. That’s rare.
Reasoning content and the Vault
One operational note: the CoT trace is content. SchneeAI’s Vault treats it the same way it treats the visible prompt and response — encrypted at the application layer before it hits object storage, with its own retention. The Gateway’s PII scanner runs over reasoning_content as well, with the same 17 categories and the same policy actions as visible content.
This matters because the CoT can be verbose — easily 5-10× the visible output length — and verbose text is where PII tends to leak. A reasoning model asked to debug a customer issue may quote the customer’s email, phone, or account number into its hidden reasoning trace as part of working through the problem. If that trace is logged without PII scanning, you’ve leaked data into a place that’s harder to redact.
If you’re operating a reasoning model in production with any kind of logging, run PII scanning over the reasoning content, not just the visible output. See PII scanning in production for the design.
What we actually recommend
Most teams should start with this default policy:
- 70% of traffic → value tier (Gemini Flash / Haiku / GPT-4o-mini) via
auto - 25% of traffic → frontier tier (Sonnet / GPT-4o / Gemini Pro) for interactive features that need it
- 5% of traffic → reasoning tier (DeepSeek R1 by default, o1/o3-mini for the cases where R1 isn’t enough)
Then watch the cost dashboard, watch the eval scores, and move workloads up or down the tiers based on data — not vibes.
The Cost Calculator lets you model the trade-off for a specific prompt and token count. The LLM Pricing Benchmark is the monthly-refreshed price table. Use them.