Switch models with /model to match the task

The first job of the day is the smallest one you’ll do all week: a charge-failure error message reads like a stack trace to the customer, and someone wants it rewritten to plain English. That’s one string in one file. There is no architecture here, nothing to reason about, no design fork — and running your most capable model at full reasoning to rephrase a sentence is paying for a brain you don’t need. The right move is to drop a gear before you even start, and the command for that is /model.

Two ways to switch

/model controls which model answers you. Two forms, depending on whether you already know what you want:

/model                 # open the picker — arrow through the options, see what each is for
/model <name>          # switch straight to a known tier, no picker

Run /model with no argument and you get a picker listing the tiers available to you — from your most capable model down to lighter, faster ones — and you arrow to the one that fits. Type a tier name after /model and it switches immediately, skipping the menu. Either way the change is live for your next prompt; the status area shows which model is currently active so you can confirm at a glance. The exact tiers and their names live in the model-config docs and shift as new models ship, so read the picker rather than memorising a name.

For the copy tweak, drop to a lighter, faster model and let it do the mechanical thing:

> /model
  ◇ pick a model
    › most capable    — hard reasoning, complex changes
      balanced        — daily coding
    ▸ fast & light    — simple, mechanical tasks      ← this one

> rewrite the charge-failure error message in src/routes/charges.js
  to read as plain customer-facing English. don't change the status code.

  ⏵ Edit src/routes/charges.js   ✓ applied
  Done. "ERR_CHARGE_DECLINED: gateway 402" → "We couldn't complete this
  payment. Your card wasn't charged — please try a different card."

Same edit you’d have gotten from the heavy model, a fraction of the cost and latency, and nothing lost — because there was nothing here that needed the bigger brain.

Session switch, or new default

When you switch in the picker, Claude Code asks a question worth understanding: do you want this model just for now, or as your default for new sessions too?

  ◇ fast & light selected
    › Enter — switch and make this my default for new sessions
      s     — switch for this session only

Enter saves the choice as your default, so every new session starts here. s switches for the current session only and leaves your default untouched. Typing /model <name> directly behaves like Enter. For a one-off copy tweak inside a session that’s mostly heavier work, you want session-only — drop to light for this task, and don’t let it bleed into how tomorrow’s session starts. The picker’s exact keys are documented in model-config; check there if the prompt looks different from this.

One thing the picker warns you about, and it’s the small tax on switching: changing model mid-conversation means the next response re-reads the whole thread without the cached context it had built up under the old model. On a short session that’s nothing. On a long, heavy one it’s a real re-read cost — a reason to pick your gear early rather than flip back and forth every few prompts.

When the heavier model earns it

So if light is cheaper and faster, why ever run the capable one? Because the copy tweak is the easy half of the day. The trade is always the same shape:

• Mechanical, scoped, one obvious answer — a rename, a copy edit, a format change, boilerplate you could describe in a sentence. A lighter model does it well and you keep the cost down. This is most of the day.
• Ambiguous, cross-cutting, more than one reasonable approach — the kind of problem where a wrong guess costs you an hour of unpicking. Here the capable model’s deeper reasoning isn’t a luxury; it’s the thing that stops the agent confidently building the wrong design. The cost is real but the re-work it prevents is more expensive.

The test is the one you already used for plan mode: would you hand this to a junior without a second thought, or would you want your sharpest engineer on it? Junior-obvious work gets the light model. The problems that need your sharpest engineer get the capable one — and you’re about to meet exactly that kind of problem.

Because the copy tweak is shipped, and the next item in the queue is the concurrency bug in the charge ledger. That one is not a string edit. Switching up to the capable model is the right first move — but on a problem this gnarly, the model alone isn’t enough. You want it to think harder before it acts. That’s the next dial.