One Claude Code Tip a Day: Choose /model for the Job, Not the Hype

This post is part of the “One Claude Code Tip a Day” series — a daily guide to using Claude Code more effectively.

The failure: treating model choice like a prestige setting

A real Claude Code session often fails before the first patch because the model choice was made on autopilot. You start with the biggest model for a typo fix, burn time and budget on obvious file inspection, then get impatient and accept a broad diff. Or you stay on a cheaper, faster model for a risky migration because it answered confidently enough. In both cases, the mistake is the same: model choice became a vibe instead of a workflow decision.

Today's tip is to use `/model` deliberately. The command is not just a settings screen. It is a checkpoint where you ask, `What kind of reasoning does this task need, what proof will catch mistakes, and how expensive will exploration become?` The right model is the one that fits the risk and the verification loop, not the one that sounds most impressive.

Start with the task shape

Before switching models, make Claude describe the work in operational terms:

Prompt: `Classify this task before editing: is it lookup, narrow patch, unfamiliar-codebase explanation, test-driven debugging, refactor, release check, or high-risk architecture work? Then recommend whether the current model is enough or whether I should use /model to switch. Justify the choice with expected evidence and verification commands.`

Now run the command when the answer says model choice matters:

Command: `/model`

For a README correction or a one-file copy tweak, you probably want speed and discipline more than maximum reasoning. For a cross-service auth bug, a migration, a gnarly type-system refactor, or a deployment loop with partial logs, stepping up can be worth it because the model must hold more competing hypotheses and inspect more context before editing. The important part is that the switch is tied to evidence you expect the session to produce.

A realistic debugging example

Imagine a flaky Playwright failure: the checkout confirmation page sometimes shows the previous order total. A weak workflow says, `Use the best model and fix it.` That may produce a clever patch, but it does not force the session to separate browser timing, API caching, state management, and test flakiness.

A stronger prompt is:

Prompt: `Before changing code, decide whether this debugging session needs a stronger model. Build a hypothesis table with evidence needed for each theory, estimate how much repo context must be read, and tell me what verification would make the model switch worth the cost. If we switch with /model, keep the first patch under two files.`

This makes `/model` part of the debugging contract. If Claude recommends switching, it must also narrow the first move: read the cart store, inspect the confirmation route, run the failing Playwright spec, and patch only after one hypothesis beats the others. The model upgrade buys better reasoning, not permission to sprawl.

Know when not to switch

The opposite failure mode is just as common. Developers reach for a stronger model because the task feels annoying, not because it is ambiguous. If the failing unit test already points to a missing null guard, switching models may only make the session more verbose. Ask for a second-pass check instead:

Prompt: `Stay on the current model for now. Read the failing test and the target file, propose the smallest fix, and list the exact condition that would justify switching models later.`

Good switch conditions are concrete: the call graph crosses several packages, two plausible root causes survive inspection, the diff touches security-sensitive code, or the first focused test still fails for a reason not explained by the patch. Bad switch conditions sound like frustration: `this is complicated`, `try harder`, or `use more intelligence.` `/model` should be triggered by risk and uncertainty you can name.

Review the diff differently after a switch

When you do switch, change your review style. A stronger model can produce more coherent multi-file edits, which also makes overreach easier to miss. After the patch, ask:

Prompt: `Review your diff as if the model switch made you overconfident. Which changes are directly required by the failure signal, which are opportunistic cleanup, and which should be reverted or split into a later commit? Then name the proof command for each required change.`

This is especially useful during refactors. The upgraded model may correctly see a cleaner abstraction, but your job is still to ship a verified slice. Run the tests it names. Inspect `git diff`. If a browser behavior changed, verify it in the browser. If the model cannot connect a changed line to a proof command, the line probably does not belong in this pass.

Rule of thumb

Use `/model` when the task's reasoning load changes, not when your patience changes. Stay efficient for narrow edits with obvious proof. Switch up for ambiguous failures, broad context, security-sensitive changes, architecture decisions, and release work where a wrong assumption is expensive. But pair every switch with a tighter evidence contract: fewer files, named hypotheses, focused checks, and a post-diff overconfidence review. The model is part of the workflow; verification is still the boss.