# Model and reasoning choice

Learn why the most capable model with high reasoning is the priciest way to work, and how to match capability to the risk and difficulty of each task.

> Model and reasoning choice means picking how capable a model to use, and how much it thinks before answering, per task. Capability and reasoning both raise the price of output, so spend them where the work is hard or risky.

Source: https://ai-sw-factory.mellicci.dev/cost/model-and-reasoning-choice

**Diagram:** Match capability and reasoning to the risk of the work; a rename needs little of either, a schema migration design needs both.

- Model capability (smaller → most capable)
  - Rename and reformat: a smaller model is enough
  - Design a schema migration: keep the capable model
- Reasoning effort (low → high)
  - Rename and reformat: little thinking needed
  - Design a schema migration: thinking pays off
- Risk of the work (low → high)
  - Rename and reformat: tests catch mistakes
  - Design a schema migration: mistakes reach production

Models differ in capability and in price. The most capable ones usually charge the highest rate per token, on input and on output. Reasoning adds to this: before it answers, the model can generate thinking tokens, usually billed as output too.

So there are two dials, model and reasoning effort, and each raises the cost of every reply. The question is not which setting is best, but which setting this task needs.

## Why it matters

Output is the priciest token in the system (see [Why tokens cost differently](https://ai-sw-factory.mellicci.dev/cost/why-tokens-cost-differently)). A premium rate on the priciest token is fine when the task needs it. On a rename it is a cost you pay hundreds of times for no benefit.

Habit makes it worse. If the session starts on the most capable model with high reasoning, every routine edit inherits that setting unless you change it.

More is not always better, either. On mechanical work, heavy reasoning can make a model overthink: it may add changes nobody asked for, which you then review and revert. This happens sometimes, not always, but it means the expensive setting can lower quality as well as raise the bill.

## How it works

Cost per task grows with the rate of the model and with the tokens it generates. Risk decides how much of that is worth paying for.

| Task | Difficulty | Risk if wrong | Reasonable starting point |
|---|---|---|---|
| Rename, reformat, update snapshots | Low | Low, tests catch it | Smaller model, low reasoning |
| Reading logs, reviewing a diff | Medium, narrow | Medium | Smaller model as a subagent |
| Design a schema migration | High | High, hard to undo | Most capable model, higher reasoning |
| Debug a failure nobody understands | High | Medium | Capable model, raise effort if it stalls |

A narrow role does not need the planner's model. A reviewer or log reader can run as a [subagent](https://ai-sw-factory.mellicci.dev/fundamentals/subagents) on a smaller model, while the hard planning stays on the capable one. The subagent also keeps its long reads out of the main context.

## Example

The `ticket-service` team ran everything on the most capable model with high reasoning: renames, formatting and test-snapshot updates, as well as design work. Spend doubled last month. Most of the volume was mechanical work that tests verify anyway.

The team moved mechanical work to a smaller model with low reasoning and kept the capable model for the migration design. Tests check every mechanical change.

| Typical day, illustrative relative units | Before | After |
|---|---|---|
| Mechanical tasks (renames, formatting, snapshots) | 60 | 12 |
| Migration design | 30 | 30 |
| Review and log reading | 20 | 8 |
| Reverted or redone changes | 10 | 4 |
| **Total** | **120** | **54** |

The design work costs the same, because it needs the capability. The saving comes from the routine tasks, and the tests keep the cheaper setting honest.

## What helps, what hurts

Helps:

- Choose the model per task, not per habit. Output is the priciest token, so the highest rate hurts most on output-heavy work.
- Lower reasoning effort for mechanical work, where thinking tokens add cost but little value.
- Run narrow roles such as reviewers and log readers as [subagents](https://ai-sw-factory.mellicci.dev/fundamentals/subagents) on a smaller model.
- Raise capability or effort when a task stalls, rather than starting there.
- Keep tests and checks in place, so a cheaper setting fails visibly.

Hurts:

- Leaving the session on the top setting for everything.
- Using the smallest model on risky, ambiguous work to save tokens.
- Switching models by feel, with no way to see what changed. See [Measuring cost](https://ai-sw-factory.mellicci.dev/cost/measuring-cost).
- Ignoring that a long session re-reads its context on every call ([Context growth](https://ai-sw-factory.mellicci.dev/cost/context-growth)); a premium rate applies to all of it.

## Trade-offs

- A smaller model can be less reliable on hard problems. If it fails, the rework can cost more than you saved.
- Low reasoning can miss edge cases on work that looked mechanical but was not.
- Splitting work across models adds a decision for you, and handoffs between agents can lose detail.
- Over-reasoning can lower quality, but a capable model on high effort is still the right choice for risky, irreversible decisions.

## Related

- [Why tokens cost differently](https://ai-sw-factory.mellicci.dev/cost/why-tokens-cost-differently): why output is the priciest token
- [Context growth](https://ai-sw-factory.mellicci.dev/cost/context-growth): why long sessions cost more per reply
- [Measuring cost](https://ai-sw-factory.mellicci.dev/cost/measuring-cost): checking that a change helped
- [Subagents](https://ai-sw-factory.mellicci.dev/fundamentals/subagents): a narrow role on its own model

## Key terms

- **Model capability** - How well a model handles hard, ambiguous or risky work. The most capable models usually charge the highest rate per token.
- **Reasoning effort** - How much the model thinks before it answers. Higher effort generates more tokens first, usually billed as output.
- **Thinking tokens** - Tokens the model generates while reasoning, before the visible answer. They are usually billed as output.
- **Mechanical work** - Low-risk, well-defined changes such as renames, formatting and snapshot updates, where tests can confirm the result.
- **Rework** - Effort spent redoing or fixing a result that was wrong, which can cost more than the saving from a cheaper model.