Skip to content

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.

/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 to inspect the models available to your account, or pass an alias/full model name to switch immediately. 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 aliases, providers, and context-window options live in the model-config docs and change as new models ship, so prefer the live picker over memorizing IDs.

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.

Work
Scope
useclaude-opus-4-7
/model
  • whyReasoning depth is the bottleneck here. The flagship’s per-token premium is cheaper than the hours you’d spend untangling a design the light model tied in knots.
  • modelThe reasoning ceiling of the lineup, with a 1M-token context window.
  • howLists the available models; the pick applies to the rest of the conversation.
  • rosterAnthropic models only. Changing vendors means changing tools - the vendor-risk trade the multi-provider tools soften.

Switching with /model changes the active model for the current session. To make a model the default for new sessions, configure the model setting or the documented environment/configuration mechanism.

For a one-off copy tweak inside a session that’s mostly heavier work, use /model <alias> and leave the default unchanged. If you want the choice to persist, set the documented model configuration deliberately. The picker UI and exact controls can change; use model-config as the source of truth.

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.

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.