Language: English · 繁體中文 · 简体中文
This file deliberately contains no model names, no effort-level names, no quota numbers, and no prices.
Everything volatile lives in findings-2026-09-07.md, which is a dated snapshot.
If the mapping in that file has gone stale, this file should still be usable.
Instead of product names, this file uses three capability tiers and a reasoning budget:
| Term | Meaning |
|---|---|
| Frontier model | The most capable, most expensive option. Best at long autonomous runs and at knowing what it does not know. |
| Workhorse model | The everyday default. Strong enough for most work, meaningfully cheaper. |
| Light model | Fast and cheap. Good for work with a well-defined input and output. |
| Reasoning budget | How much thinking the model is allowed to spend per turn (Claude Code calls this effort). Usually 4–5 discrete levels from minimal to maximum. |
Map these onto today's products using the snapshot file.
Choosing a model is not "pick the best one you can afford." It is a trade between two kinds of cost:
- Unit cost — what one turn costs you in money or quota.
- Steering cost — how much of your attention it takes to get a correct result.
A cheaper model that needs three corrections can cost more than an expensive one that needs none — in quota, in wall-clock, and in your attention. The reverse is also true: a frontier model on a rename is pure waste.
The question is never "which model is best." It is "which model has the lowest total cost for this shape of task."
This is the most common mistake. People reach for the strongest configuration on important tasks. But importance is not the variable that matters; shape is.
A one-line fix to production billing code is important and still a one-line fix.
| Task shape | Model tier | Reasoning budget | Plan first? |
|---|---|---|---|
| You can describe the diff in one sentence (rename, typo, add a log line, formatting, boilerplate, simple CRUD) | Light / workhorse | Low–medium | No |
| Normal feature work in a codebase you know | Workhorse | Default | Only if it touches 3+ files |
| Touches 3+ files, or schema / data-model change, or security-relevant, or you don't know this codebase | Workhorse | Default–high | Yes |
| Long autonomous run you will not be watching | Frontier or workhorse | High–very high | Yes, and save the plan to a file |
| Subtle concurrency bug, architecture trade-off, security review, second failed fix attempt | Workhorse or frontier | Maximum (temporarily) | Yes |
| Bulk reading, searching, running tests, mechanical edits | Light, in a subagent | Low | No |
If you can describe the resulting diff in one sentence, skip planning and use a cheap configuration.
This single heuristic prevents most overspending. It is also the most widely agreed-on rule across every source surveyed.
When output is wrong, there are three different fixes and they are not interchangeable. Escalating the wrong dimension wastes money and does not fix the problem.
Output is wrong
│
├─ Did it miss a file, skip the tests, or fail to double-check?
│ → It didn't think enough. RAISE THE REASONING BUDGET.
│
├─ Did it have everything it needed, visibly try hard, and still get it wrong?
│ → It isn't smart enough for this. USE A STRONGER MODEL.
│
└─ Have you corrected the same thing more than twice?
→ The context is poisoned by failed attempts.
START A NEW SESSION with a better prompt. Do not escalate.
The third branch is the one people skip, and it is the one that matters most. Better context beats a higher reasoning budget almost every time.
If you find yourself routinely needing the maximum budget, the problem is upstream: dirty context, a task that was never scoped, or an unclear prompt. Fix that instead of paying more.
When you need to cut cost, there is a cheapest-first order:
- Lower the reasoning budget. Largest saving, smallest quality loss on ordinary work.
- Step down one model tier.
- Move bulk work into subagents running a cheaper tier.
- Shorten the context. Long contexts cost on every single turn.
Doing this in the reverse order — switching to a weak model while keeping a huge context and maximum budget — gives you the worst of both.
A model reviewing code it just wrote will forgive itself. This is not a capability problem and a stronger model does not fix it.
- Separate maker from checker. The checker must not have written the code.
- A fresh session reviewing a diff outperforms the same model reviewing its own work in the session that produced it.
- Switching to a different model on review is a bonus, not the main effect. The main effect is the clean context.
- Where a second model genuinely helps: confidently wrong answers. When a model is wrong in a plausible, self-consistent way, asking it to check itself produces more plausible, self-consistent wrongness. A different model has different blind spots.
Trigger points for a second opinion: architecture decisions, root-cause analysis after two failed fixes, security-relevant code, and anything hard to reverse.
Iterating on a plan is cheap. Iterating on a half-written implementation is expensive and leaves debris — stray comments, abandoned branches, half-migrated call sites.
- Decide the approach before any file is touched.
- Write the plan to a file, then start a fresh session to execute it. The plan survives context loss; the conversation does not.
- For long plans this is not optional. A plan held only in conversation will be damaged by summarization halfway through execution.
Known disagreement: as models improve, some experienced users have dropped formal planning for everyday work and rely on the model to explore first. The snapshot file records both positions. The conservative reading — plan when the work is multi-file, unfamiliar, or hard to reverse; skip it otherwise — is still safe.
Conversation history is a bad carrier for project state. It is lossy when summarized, it is expensive to carry, and it degrades.
- New task → new session. Not a summary of the old one.
- Same task, long session → summarize deliberately, while the session is still healthy. A model that has already lost the thread cannot write a good summary of it. Do not wait for an automatic trigger; by then it is summarizing under duress.
- Keep durable state in files — a progress file, a decision log, a checklist — and have each new session read them.
- Before you walk away from the keyboard, summarize. Cached context expires; an idle session goes stale at full price.
Watch for behaviour, not percentages:
- It asks for information you already gave it.
- It writes code that contradicts a decision made earlier in the session.
- It builds on top of an error instead of flagging it.
- It reverts its own change twice.
Any of these → start a new session. Published numeric thresholds vary wildly between people and workflows; the behavioural signals do not.
The reason to use a subagent is not parallelism and not specialization. It is to keep a large volume of intermediate output out of your main context.
- Delegate reading, searching, and running things. Keep judgment, synthesis, and decisions in the main loop.
- Cheap tier collects, expensive tier decides.
- Constrain what comes back. An unconstrained subagent returns a wall of text and you have paid for the isolation without getting it. Ask for a specific, bounded format.
- Few, not many. A handful of well-scoped subagents beats a dozen overlapping ones.
- Subagents are not free: they start cold and must gather their own context. When latency matters or the task is small, do it inline.
- Check what tier your subagents actually inherit. In several tools the default is to inherit the parent's model, so a fan-out silently runs everything at the most expensive tier. This is the single fastest way to burn a quota window.
Changing the model or the reasoning budget mid-session invalidates cached context, so you re-pay for everything already in the conversation. Any always-on "fast" or premium mode has the same property — enabling it late re-prices the whole session.
Pick your configuration when you open the session, not when you get frustrated.
The maximum reasoning budget has a real use: subtle concurrency bugs, security review, architecture trade-offs, and the root-cause analysis after two failed fixes.
It also has two well-documented failure modes:
- It overthinks. On structured output and on writing tasks, maximum budget can produce worse results than the default.
- People forget to lower it. The recurring war story is not a bad result; it is a trivial task that silently ran at many times its normal cost for the rest of the day.
If your tool scopes the maximum level to the current session only, that is a feature. Use it, then let it expire.
Ranked by how much they help per unit of effort:
- Give it better context — the right files, the constraint you forgot to state, an example of the pattern you want.
- Scope the task down until you can describe the outcome in one sentence.
- Start a clean session and rewrite the prompt using what you learned.
- Raise the reasoning budget.
- Change model tier.
Most people try 4 and 5 first. They are the last two for a reason.
The snapshot in this repository is dated and not maintained. When it no longer matches reality:
- Keep this file. The principles above have survived several model generations.
- Rebuild only the mapping — which product is the frontier / workhorse / light tier today, what the budget levels are called, and what your plan's quota rules are.
- Check your vendor's own documentation for the current numbers. Do not trust the snapshot, and do not trust blog posts that quote it.