The One Rule for Safe Claude Code API Usage: Tier Your Tasks

The Mistake Everyone Makes

New Claude Code users send everything to Opus. It is the flagship model — it thinks harder, it catches more, it produces better output. Why would you use anything else?

Then the bill arrives.

The problem is not that Opus is overpriced for what it does. The problem is that most tasks do not need Opus. A well-structured coding task — write a function, add tests, refactor a module — runs just as well on Sonnet at roughly half the cost. You are paying for reasoning depth you do not use.

The fix is not to use Claude Code less. It is to be intentional about which model handles which work.

The One Rule

Route each request to the cheapest model that handles it reliably. This is not about being cheap with your tooling. It is about preserving the Opus-tier reasoning for problems that actually need it while running the routine work at Sonnet prices.

Tier 1: Sonnet for Day-to-Day Work

Sonnet handles the bulk of what you do with Claude Code. Feature implementation, test writing, bug fixes, refactoring, code review, documentation — these are well-defined tasks with clear targets. Sonnet gets them right without the overhead of flagship reasoning.

The savings compound here because this is where you spend most of your API calls. Running Sonnet for eight hours of development work costs a fraction of what Opus would cost for the same session.

When to use Sonnet: you know exactly what you want, the task has a clear scope, and the risk of being wrong is low because you can verify the output quickly.

Tier 2: Opus 4.6 for Production-Critical Code

Move to Opus 4.6 when the cost of being wrong is real. Code that ships to production, API interfaces that other systems depend on, authentication logic, database migrations — these are where Sonnet starting to show limits becomes apparent.

Opus 4.6 is meaningfully cheaper than 4.7 while delivering nearly all its reasoning capability. The use case is production work where you want confidence but do not need the absolute top tier.

When to use Opus 4.6: the task involves reasoning across multiple files, the code will have real consequences if it is wrong, or you have found yourself correcting Sonnet repeatedly on similar tasks.

Tier 3: Opus 4.7 for Genuinely Hard Problems

Opus 4.7 is for the problems that make you stop and think before describing them. Complex debugging where the root cause is buried under several layers. Architectural decisions with competing tradeoffs. Security-sensitive code where missing a vulnerability is not acceptable. Large refactors that touch many interconnected files.

These are the tasks where Sonnet gets confidently wrong and Opus 4.6 does not quite get you to the right answer. When you feel the friction of Claude Code failing to solve a problem at a lower tier, that is when you go up.

When to use Opus 4.7: the task is genuinely hard, you have already tried Sonnet and hit a wall, or the cost of being wrong is high enough to justify the premium.

Making It Stick

The tiering system only works if you actually apply it. Set a default model in your claude_settings.json:

{ "defaultModel": "sonnet-4-6" }

Then switch explicitly when a task warrants it. Use /model opus-4.6 mid-session when you hit a problem that needs it. Most of your session will run on Sonnet. The Opus calls will be for the problems that genuinely need them.

This is not about rationing Claude Code. It is about matching the tool to the task so you have headroom for the hard problems without blowing your budget on the easy ones.