Reasoning effort sets the budget for thinking tokens: private scratch work the model generates before it writes the answer you see. Each extra token makes another trip through the same model. The weights and knowledge stay the same.
More effort helps when a task has dependent steps, such as tracing a race condition or planning a migration. It adds little to a rename or a formatting change. Token cost and waiting time keep rising even after answer quality stops improving.
Find the useful stopping point
The curve below shows the idea. Quality rises while the model has useful steps left, then levels off. The point where it levels off moves with the task.
Stop when the quality line barely moves. Switch tasks and see how the stopping point changes.
The three task shapes lead to three different choices:
- Mechanical work flattens early. Renames, formatting, and boilerplate usually need little scratch work.
- Ordinary features need a middle budget. The model has time to plan the change and check the interfaces it touches.
- Hard bugs keep paying longer. A concurrency bug or security review can require a long chain of checks.
Effort cannot supply missing facts. If the model does not know your internal framework, add context or choose a different model. Raise effort when the model knows the pieces but skips steps between them.
Picking a level
Estimate the number of dependent steps and the cost of a wrong answer after tests and review. Short, easy-to-check tasks go low. Long chains or expensive mistakes go high. Use the middle for normal work.
| Level | Reach for it when | Examples |
|---|---|---|
| low | the task is mechanical, reversible, and tooling checks its output anyway | renames, formatting, boilerplate, config edits, summarizing a diff |
| medium | ordinary engineering work with a few interacting parts; the daily default | a scoped feature, a straightforward bug, test writing, code review of a small change |
| high | the answer sits behind several dependent deductions, or spans systems | debugging heisenbugs, API design, performance work, security review |
| max | one shot at a correctness-critical answer, and verification is expensive | migration plans, concurrency invariants, incident root-cause under pressure |
Use the result to tune the next run. Repeated ideas suggest too much budget. A fast answer with an unchecked assumption suggests too little.
Effort and model choice solve different problems
Effort gives the same model more steps. A stronger model brings better judgment to every step. A smaller model can spend a large budget exploring a bad path; a stronger model can still miss an interaction if it answers too quickly.
There is also a third option. When answers are cheap to check, several low-effort attempts plus a verifier can beat one long attempt. That moves the spending across model runs, which is where orchestration begins.
Defaults that hold up
- Start at medium and move only when the task gives you a reason.
- Use less effort when tests can catch mistakes quickly.
- If high effort still misses, add context or change models.
- Effort buys more thinking tokens, not new knowledge.
- Quality can flatten while cost and waiting time keep rising.
- The best level depends on task depth and the cost of a mistake.