Working with Opus 5 in Claude Code without burning budget

Teams upgrade the model and expect a step change. What they get is narrower than that, and knowing where the gain lands saves a lot of money.

The difference shows up on long, multi-step work where an early wrong turn compounds. Tracing a bug through four layers of indirection. Planning a migration where step three depends on a decision made in step one. Reading an unfamiliar service and producing a design that respects constraints nobody wrote down. On short, well-specified edits, a smaller model does the same job and returns sooner.

Our rough split after running this across a lot of teams: reach for the strongest model when planning or debugging. Drop down for mechanical edits and for anything where you already know exactly what the diff should look like.

Switch models mid-session, not per project

The habit worth building is treating model choice as a per-task decision inside one session. In Claude Code, /model changes it without losing your conversation. A workflow we see land well:

• Plan on the strong model. Ask for the approach and the files it will touch, before any code.
• Review the plan yourself. This is the highest-value 90 seconds in the whole loop.
• Drop to a faster model to execute the agreed plan.
• Go back up for the review pass, and ask specifically what it got wrong, not whether it is correct.

That last point matters. Ask a model to check its own work and it will usually agree with itself. Ask "what in this diff would a senior reviewer push back on" and you get a different, more useful answer.

Context discipline beats model choice

A stronger model on a repo with no CLAUDE.md, twelve MCP servers connected, and a 300-message session is worse than a mid-tier model on a clean setup. We have measured this in workshops with the same task and two configurations, and the clean setup wins every time.

So before you upgrade: keep the project file short and factual, prune the tools the agent can see, and start a fresh session when the topic changes. /clear costs you nothing and removes a lot of noise the model is otherwise spending attention on.

The limits, stated plainly

It still fabricates APIs it has not seen, particularly in fast-moving internal libraries. It still writes a test that asserts the behaviour it just implemented rather than the behaviour you wanted. It is confident about deprecations and version-specific behaviour in ways that do not always survive contact with your lockfile. None of that goes away with a bigger model, and treating the model as an oracle is how teams end up with quietly wrong code that passes CI.

What to do this week

Take one ticket that previously went badly with an agent. Run it twice: once on your default model with your current setup, once on the strongest model after trimming the project file and clearing the session. Time both, and count the review comments. If the gap is small, your bottleneck is context, not capability, and that is the cheaper problem to fix.

We spend a day on exactly this with engineering teams, using their repo rather than a toy example.

If you want help putting this into practice, talk to us.