Agentic workflows is what consumes a lot. When you have an automated agentic loop working towards a given goal. If you use an LLM as a support for your own work you don’t end up consuming that much tokens, if you have multiple agents working on things independently, reviewing the work of other agents, etc you very, very quickly burn all your budget
Personally, I use gpt 5.5 high with planning every time and plan various smaller features/changes in parallel, then approve them one after another. This allows me to steer it (which I need more often than not) before approving the plan, thus reducing the otherwise accumulating slop.
Using goal doesn't work for everyone, unless you have an unreasonably strong test suite or harness that the agent can verify against.
I think a senior dev/architect + some good models is still the goated combination.
Generating code and building features, even before AI, was never the issue. Stability, knowing what to build when, and boring business problems (licensing, distribution, sales, etc) were the limits.
With the latter you can, for example, say "Wait, this should be an interface because later on we need different concrete implementations". With the former, the agent doesn't do that, gets to the point where you actually need the flexibility interfaces give you and refactors everything to handle that. That is at least 2x the work/tokens. Multiply this for all the decision points you have to do to deliver a big piece of work and you have your bagillion tokens consumed.
Use worktrees to parallelize development on multiple tasks.
That's all there is to it.
In many cases, this means a new solo project rather than a project at work with a team.
In my iOS app with around 100k LOC, Claude Code typically uses 150k context for small tasks.
For tasks that take longer and run the tests to instrument and investigate outcomes, the context grows to 250k-600k. With a few of those in parallel, busy days can consume a lot of tokens.
If you're working on isolated components within a system or small projects, you'll have a very different experience.
Any overages (hourly/weekly/model) on these plans gets billed at rack API costs.
Its not practical to expect these subsidies to last for very long.
This talking point from Anthropic that Claude Code sitting in a Ralph Loop is burning top sirloin interactive session tokens is bad faith hogwash and it only flies because most everyone who has run this shit at scale either already works there, sells them hardware, or hopes to be an acquisition target.
I'm none of those things, so I'm happy to tell you they're lying. I know, it's hard to swallow, but it turns out Altman and Amodei are occasionally full of shit.
In an HBM bandwidth constrained setting you're dealing with something called "roofline analysis" (comes originally from NUMA work circa ~2009 but it's applicable to modern GPUs). Great diagram from the JAX people:
https://jax-ml.github.io/scaling-book/roofline/
In order to get your money's worth from a modern GPU (or disagg rack like an NVL72) you need to decode (the one token at a time thing) across big batches of context windows. To the left of that point where it hits "the roof" you're idling tensor units. TensorRT-LLM likes batches of 4096, so BS=4096.
In the case of one person chat prompting their local LLM, BS=1, totally bandwidth limited.
So the game is to set some latency target with some control theory primitive (PID or something) and then delay the next token until a batch is big enough to not waste tensor units. This is a real trick when a human is waiting (you've probably seen the thing in Claude.ai where it's all bursty and then they reflow the whole block with JavaScript).
Agentic workloads are huge piles of context windows where you've always got enough who want the same experts on the next token, you're always to the right of that intersection. And it doesn't really matter if it's on the other side of the world, or lags by a second, it's fine.
Claude Code soaks up all the tensor units that would be idle until they're full, and only then does it leak into the capacity reserved for highly interactive use. It's the bottom of the barrel until it's rinsed the fuck out.
They want more margin on agentic tokens. That's it. The COGS on them is the absolute lowest of anything they do.
1. wouldn't write stuff like "I've only spent a few hundred dollars using gpt-5.5/5.6 and codex"
2. wouldn't think tokens are cheap
It then has to look over everything see how it connects together and then decide the best way to do something.
Giving it small and very focused plans when you already understand the system gets it done fast and cheap.
There is more to it than this, but much of the cost structure around subscriptions etc is specifically designed to allow for that experimentation.
There are good cynical takes, here, too. At the current model costs I don't need to optimize my expenses, but that could change if it climbs eg above 30% of my salary^
Note: this is an easy thing to prove ROI on. If I'm writing 5-6x more code and reviewing commensurately more code, and those PRs are better-tested and get us to shipping quality features faster, this is easy to justify and we are not that price sensitive
In retrospect, I should have just spend a few days learning the basics, but you don't know what you don't know. And part of me can't help but feel companies aren't exactly prompting agents to be courteous when onboarding newbies because they want people like me to get hooked, and token maxxing on their end helps. I spent few $100 more than I should getting subs/tiers I didn't need, but at the time it was small $$$ for productivity gains from going from 0-1.
Shepherded the writing of on the order of a half a million lines of code