If your Claude Code team burns through its usage limit by lunch after one real task in the morning, the instinct is to assume the quota is too small. Talk to enough Sydney and Melbourne engineering leads running Claude Code across a handful of seats and you will hear the same complaint: the plan feels expensive relative to what actually ships. The more useful read is the opposite one. You are paying frontier prices for a model to do work that a cheaper model would handle just as well. There is a specific pattern, the orchestrator pattern, that Australian teams can put in place in an afternoon, and it consistently cuts Claude Code spend by 30 to 40 percent without touching what gets shipped. Here is how it works, and what we would check first in your own setup.
Stop treating the model as one thing
Frontier models like Claude Opus 5 are extremely capable, and also the most expensive and slowest tier to run. As models get stronger, the frontier tier stops being the thing that writes your code and starts being the thing that decides what code gets written. Anthropic's own Claude Code documentation now recommends this directly: use the strongest model as the planner, and a smaller model as the executor. Sonnet 5 costs roughly a fifth of Opus 5 and performs close to what was the strongest model on earth only a few months ago. That is not downgrading. That is paying current prices for last season's frontier capability, and it is the first lever worth pulling before you touch seat counts or plan tiers.
Two ways to split the work, and only one of them is cheap
Claude Code supports splitting planning from execution in two shapes, and the difference between them is where most of the wasted spend hides.
Advisor: a main agent does the work itself and occasionally calls out to a stronger model to review its plan.
Orchestrator: a stronger model plans the work, freezes the spec, and spins up worker agents on a cheaper model to execute it.
The orchestrator pattern wins, and the reason is token accounting rather than raw intelligence. An advisor has to re-read the main agent's full conversation history every time it is asked for input, and that is fresh, uncached, full-price input tokens on every single call. A worker only receives a task brief, and once a subagent session is warm, its context is cached at roughly a tenth the cost of fresh input tokens. Put plainly, the advisor pattern quietly charges frontier rates for re-reading your own transcript, over and over, for the life of the project.
The leak most setups don't catch: subagents that don't persist
The bigger cost leak sits in how sub-agents get spun up in the first place. Traditionally, a sub-agent runs once, returns a result, and dies. If the main agent wants a revision, it dispatches a brand-new sub-agent with zero context, which re-reads the same files and re-derives the same understanding at full token cost, every time. The fix is a persistent sub-agent. Feedback goes back as a follow-up message to the same session, which still holds everything it learned, cached and close to free to keep using. Claude Code's agent teams already support this natively: a coordinator can message an existing teammate session directly, that teammate stays resumable until it is told to stop, and you can set the model per agent when the team is first started. Skipping this one setting is the single most common reason a business ends up paying full advisor-style rates while thinking it has already switched to an orchestrator setup.
How to tell if you're already paying advisor prices
Most teams do not choose the advisor pattern on purpose. It is simply what Claude Code does by default if nobody has configured a delegation structure, and it is easy to run for months without noticing the cost shape underneath it. A few signals are worth checking directly. If every follow-up request or revision seems to cost roughly the same as the original task, that is a strong sign sub-agents are being respawned from scratch instead of resumed. If your CLAUDE.md has no delegation-rules section at all, the coordinator is almost certainly doing both planning and hands-on execution on the same expensive model. If nobody on the team can say which model each agent in a session is running, the per-agent model setting has never been touched. None of these are hard to check, and none of them require pulling detailed usage reports, though pulling those reports afterwards is the easiest way to confirm the saving once the pattern is in place.
It is also worth being honest about where this pattern does not help. A solo founder running one Claude Code seat on small, self-contained tasks will not see much benefit from an orchestrator setup, because there is no repeated re-reading of a long transcript to eliminate in the first place. The pattern earns its keep once a team is running multi-step builds, revision cycles, or several parallel workstreams on the same codebase, which is exactly the profile of most Sydney and Melbourne engineering teams that come to us asking why their Claude Code bill does not match the size of their team.
Turning this into a CLAUDE.md delegation section
A short delegation-rules section in your project's CLAUDE.md file is usually enough to switch this on. It needs four things:
Define the coordinator's role: design, review, land the work, and never touch hands-on execution directly.
Define what gets delegated by default: implementation from a frozen spec, refactors, bug fixes, dependency bumps, and read-heavy exploration.
Define what stays with the coordinator: architecture and naming decisions, tiny edits under roughly 20 lines, and anything touching releases or secrets.
Add one firm rule: a spawned executor never spawns its own subagents.
That last rule matters more than it looks. Uncontrolled recursive delegation is exactly what turns a cheap pattern back into an expensive one, because every extra layer of sub-agents re-introduces the same full-price, uncached calls the orchestrator pattern was built to avoid.
What we'd check first in your setup
For a business running Claude Code seats across a small engineering team, the gap between an advisor setup and a proper orchestrator setup is often the difference between burning through your monthly allowance by Wednesday and having headroom to spare, without changing what the team ships. On a team spending roughly $2,000 to $4,000 AUD a month across several Claude Code seats, a 30 to 40 percent cost cut works out to somewhere between $600 and $1,600 AUD back a month. For most Australian small and medium businesses, that is not a rounding error, it is a real line item. If your Claude Code usage feels expensive relative to what your team is actually shipping, the CLAUDE.md delegation section above is a same-day change, not a re-architecture, and it is usually the first thing worth auditing before you assume you need a bigger plan or more seats.
A quick checklist before you touch your plan
Before assuming you need to upgrade plans or add seats, run through this list with whoever owns your Claude Code setup:
Is the strongest model configured as planner only, with a cheaper model handling execution?
Are sub-agent sessions persistent, or does every revision spin up a fresh, context-free agent?
Does your CLAUDE.md have an explicit delegation-rules section covering coordinator role, default delegation, and what stays with the coordinator?
Is there a hard rule blocking spawned executors from spawning their own subagents?
Have you measured token spend before and after, rather than assuming the pattern is already in place?
None of this requires a rebuild. It requires an audit of how your team's Claude Code sessions are actually structured, and a same-day edit to a config file most teams have never touched. If you want a second set of eyes on your setup, get in touch and we will walk through where your Claude Code spend is actually going.
