Every developer using Claude regularly has hit the same wall eventually — either the API bill is bigger than expected, or you're bumping against your subscription quota mid-task more often than you'd like.
Most advice on this topic is either too vague to act on, or written for enterprises spending thousands a month. Here's the practical version, built for a solo developer or small team actually trying to get more out of every token.
First — Understand What You're Actually Paying For
On the API, you pay per token, with input and output billed separately, and different models carry different rates. Sonnet 5 is currently priced at $2 per million input tokens and $10 per million output tokens through an introductory window ending August 31, 2026, after which it moves to $3/$15. Opus is roughly 1.67 to 2.5x more expensive depending on the pricing window — a meaningfully smaller gap than the 5x figure older guides still quote.
On subscription plans — Pro or Max — you're not billed per token. You hit a usage quota instead. The optimisation strategies below apply either way, but what you're protecting is different: dollars on API, headroom on subscription.
1. Put Your Project Context in One File, Once
This is the single highest-leverage change available, and most developers still aren't doing it.
Storing project context once in a CLAUDE.md file eliminates 500 to 2,000 tokens of repeated setup per session, every single session. Without it, you're re-explaining your stack, your conventions, and your project structure every time you open a new conversation — tokens spent purely on re-establishing context Claude should already have.
Set this up once. It pays for itself within your first few sessions and keeps paying for as long as you use the project.
2. Only Include the Files That Actually Matter
If you're working in a large codebase, including only the files relevant to the current task uses 60 to 80% fewer tokens than dumping broad context and letting Claude figure out what's relevant.
This matters more in monorepos and large projects, where the temptation is to give Claude "everything just in case." That instinct is expensive. Scope the context to what the task genuinely needs, not what might theoretically be useful.
3. Match Model and Effort to the Actual Task
Claude Code supports effort settings — low, medium, high — and lower effort means fewer tokens spent on reasoning. For routine tasks like formatting, linting, or a simple review, effort: low cuts token usage substantially with no noticeable quality loss. Reserve high effort for the tasks that actually need deep reasoning — architecture decisions, security audits, complex refactors.
The same logic applies to model choice. Not every task needs Opus. Sonnet handles the majority of everyday coding work at a meaningfully lower cost, and dropping to Haiku for simple, well-defined tasks saves further. Route by task complexity, not by habit.
4. Ask for Structured Output Instead of Prose
If you're using the API for extraction, classification, or any task with a defined output shape, ask Claude to return structured JSON instead of natural language. This can cut output tokens by 40 to 70% on these task types — a natural language answer that runs 200 tokens often compresses to 60-80 tokens as a clean JSON object with only the fields you actually need.
This is one of the more underused techniques. Most developers write prompts the way they'd ask a colleague a question, then pay for a full paragraph reply when three fields of structured data would have answered the question completely.
5. Suppress Thinking Output You're Not Using
If you're on the API and using extended thinking, Claude's newer models support thinking.display: "omitted" — this strips the thinking content from the response so you're not paying output tokens for a reasoning trace nobody's reading. The model still reasons internally and the signature is preserved for multi-turn continuity, but the token cost of the visible trace disappears.
This is specifically useful for production pipelines where the reasoning process isn't shown to end users. If nobody's reading the thinking trace, there's no reason to pay to generate and transmit it.
6. Batch Related Tasks Instead of Starting Fresh Each Time
Instead of five separate conversations about five related endpoints, handle them in one session where Claude already has the context loaded. Every new conversation means paying to re-establish context from scratch. Batching related work into a single session means that setup cost gets paid once instead of five times.
7. Measure Before You Optimise Further
Run your usage verbose or check /cost for one full working day before making further changes. Guessing at where your tokens are going leads to optimising the wrong thing. The data almost always reveals a small number of high-waste patterns rather than a uniform problem across everything you do — fix those specific patterns first.
Once you have a baseline, set a concrete target. Track your usage for a week, then set a target roughly 30% lower, and measure whether your changes are actually moving the number.
The Honest Take
None of these changes require a new tool, a new subscription, or a rewrite of how you work. They're mostly habits — put context in one place, scope what you include, match effort to task, ask for structured output when appropriate, batch related work.
The developers who cut their costs significantly aren't the ones who found some clever workaround. They're the ones who stopped treating every session like a blank slate and started treating their setup as something worth investing fifteen minutes into once, rather than paying the same tax on every single conversation indefinitely.
🛠 Dev Tip of the Week
Write your CLAUDE.md file this week if you don't already have one. Fifteen minutes of setup, and it eliminates repeated context-setting costs for every session going forward. It's the single highest-leverage change on this entire list, and it's also the one most developers keep meaning to get to and never quite do.
If you've found an optimisation that's genuinely moved your numbers and it's not on this list, hit reply. Always curious what's working for other developers in the real world.