For most of the LLM era, scaling meant one thing: bigger models trained on more data. A newer axis has reshaped the frontier — test-time compute, the idea that you can make a model better at hard problems not by enlarging it, but by letting it think longer when it answers. The models built around this are often called reasoning models or thinking models, and understanding them is key to using them well.

What they do differently

A standard LLM reads your prompt and starts emitting the answer immediately. A reasoning model first generates a long internal chain of intermediate steps — exploring approaches, checking its own work, backtracking from dead ends — and only then produces the final answer. That intermediate reasoning may be hidden from you or partly shown, but either way the model is spending substantial extra compute before committing to a response.

This works because many hard problems can't be solved in a single forward pass. Competition maths, intricate logic, careful multi-step planning, subtle debugging — these benefit enormously from the model being able to work through the problem, catch its own mistakes, and try again, rather than blurting the first thing.

Why it's a genuine shift

The striking finding is that you can trade compute for accuracy at inference time. On a hard problem, letting the model generate more reasoning — thinking longer, or sampling several attempts and picking the best — measurably improves the chance of a correct answer. That's a different lever from training a bigger model. It means a fixed model can be made smarter on demand, per-problem, by spending more at answer time.

For classes of problem that were previously out of reach — ones requiring sustained, verifiable, multi-step reasoning — this has pushed performance up sharply. It's one of the most significant capability advances since instruction tuning.

The cost is real

Thinking isn't free. A reasoning model on a hard problem may generate many times more tokens internally than the final answer contains, and it takes proportionally longer to respond. That means:

• Higher latency — seconds, sometimes much more, where a standard model replies near-instantly.
• Higher cost — you pay for all those reasoning tokens, even the ones you never see.

For a genuinely hard problem where correctness matters, that's an excellent trade. For "summarise this email" or "classify this ticket," it's pure waste — you pay more and wait longer for no improvement, because the task never needed deliberation.

When to reach for one

Use a reasoning model when the task has these properties:

• Multi-step — the answer requires chaining several inferences, not recalling a fact.
• Verifiable or high-stakes — getting it right is worth extra time and cost.
• Error-prone for standard models — you've seen a fast model get it confidently wrong.

Good candidates: hard maths and logic, complex code debugging, intricate planning, careful analysis with many constraints.

Stick with a fast standard model when the task is:

• Single-step or retrieval-like — summarisation, extraction, classification, simple Q&A.
• Latency-sensitive — anything interactive where a multi-second pause is unacceptable.
• High-volume and easy — where the per-call cost premium adds up fast for no gain.

The architecture lesson

The practical takeaway mirrors the broader model-routing theme: don't use one model for everything. Route easy, fast traffic to a standard model and reserve the thinking model for the genuinely hard requests where its deliberation earns its cost. Some systems even let the model itself decide how long to think based on the difficulty it detects — spending little on easy questions and ramping up on hard ones.

Reasoning models didn't make standard models obsolete. They added a dial — how hard should the model think about this? — and learning when to turn it up is now part of building well with LLMs.