Dial model, thinking, and speed per task to control cost

Model and effort are two dials, and they do not have to move together. Treating them as a per-task spend - rather than a session-wide default you set once and forget - is the habit this lesson builds, plus the one case where you deliberately pay more: buying speed. The running example, the payments service (the small TypeScript service this course uses as its running example), makes the range concrete: the duplicate-payment string rewrite in src/payments/processor.ts is mechanical; the allowAsync race in src/payments/rate-limiter.ts is genuinely hard. The dials should sit at opposite ends for those two tasks, and move as the work changes.

Two independent dials

It helps to see clearly that you have been turning two separate knobs:

• Model - which brain answers. Capable for hard reasoning, lighter and faster for mechanical work. Set with /model.
• Effort - how hard that brain reasons before it acts. Up for ambiguity, down for the obvious. Set with /effort (that page lists the levels; its thinking toggle is the on/off switch for extended thinking, not a third dial).

Every task lands somewhere on this grid, and the matched corner depends on the task. Here is a day with both dials live on every item - the multipliers are illustrative ratios, not prices, and the redo-tax corners assume an underpowered hard task fails twice before you escalate:

A lumpy day: four kinds of task, and two dials on each - which model answers, and how much effort it spends thinking. Everything starts where most people leave it: pinned to the expensive corner. Re-dial each task and watch what the day costs.

• copy tweaksmechanical · five today

  Fix the onboarding typo, reword two error strings, update the footer year - one obvious answer each.

  modellightcapableeffortlowhigh

  top dollar, one answer

  The most expensive corner on the board, spent on work the cheap corner ships identically. This is where a pinned dial leaks.

• pattern-following endpointsmechanical · three today

  Add list/create endpoints that mirror the handler in the next file over.

  modellightcapableeffortlowhigh

  premium for boilerplate

  Nothing about list/create forks or surprises; the expensive reasoning has nothing to grip. Reserve this corner.

• the intermittent failurehard · once, thankfully

  A test that fails one run in five, timing-dependent, with the cause three files from the symptom.

  modellightcapableeffortlowhigh

  matched - spend it here

  A genuine reasoning problem: timing-dependent, cause far from symptom, no pattern to copy. This corner exists for exactly this task.

• the design forkhard · once

  Choose how rule conflicts resolve in the categorization engine - several defensible designs, one gets built on.

  modellightcapableeffortlowhigh

  matched - the wrong call costs a rewrite

  Several reasonable designs, and whichever wins gets built on. The delta between corners here is noise next to the cost of unpicking a bad choice later.

presetspin everything expensiveroute by taskunderpower the hard task

first runs495 unitsredo tax0 unitsvs the matched day1.9×

Everything ships - no failures, no redo tax - and the day still costs 1.9× what it should. That’s the quiet leak of a pinned dial: the mechanical work bills like hard work, five and three times over. Dial it down to the cheapest corner that ships it; the hard problems keep their budget.

Numbers are illustrative - the ratios are the point (capable ≈ 5× per token, high effort ≈ 3× the tokens). The redo tax counts an underpowered task’s failed attempts plus the escalation you’d run anyway, not the hour lost to confident wrong answers.

Two leaks account for most of the waste. The expensive corner pinned by habit: the capable model at high effort grinding through renames, paying its premium per token (tokens are the units of text the provider processes and bills) for diffs the light model produces identically. And the cheap corner on a hard problem, which is worse than it looks - an underpowered run on the race flails, produces a plausible wrong fix, and you escalate to the big model anyway, paying for the attempt and the redo. Overpaying burns money linearly; underpowering burns it and leaves you where you started.

You want the corner that matches the work - cheap and shallow for the mechanical, expensive and deep for the genuinely hard - and you want to move between them as the work changes.

What the tiers cost relative to each other

Exact per-token prices and usage multipliers move, so do not budget from a fixed ratio between tiers. Use the current Claude pricing page and the usage information shown by your plan or provider:

Tier	Relative cost	Best for
Haiku or a lighter available model	Cheapest per token	Renames, formatting, simple lookups
Sonnet or a balanced available model	Middle	Multi-file features, code review
Opus or a stronger available model	Most expensive per token	Architecture, concurrency bugs, planning

The practical lesson is stable even when the numbers move: choose the least expensive model that reliably handles the task, and verify the current price before budgeting anything real.

When speed is the thing you’re buying

There is a third lever, and it is not about capability at all - it is about latency. Some sessions are interactive in a way where waiting hurts: live debugging, rapid iteration where you fire a prompt every thirty seconds and the response time is the bottleneck. For those, Claude Code has fast mode. It runs the same model at a higher cost per token in exchange for lower latency, with quality held constant:

/fast            # toggle fast mode on (or off again)
/fast on         # set it explicitly
/fast off

