If your team runs Claude Code, two settings quietly decide most of your cost and quality: which model you pick, and how much effort you let it spend. Get them right and the tool feels sharp and economical. Get them wrong and you either overpay for trivial edits or watch a capable model give up halfway through a hard refactor. The two dials look similar, but they solve different problems, and knowing which one to reach for is most of the skill.
Two dials, not one
Model and effort are separate controls. The model is the set of fixed weights doing the reasoning: its knowledge and raw capability are baked in. You can hand a model more context or steer it with instructions, but you cannot make a smaller model fundamentally smarter on a given request. Effort is different. It governs how much work Claude does before it reports back to you: how many files it reads, how many tools it calls, and how many steps it takes. A small model on high effort and a large model on low effort are genuinely different animals, and they cost different amounts.
What the model setting controls
Choosing a model is choosing a capability ceiling. A faster, smaller model like Claude Haiku handles routine, well-specified work at low cost: renaming things, small edits, boilerplate, obvious bug fixes. A larger model like Claude Opus earns its higher token price on ambiguous, multi-file problems where judgement matters more than speed. The mistake most teams make is running everything on the biggest model because it feels safer. That is a fast way to turn a $400 monthly bill into a $2,400 one without a matching lift in output quality. Match the model to the difficulty of the task, not to your anxiety about getting a wrong answer.
What the effort setting controls
Effort is often read as thinking time, but it is broader than that. It decides how thoroughly Claude works a problem from start to finish:
How many files it reads before it acts, instead of guessing from one.
How many tools it uses, including running tests and checking its own work.
How many steps it takes before it stops and checks back in with you.
Higher effort means Claude reads more, verifies more, and finishes more of the job on its own, at the cost of more tokens and a longer wait. Lower effort is quicker and cheaper, and perfectly fine when the task is small and the instructions are tight. Anthropic's guidance is to start each model on its default effort and treat effort as a standing preference for the kind of work you usually do, rather than something you adjust on every request.
A rule for deciding which dial to move
When Claude gets something wrong, the useful question is why it failed, because the answer tells you which dial to turn:
If it had all the relevant context, clearly tried, and still produced a wrong or shallow answer, reach for a more capable model.
If it went wrong by skipping a file, not running the tests, or bailing on a refactor partway through, raise the effort instead.
That single distinction saves a lot of wasted spend. Teams reflexively jump to the largest model the moment anything breaks, when half the time the model was fine and simply was not asked to do enough work. A capability problem and a thoroughness problem look the same on the surface and have opposite fixes.
Turning this into a cost policy
For an Australian business watching its AI spend, this is where governance actually lives. You do not need a committee. You need a one-page default that most of your engineers follow without thinking: small model plus default effort for everyday changes, step up to a larger model for genuinely hard or open-ended work, and raise effort when a task needs Claude to read broadly and verify itself. A Sydney development team we work with cut its Claude Code bill by roughly a third by moving routine work off the flagship model and reserving it for the problems that warranted it, with no drop in what shipped. On a $3,000 monthly spend, that is about $1,000 back each month for a ten-minute policy.
The point is not to be stingy. It is to spend where capability changes the outcome and save where it does not. Most Claude Code budgets balloon not because the work is hard, but because everything is being run as if it were.
Where to start
Pick your defaults, write them down, and let people override them when a task clearly calls for it. Review the bill after a fortnight and see where the tokens actually went. If you want a hand setting a model-and-effort policy that fits how your team works, you can book a brainstorm with us and we will map it to your stack. Australian teams adopting Claude do best when these decisions are deliberate, rather than left on the most expensive setting by default.
