Friday I spent an hour with a founder who's building AI tools for estate administration. They aren't an engineer by background, they built a real working product with Claude Code anyway, and they keep hitting their daily rate limit and having to stop. On the $200-a-month Max plan. One expensive model running where it didn't need to and the afternoon is gone.
What they wanted was a way to keep working without running out.
So we spent the hour on getting more useful work out of the same budget. Almost none of that is about picking a better model.
This matters well beyond one founder. Most people using these tools aren't thinking about token efficiency yet, because they're running a few discrete tasks a day and they're nowhere near the ceiling. Hand agents real multi-step work and you find the ceiling fast. The fixes also aren't a setting you flip once you get there, they're decisions about how the whole thing was set up, so the cheapest time to make them is before you need them.
Same list whether you're one person or a whole product team, because the failure mode is identical at both sizes.. it just costs more at scale.
Most of the waste happens before anybody writes code
The instinct is to look for savings in the code, and that's the wrong place to look because by then you've already paid for it. The expensive decision happened earlier, when something decided to build a thing that didn't need to exist.
So I put the gate in planning now. Before it touches anything, I make the AI name the smallest version that could possibly work, say what it can reuse from what's already there, and explicitly call out what does not need to be built at all. That last one is the whole trick and it's the one people skip. An agent left alone will happily build you a configurable, extensible, beautifully abstracted version of something you needed once.
Unnecessary code charges you 5 separate times. You pay to write it, then to review it, then to debug it, then to change it when the product moves, and then you keep paying every time an agent has to read past it or pull it back in to work on something nearby. None of those is the expensive part on its own. Stacked up, they're where the cost actually lives.
The other half of this is guardrails that persist. Engineering principles belong in your `claude.md` file, not in your head and not re-typed into every prompt: no speculative features, no new dependencies without a reason, no abstraction the problem doesn't demand, simplicity first, surgical changes. Andrej Karpathy's principles are a great place to start if you don't want to write your own. That file ends up functioning less like a prompt and more like the engineering culture of the whole thing.
Your most expensive model is quietly cloning itself
This is the one that got the founder, and it's the one I'd check first if you're wondering where your usage went.
By default, subagents run on whatever your main model is. So one instruction quietly fans out into several copies of your most expensive model, all running at the same time, most of them doing work that didn't need that much horsepower, like reading a directory or grepping for a pattern. That's how you burn through your usage in a single afternoon and have no idea what happened.
The fix is boring and it works. Ask the frontier models to delegate the simple stuff down. Claude's lineup goes Fable, Opus, Sonnet, Haiku, and the gap between the top and the bottom is not small.. Haiku costs a fraction of what Opus does. Reserve the expensive one for what it's actually good at, which is ambiguous work where the goal is clear and the path isn't. "Audit this whole repo, figure out why it's become hard to maintain, and give me the best plan to simplify it" is worth a frontier model. Renaming a function is not.
I run Opus on high reasoning as my daily driver and route down from there. If you're on a team, this is the part I'd standardize rather than leave to preference, because one person's default becomes everybody's usage.
Not every check needs to think
Every model call spends budget, and a good chunk of them get spent on questions that have a right answer a machine can verify exactly for free. Tests, linting, type checks, builds, security scans.. all of that runs deterministically in GitHub Actions for basically nothing, and it never gets things wrong in a creative new way. Save the expensive judgment for what actually needs judgment.
Then for the things that do need a model, don't ask the thing that wrote the code whether the code is good. Have Claude build and Codex challenge, or the other way around. A second model coming in cold catches duplicate functionality, dead code, security holes, and architectural drift that the author is structurally blind to, because the author is arguing for its own work. CodeRabbit does a version of this on every PR for about the cost of another small SaaS subscription, and it's cheap enough that I'd just turn it on.
That's the shape I'd aim for: deterministic checks for whatever machines can verify exactly, a different model for the judgment calls, and a person for the product decisions. No single agent should be expected to do all 3, and most setups I see are asking one to.
A sprawling repo quietly costs you tokens
Every file you keep is one more thing the agent searches past to find what actually matters, and searching isn't free.. those are real calls burning real budget before any work gets done. Worse, a stale spec doesn't sit there quietly.. the agent finds it, believes it, and confidently builds against a decision you already reversed. Then you pay a second time to undo that.
So repo cleanup is a recurring job now, not a thing you get around to. Put AI on a schedule to audit for dead code, obsolete specs, old planning docs, duplicate implementations, unused dependencies, and modules that should have been consolidated. Then actually delete what it finds.
Componentize what genuinely repeats, and not before. Early on, duplication is fine because you're still discovering the product and you don't know yet which patterns are real. Build fast enough to learn, watch for the pattern, then consolidate the version that survived contact. Duplication early is fine. Duplication forever isn't.
And if you're starting out, stay in one repo. Microservices, multiple repos, Kubernetes, Terraform-heavy anything.. those are all answers to problems you don't have yet, and every one of them makes your agents slower and your context more fragmented while you're still trying to find out whether customers care.
Wrapping up
None of these are a big move on their own. Stacked up, they're the difference between running out by mid-afternoon and getting a full day of real work out of the same budget.
The honest part is that AI still gets you most of the way and the last stretch to production is the hardest part. You'll probably need real engineering help for it, and that's fine.. just don't go pay for it before you've proven anybody wants the thing. Prove customers care, then harden it.
Putting this into action
Go find out what your subagents are running on. If the answer is "whatever the main model is," that's your usage problem right there, and it's a config change, not a project. Set the default down and promote specific tasks up.
Run one repo audit this week and delete what it finds. Ask for dead code, obsolete specs, duplicate implementations, and unused dependencies. The deleting is the part people skip, and it's the only part that matters.
What I'm reading
Demystifying evals for AI agents. If you're going to trust an agent with real work, you need a way to know whether it's actually good at it. This is the clearest practical writeup I've seen on building that.
Peter Steinberger on building in the agent era. On managing an army of agents and how the hype nearly broke him. Worth it for the honesty about the parts that didn't work.
Don't classify. Hallucinate!. Simon Willison on tagging a huge backlog of old blog posts by letting the model just make the tag up. Nice reminder that the obvious framing of a problem is often the expensive one.
Cursor + SpaceXAI: the fastest iterating team wins. Move in the right direction faster than anybody else. Lands differently once your iteration speed is genuinely a function of your tooling.
Claude's workflow improvement planner. Turns a vague process complaint into a structured improvement plan. Unglamorous, and a good first thing to hand somebody on your team who wants to use AI but doesn't know where to point it.
Some AI tips for this week
Give the AI a scratch drawer. Agents generate a ton of temporary junk, and by default all of it lands in your repo permanently. Tell it that analysis, throwaway scripts, and intermediate planning go in a dedicated scratch directory and get deleted when the task is done. I do this on my VM and it's the cheapest thing on this list to set up. Your repo stops accumulating artifacts nobody will ever read again.
Ask your repo what's dead. One prompt: audit this entire codebase and list dead code, obsolete specs, duplicate implementations, and unused dependencies, with a one-line reason for each. You'll get a longer list than you expect. Do it monthly, and put it on a calendar so it doesn't quietly become never.
Onward & upward 🤘
Drew
P.s. I've been messing around on weekends making little retro pixel characters and videos. It's been a fun creative outlet and a throwback to the lifestyle brand I started over 15 years ago. Maybe I'll make a retro game 🤔
P.p.s. If we haven't met yet, hello. I'm Drew Burdick, Founder and Managing Partner at StealthX. We work with brands to design and build great customer experiences that win. I share ideas weekly through this newsletter and over on the Building Great Experiences podcast. Have a question? Feel free to contact us. I'd love to hear from you.