Reasoning vs Fast Models

The first time I used o3 for a coding task, I was impressed — then I checked the latency and the bill. 40 seconds and 15× the cost of Sonnet, for a task Sonnet would have nailed. That moment is what started me keeping notes on when the expensive reasoning models actually earn their cost — and when they're just burning money.

I'm Filip van Harreveld, a senior creative developer at iO. I share work and notes at filipvanharreveld.com and on LinkedIn.

Everything below is an operating heuristic from my own coding sessions, not a permanent ranking. Model behavior shifts with the version, prompt, tool harness, repository context, and how success is measured. Treat the examples as patterns to test against your work.

The current model shortlist

The tools below now include Claude Opus 5.5 and Sonnet 5.5, GPT-6.1 Sol and GPT-6 Luna, GLM-5.3, GPT-6 Astra, Claude Fable 5.1, Gemini 3.8 Flash, DeepSeek-V4.1-Flash, and Kimi K3. Their specs come from provider documentation; the new releases do not yet have local scenario results. Opus 5.5 replaces Opus 4.8 and Opus 5, which now appear only in the scenario examples where they were run. The earlier sessions described here keep the model versions used at the time.

Start with a task you can check. Compare GPT-6 Luna, Gemini 3.8 Flash, or DeepSeek for a narrow step. Try Sonnet 5.5 or GPT-6.1 Sol for everyday implementation, and Opus 5.5 before Astra or Fable 5.1 when the problem needs more sustained reasoning. GLM-5.3 and Kimi K3 are the open-weight options; GLM-5.3 takes text only. Mistral Large 4 adds a public-preview candidate for coding, document analysis, and visual workflows. Compare it on the same checks before adopting it. The release notes explain what changed and link to the sources.

Token prices alone miss two costs: how much the model generates and how many attempts it needs. The calculators use explicit token assumptions and documented long-context surcharges. They cannot predict the number of retries your task will take.

When reasoning models actually earn it

In my tests, fast models usually do well when a task follows a well-known pattern — "write a React form," "add a REST endpoint" — because there is less ambiguity to resolve. Reasoning models have earned their cost more often when the task requires weighing tradeoffs or holding multiple constraints in tension. "Design the data model for this feature given these constraints" or "find the bug in this async code that only fails under load" asks for more than reproducing a familiar pattern.

• Architecture decisions with real tradeoffs. I asked Sonnet to choose between three caching strategies for a Next.js app — it picked the most common one. o3 identified that my specific access pattern made the "common" choice wrong and explained why.
• Complex refactors with many constraints. "Refactor this without changing the public API, keeping backward compatibility, and not touching the test files" — the more constraints you stack, the more reasoning models pull ahead.
• Debugging non-obvious failures. A flaky integration test that only broke in CI. Sonnet suggested the usual suspects — timing, environment variables, missing mocks. Opus traced the actual execution path, found a shared database connection that leaked state between parallel test runs, and explained why it only surfaced in CI where tests run concurrently.

When fast models win

Fast models have often been better for my constrained tasks because they are less likely to expand the scope. In one run, I needed to convert 200 webhook payloads from one shape to another — straightforward field mapping, no ambiguity. Haiku did it in 2 seconds flat, correct on the first pass. o3 took 12 seconds per payload and added defensive null checks, fallback defaults, and logging I never asked for. Same output quality for the actual mapping in that run, 6× slower, 10× more expensive.

Reach for GPT-5.6 Luna, Haiku, or Flash when:

• Boilerplate generation. Component scaffolding, test stubs, migration files — anything where the structure is known and the model just needs to fill in the blanks.
• Structured data extraction. Pulling JSON from unstructured text, classifying support tickets, parsing log lines. Fast models follow extraction schemas reliably without "improving" them.
• Pipeline steps where latency compounds. If the model runs in a loop — processing files, transforming records, generating variants — even small per-call overhead adds up fast. A 3-second Haiku call vs. a 30-second o3 call, repeated 50 times, is the difference between 2.5 minutes and 25.

When the pipeline only needs a decision

A returns photo does not always need a written explanation. Sometimes the next step needs a probability of visible damage, a choice of queue, or a score against a rubric.

OpenAI's Decisions API takes text and inline images and returns those bounded answers. That can fit a classification or routing step before a broader agent runs. The application still handles refusals and chooses what happens next; a model's confidence needs checking against labelled examples.

The Decisions API release note includes a vision request example and endpoint-specific pricing. Keep that pricing separate from the general model-token estimates below.

The model mixer approach

I don't pick one model for a task — I use different models for different steps in the same task. Here's a real example: building a new API endpoint with auth, validation, and tests.

1. Fable 5 for the plan. I described the feature and constraints. Fable mapped out the data model, identified where the new endpoint fit in the existing auth middleware, and flagged a potential race condition with concurrent writes. Expensive, but it caught a design issue I would have hit two hours into implementation.
2. GPT-5.6 Terra for implementation. With the plan locked, Terra wrote the route handler, validation logic, and database queries. Fast, correct, no scope creep — because the architecture decisions were already made.
3. Composer 2.5 for the test suite. Gave it the implementation and said "full test coverage, including the race condition Fable flagged." It generated the tests, ran them, caught two failures from its own output, and fixed them autonomously.
4. GPT-5.6 Sol for review. Asked it to review the final diff for edge cases and security issues, run the relevant checks, and verify the result. It spotted a missing rate limit on the new endpoint and a permissive CORS header I'd copied from another route.

Total cost: a fraction of running Fable end-to-end. Each model played to its strength — deep reasoning where it mattered, balanced execution in the middle, and flagship verification at the boundary.

See it in practice

Pick a coding scenario below to inspect the existing examples and compare current model costs. Pay attention to where reasoning models spend their token budget — and whether that extra thinking actually improves the output.

Pick the right model for your task

Not sure which model fits? Describe what you're building and how complex the task is. The picker weighs tradeoffs you might not think about — latency sensitivity, number of constraints, whether the task needs creativity or compliance.

What does it actually cost?

The price gap between model tiers is real, but it's not as simple as "expensive = better." Run your own numbers below — adjust task count, model choice, and context size to see how costs shift across a realistic workload.