Before leaning on it, know its current shape - it is narrower than the effort dial, and these facts move, so treat the fast-mode reference as the source of truth:

• Model availability. Fast mode is supported on Opus 5.5, Opus 5, and Opus 4.8 only. It is not available on Sonnet, Haiku, or other models - and notice that the tier table above steers exactly the mechanical, latency-sensitive work toward those lighter models. On them, fast mode is simply not an option; the light model’s ordinary speed is what you have.
• Billing. For subscription users, fast mode draws from usage credits only - it is not included in plan rate limits, and it draws from credits even when you have remaining plan allowance. Console and API organizations pay per token with the rest of their API usage instead.
• Organization policy. Fast mode is disabled by default for Team and Enterprise organizations; an Owner has to enable it before anyone in the org can use it.

Where it is available, the judgment of when it is worth it is narrow and worth stating plainly:

• Worth it - interactive, latency-sensitive work where your waiting time is the expensive resource: rapid iteration, live debugging against a deadline.
• Usually not worth it - long autonomous runs, batch jobs, anything where nothing downstream depends on completion time. The test is not whether you are watching; it is whether anyone or anything waits on the answer. A nightly summary with no deadline buys nothing from the premium; the same summary gating a morning deployment has elapsed time worth pricing against the charge.

Two mechanics from the docs worth carrying. Enabling fast mode mid-conversation re-prices the whole context (the conversation and instructions the model can currently draw on) - the first fast-mode request pays the uncached input price for the entire conversation. Cached input normally bills at a lower rate when the provider can reuse its prior processing; this one-time charge is the existing context billed at the full rate instead, once per conversation, so toggling fast mode off and on again does not repeat it. That re-price is one bounded cost that grows with the context you have already built: negligible on a fresh conversation, a real line item on a long one. So when you know from the start a session will be interactive, turning fast mode on early avoids it. And fast mode stacks with the effort dial; the docs’ own phrasing is “use fast mode with a lower effort level for maximum speed on straightforward tasks”.

The discipline, stated once

Strip away the commands and this chapter is one move in the course’s cost vocabulary: what a task consumes is a decision you make, not a constant. The agent’s context - the information it can draw on for a response: instructions, files, tool results, the conversation itself - is finite, and its capacity is the context window. Sessions & context teaches governing that window the same way: watch it, fill it with signal, reclaim it before it bloats. Model and effort are the same instinct aimed at the agent’s reasoning: spend the capable model and deep reasoning where the problem is genuinely hard, like a race that punishes pattern-matching, and pull both down the moment the work goes mechanical.

Do that by reflex and a mixed day costs what it should: the light model’s rate on the string edit, real budget on the race, and nothing spent powering work that never needed it.

Run it on tomorrow’s queue

The discipline is only real if you can run it cold. Here is a four-ticket queue on the payments service (the first two reuse this chapter’s examples) - for each, pick the model, the effort, and whether fast mode earns its premium, before reading the verdicts:

1. Reword the "duplicate payment" error to name the idempotency key.
2. Design the fix for the allowAsync race, where a confident wrong patch costs an hour of unpicking.
3. The nightly CI job that runs the suite and posts a failure summary - nobody watches it run, and nothing depends on receiving the summary sooner.
4. Rapid iteration on a flaky test, you firing a prompt every thirty seconds against a deadline.

The verdicts. The error reword is mechanical: light model, low effort, no premium worth paying on a one-shot edit. The race is the chapter’s argument in one ticket - capable model, effort up, because the reasoning is what separates the real interleaving that causes the race from a plausible wrong patch.

The CI job is work you walk away from, and with no deadline waiting on its summary, fast mode buys nothing anyone needs sooner; the model need only be capable enough to summarize honestly.

The flaky-test sprint is the one ticket where your waiting is the expensive resource, and the verdict depends on what the debugging actually needs. If each retry is a trivial edit and only the latency hurts, stay on the light model and take its ordinary speed: paying the Opus rate plus the fast-mode premium to shave seconds off trivial edits is the overpaying leak in a new coat. If the flakiness needs real diagnosis, take Opus with fast mode on and the effort the diagnosis needs - the reasoning is the work, your waiting is the expensive resource, and that is exactly the combination fast mode exists for.

When one agent is not enough

Everything so far has been one agent - one model, one reasoning budget, working a task in front of you. That base case has a ceiling. When a job splits into parts that can run separately, or when one noisy step such as reading a giant log or churning through a test suite would flood the context window with output the main conversation does not need, the next move is not a bigger gear on a single agent.

It is more agents: pushing the noisy work into an isolated context of its own, and fanning a separable problem across parallel workers that each carry their own window and report back a summary. Delegation has its own bill - extra usage, and coordination you must review - so it earns its place when the work genuinely separates or the noise genuinely drowns, not merely because a task is large.

That is the whole idea of Subagents, and it is where the course goes next.