Claude Opus 5 became generally available on 24 July 2026, and the headline capability numbers matter less to a working engineering team than two structural changes: adaptive thinking is on by default, and there is now a five-level effort setting. Both change how you should be configuring Claude Code, and most teams we talk to in Sydney and Melbourne are still running configurations tuned for a model generation that no longer exists. Here are five patterns worth revisiting.
1. Stop over-prompting for reasoning
A lot of prompt scaffolding written for earlier Claude generations exists purely to coax the model into thinking before answering: instructions to work step by step, to consider alternatives, to check its own reasoning. With adaptive thinking on by default, much of that scaffolding is now redundant and occasionally counterproductive, because it competes with the model's own allocation of reasoning effort. Strip those instructions out and re-benchmark before assuming they help.
2. Use the effort setting deliberately, not maximally
The five-level effort setting is a genuine cost and latency lever, and the instinct to pin it at maximum for everything wastes real money. Routine work such as renaming symbols across a codebase, updating import paths, or drafting a straightforward test does not benefit from top-tier effort, while an architectural refactor across service boundaries does. A team running everything at maximum effort can easily spend two to three times what a tiered approach costs for output that is no better on the simple tasks.
Low effort: mechanical edits, formatting, symbol renames, straightforward test scaffolding.
Middle effort: standard feature work, bug fixes with a clear reproduction, routine code review.
High effort: cross-service refactors, tricky concurrency bugs, anything where a wrong answer is expensive to unwind.
3. Rebuild your context strategy around the larger window
Opus 5 offers a 1M-token context window, which invites the lazy pattern of dumping an entire repository into context and hoping for the best. That works, and it is expensive and often less accurate than a curated context. The better pattern is a pre-tool-use hook that filters context to what the current task actually needs. Teams applying this consistently report cutting per-request token use by more than half with no loss in output quality, and often an improvement, because the model is not distracted by irrelevant code.
4. Revisit your output token budget
With up to 128K output tokens available, generation limits that previously forced awkward chunking of large refactors are mostly gone. If your Claude Code workflows include logic to split a large change into pieces because the model could not emit it in one pass, test whether that splitting is still necessary. Removing it often simplifies the workflow and reduces the state-management bugs that chunked generation introduces.
5. Re-run your evals before trusting old benchmarks
Any internal benchmark your team ran against a previous model generation is now a historical document, not a current decision input. This matters most for teams that chose a particular workflow or model tier based on a comparison run six months ago, since the relative performance and the pricing have both moved. Budget half a day to re-run your evaluation suite against Opus 5 at a couple of effort levels before assuming your existing configuration is still the right one.
An Adelaide engineering team we work with did exactly this and found their standing configuration, high effort on everything with heavy prompt scaffolding, was costing roughly $2,600 AUD a month more than a tiered setup that scored equivalently on their own test suite. That is a straightforward saving available to most teams who have not revisited their configuration since upgrading.
A note on migration risk
None of this argues for upgrading a production workflow the week a model ships. The sensible pattern for an Australian team running Claude Code against real production code is to move a non-critical workflow first, a test-generation pipeline or a documentation task, watch it for a fortnight, and only then migrate the workflows where a bad autonomous decision costs real money. Model upgrades are usually improvements, and usually is not a strong enough guarantee for the service that processes your payments.
The pattern underneath all five
Every one of these comes down to the same discipline: configurations written for a previous model generation carry assumptions that quietly stop being true. Adaptive thinking made reasoning scaffolds redundant. The effort setting made uniform maximum settings wasteful. The larger context window made aggressive context pruning less necessary but curated context more valuable. None of that is obvious from a release note, and none of it shows up until a team deliberately re-tests.
For Australian engineering teams standardising on Claude Code, the practical cadence worth adopting is a short configuration review after each major model release rather than a rolling set of habits accumulated over a year. Half a day of re-benchmarking per release is cheap against the cost of running a stale configuration for months without noticing.
