What really burns tokens is sub agents. I once gave Claude Code a pretty big task, and it immediately launched 7 sub agents which burned through my budget before even one of them was finished. Tried again 5 hours later: same result.
If I let the main agent do the same task sequentially, it was no problem at all. I don't know if it's really just communication and orchestration that makes sub agents so inefficient, or if Anthropic figured that most people using sub agents pay per token on a big corporate account, so this is an easy way to make more money from tokenmaxxers.
As a counterpoint: in a complex project, Fable's "curiosity" may be exactly what you want for an exploration and planning stage - not just for the orchestrator that turns your prompt into different angles with which to explore, but for each subagent whose task is to search the codebase for one of those "angles." If you truly want no stone unturned, letting those subagents spawn their own discoveries, and recursively grow the surface area of the inquiry, then it's quite reasonable to want Fable throughout.
That said, if your project is "do this well-planned thing on a bunch of things in parallel" then you should absolutely be instructing to have subagents "step down" to less curious models. Their output may well be more cohesive as a result!
The curiosity is inefficient though. So many times I have to stop the agent and tell it to just fucking write the code and try compiling it. Otherwise it will fill its entire context tracing through the program logic to derive from the code itself whether the thing it is about to do would work. It completely fails to notice it can just… try.
Everything about LLMs is inefficient. They have their benefits but watching them reason over things that are painfully obvious, that they've literally investigated before (before a memory compaction), never take a step back aand be like 'this is going too slow let me look for a better way', etc. is painful.
It’s got worse though right? Older models from before everyone went off the deep end with CoT don’t do this and just write the code with 1/10 the token usage.
The downside is the code isn’t as good but it is produced a lot faster and more cheaply and often it’s actually fine.
CoT has made LLMs better (say 50% improvement or something) but increases cost by an order of magnitude. That graph is going in the wrong direction and has been for a while now
This is how I worked with LLMs originally, and I much preferred it. This gave me a much better understanding of the code that I was adding. But, there's no way to keep up with my team like this anymore. It's just too slow when everyone else is working directly in Claude Code.
If the entire team is vibe coding and there is no human audit then there is no way but to vibe code, for sure.
I would also just vibe it if there is no responsibility, but if I do it that way I don't even care what happens with the project.
I get so detached from it that I stop caring and if it has huge critical bugs..I just don't care anymore because it's not my responsibility or my code at all at that point. I'm just there to nudge things along.
Just hook it up to Jira and let the managers add the features then pass it off to QA.
Real engineering is fully automated at that point.
> I just don't care anymore because it's not my responsibility or my code at all at that point
Yep, 100%.
Business has made it clear they don’t care, so there’s no point in burning one’s energy. Throw the whole thing on auto, check out, and go do something else during the day.
I agree, that work in these places is likely short lived, if for no other reason than working in them is awful and demoralising. My point is, that these places exist, and have such a hard-on for “oh my god, AI!!!1!1!” that putting in extra effort there, is a waste of your own energy.
I'm just thinking: The result is net-net the same. Either they terminate your contract as a salaried employee or they do it as a consultant. The fee is higher as a consultant and you never have to say you were fired. You're making a really good argument for getting into consulting.
You can just answer the same rote questions to different companies for max salary, then when the going gets tough you can essentially 'fire' the company and say they've moved past your core consulting paradigm. Maybe suggest a new consultant and move one. Rinse; repeat.
Parent comment said they end up "...pass[ing] it off to QA."
Edit: suppose that very well could have been tongue-in-cheek.
Side note: as someone who has been interested in programming for a while, but didn't end up in a software dev track in life, it's been pretty wild watching the ride you all have been going on lately. I used to be pretty bummed I didn't get to do that kind of work for a living, but lately I've been feeling more and more like I dodged a bullet.
Not that I don't have my own AI-related junk I have to deal with where I did end up, of course. I think most have.
I like it but how much context does it need for a complex program? If you're giving instructions and using its code, I imagine context is being passed back up in an exponential way. If not, and you give it a very thin context every time, how do you manage to prompt it enough?
It's tuned for the kinds of tasks where "just try" doesn't get good results.
A major complaint with AI code was that AIs struggle with complex codebases, don't respect existing conventions, reinvent functionality multiple times over, etc. So, newer high end AIs are tuned with the "explore/exploit" dial turned towards "explore".
You could probably get it to do things "quick and dirty" with prompting, but that, of course, requires prompting for it.
I get what you're saying, but these instances are of a different type. It is along the lines of "if I pass None for this parameter, will it default to X or return an error?" and it looks, but finds that the actual logic is distributed across multiple files. And so it quickly falls down that rabbit hole.
All the while, it could have just done a two-line probe test and see what happens when it calls the API with "None" for that parameter. Or just assum it would act as expected and wire in debug logs in case it doesn't.
That is the usual work of high end programmers, right? Growing codebases as consistent, dependable ontologies?
I feel like most mainstream programming languages do this sort of work for their standard libraries and their official docs. Go and Python come to mind, but plenty others do this reasonably well to the point where one mostly doesn’t need to read the implementation code to effectively use the standard library itself.
I use the human-in-the-loop for managing the context.
Give it only what it needs and do things usually 1 file at a time.
Feels like I'm a sort of manual tape editor, if the context was a tape fed into machine, I assemble that and then watch the machine output the results I need.
that's why i mostly use it for asynchronous work, the inefficiency is something i can bear with because the subscription costs are dirt cheap. if it's token-based, it wouldn't make financial sense.
Next time it does that expensive scan, run order it to keep or update an index on the codebase. It really helps prevent these expansive scans if you have additional markdown files for LLM navigation.
Fable and sub agents are two different things. There are many situations for which Fable is great, but Fable doesn't have to run in a sub agent. You can use it for your main agent and that works fine.
Or are you saying my sub agents burned so many tokens because they were all using Fable, whereas my main agent could do the same job with a lesser model?
I think the commenter (who is not me) is saying to use Fable as the main agent but then use lesser models for your subagents so that you get the advantages of Fable to plan but then the subagents don’t cost as much, and may be more focused because they lack Fable’s thinking modes.
I’ve heard the proper pattern is to have Fable write a software design doc and then tell Opus to follow that doc strictly in implementation and testing.
I hear that too, but I'm much more ad-hoc about what model I use for what. Opus can be good at planning too, and Fable is remarkably good at figuring out obscure complexities in the code.
If the assumption is that they can be searched in parallel and it takes the same amount of tokens as doing it sequentially. What you would gain is a speed up.
I vaguely understand you argument with the context, however is that not solved by sum agents handing their results in to the planner (or a third agent) to run on them again? I'd assume that's what is happening anyway. Let me know if that's wrong
How do I get it to spend fable tokens on “curiosity” then switch to cheaper models? Preferably based on its own judgment of what model is truly needed.
Just ask it to. If you want, you can also give it pointers to how to read .claude jsonl/metadata so it keeps track of usage and self-adjusts. It's not perfect, but it's pretty dang good if you just say 'This project is allotted X% of my 5h limit'.
doesnt intelligence involve knowing where to start and what to read and not just throwing everything in the bag.
im on local only AI and subagents are only valuable when they avoid polluting the context with extraneous file reads and parallel exploration when fixes are linear.
as OP is on about, subagents burn tokens because they arnt a deterministic intelligent gatherer but like pooluring water into a maze hoping the exit will illuminate.
Sub agents each have to read part of your code base again to get enough context for the task. And if they take too long, your orchestrator's context is no longer in cache so you pay full price for that again once the subagents finish
If you do it sequentially you only read those files approximately once, and everything hits the same prefix cache
Yes but one of the key things about subagents is they keep all of their tool calls and exploration out of the parent context.
If you plan on continuing on in the parent, and aren't going to necessarily be touching the systems the other agents are exploring, it can be worth it.
It's useful in certain situations where the parent context may need the "10,000 foot" view of something without going back in there. But subsystem-specific AGENTS.md/CLAUDE.md files are still superior and accomplish the same thing. The problem with those is they can become stale.
It seems like there could be a useful strategy of writing a plan with a main agent, and then instead of spawning subagents to implement, fork the main context to write each part. Then use one last fork to verify the work. That way you keep reusing the same context without polluting your main context for when you are ready to continue.
I've started doing this by hand in OpenCode and it works pretty well. But there's no UI support for maintaining a tree of related session forks so there's a little bit of manual fussing involved with session naming to keep organized. I also like to end a session with an "AI-friendly terse but detailed summary" (or some equivalent prompt) that I can then dump out to a Markdown file and then the mainline session can still get info back from the branch session. I don't know how much of this is automatable with OpenCode plugins, or in another hackable harness like Pi.
Right, so it’s a trade off between contexts. There are two reasons to use subagents, parallelism and tailoring of context. For the second, there is the “personality” of the subagents as well as how much context is injected from the main agent. Ignoring the personality, you ideally want the injected context to be small and focused on a single task so the subagent doesn’t get distracted. You want the main agent to be orchestrating all the subagents, but not reading all the same files they are reading, otherwise you’ll be paying for the same tokens in multiple contexts. IMO, this is where prompt engineering comes in, to be able to guide the main agent as to where subagents are desired and where not.
For the sake of accuracy Claude Code has a "fork" feature which does what you'd expect and based on traces I skimmed this morning it seems under some circumstances you get fork behavior for subagents as well.
Every subagent send the same ~30k system prompts. If you are using fable/opus, that's easily 30% of a 5-hour window for 7 subagent, before doing any work
I'm gonna jump in here and say that the way Anthropic's KV cache works (prefix matching) doesnt guarantee this at all if the subagents are all put into flight at close to the same time. There's nothing in the agent SDK that allows you to instance more than one agent simultaneously, and the docs don't say anything special about KV cache use by agents in this scenario.
You could probably engineer your own harness or workflow to warm the cache by running a single warmup agent, but this is not at all how the tools behave out of the box. It's mostly a cost optimizaiton, so Anthropic really don't have any incentive to do it proactively, and if they did, surely they would want to tell their customers how much they were saving?
Compared to the primary agent, maybe. But it's highly unlikely that all the agents have different tools and system prompts than each other, and those account for the bulk of the context per the post.
There's no single call that can launch multiple event loops at the same time, so there really isn't a notion of serial or parallel; it's always going to be a simple question of how the first model calls made by each hit the backend. I highly doubt that a bunch of agents created within milliseconds of each other are going to get cache hits. It's more likely they will spin up in parallel. I strongly suspect if Anthropic were trying to deduplicate their inflight requests for cache efficiency, they'd at least want to tell you about it.
The system prompt and available tools would likely only change for different agent types. So how they're launched probably doesn't matter.
I say this as I don't actually know how Clade Code does this, since it's not open source, but I fail to see why two agents doing the same thing launched at different times would have different tools and system prompts.
I think you are right and most people here are overthinking it.
If you make a bunch of identical API calls quickly, before the initial request completes its cache write, you will have cache misses.
If you make a single API call to warm the cache, then make a bunch of subsequent identical requests, you will have cache hits.
The optimization for this sort of thing is to deduplicate in-flight requests, but i've seen no evidence that is being done; the better design pattern would be an api or tool call that explicitly launches multiple agents after a shared prompt processing stage
I'm pretty sure the system instructions are a function of your environment and not the same universally. That said, there should be a finite number of branches so still cacheable.
Same for me. I never use them. I use Fable on highest effort to plan things and then record the plan in tickets. I use Kata, which is CLI and agent oriented, but I suppose Jira or other systems would work too. I tell it to put enough context in each ticket to on-board a fresh coding agent to implement it. Then I just do /goal, telling to to run `kata ready` to get new tickets to work and continue until they're all closed according to acceptance criteria or until they're blocked on actions from me. I need to play around with getting it to switch to smaller models (or spawning 1 subagent) to do ticket implementation and then auto compact after each. Either way, it results in really easy workflows and uses very few tokens compared to the built in subagent flows that doing this completely avoids.
Subagents with a fat tailed latency distribution completely masks the trough filling that puts the most downwards pressure on per-token COGS.
This is why the subscription plans are forced through the harness (the "OpenClaw Wars"): it creates a false equivalence in the minds of many customers between API tokens (latency sensitive, easy to measure) and Claude Code tokens (remnant backfill to stay to the right of the roofline, marginal cost often zero).
Selling sausage as sirloin is a great business if people go for it. And there's nothing inherently wrong with spot pricing, as long as you're honest about it...
I had learnt that trick, so now I explicitly disallow Fable subagents.
Yesterday, I wanted to review a complex piece after a large refactoring, and requested a review plan beforehand. The first step was 8 agents + one more to verify the findings (all Fable). Looks good, approved.
The verification step turned into an attempt to throw a party with 41 Fable verifiers.
I find it useful for code reviews (spawn a subagent with minimal/no context to review X commit). Of course, this is more or less a shortcut that could be done with a seperate agent. Another use is multiple reviews at once if tokens are not an issue, with seperate "personas" or focuses. As far as implementation goes I have not seen any major usecase.
Yeah, my personal workflow has different reviewers for codebase(patterns, code cleanliness, etc), frontend, security, product fit, etc. So they spawn as separate subagents. Both so that they stay limited to their role, and so they don't have preconceived notions about the implementations. It's a bit heavy-handed but works for me.
> CRITICAL: Do NOT spawn sub-agents for any reason. Perform all work in the main session. If a task is too large, ask me to break it down manually.
> This is a big task, and can easily get too large. However, sub-agents make the situation worse, and eat through our token budget way too fast. Do not use them.
> Take on manageable tasks. Don't try to do everything at once. When you start on a big task, break it down into smaller tasks, and make sure you finish each task before starting on the next one.
Or actually Claude put it there for me. Maybe it's a bit much, but it seems to work.
I think there's some setting to restrict the number of them, or maybe turn them off. Doesn't happen for me ~ever and it's not my $$ (work) so I haven't really looked at it much.
> What really burns tokens is sub agents. I once gave Claude Code a pretty big task, and it immediately launched 7 sub agents which burned through my budget before even one of them was finished. Tried again 5 hours later: same result.
Probably because the general purpose subagents inherit the parent model.
I tell Claude explicitly to use Explore subagents, which use Haiku only, now.
Yeah, I was surprised. I had Claude make a skill to extract the explore agent from Claude Code, but set the model back to haiku. Here it is if it's helpful:
for subagents to be cheap/effective, you have to specify the size of those subagents; i.e. right now by default 5.6-sol spawns many 5.6-sol subagents. 5.4-mini as subagent saves me tons of tokens. 5.6-sol audits the work before accepting it, so there's not really a quality issue.
It’s funny too because I’ll ask fairly simple things and it’s fine, similarly simple question might spin up a bunch of sub agents and I don’t know why….
I feel like maybe it could have asked for clarification or something rather than go and try to calculate all the digits of pi all of a sudden.
They did recently change it so the default explorer agent inherits the session agent (capped at Opus). Before Explore was always haiku. I had Claude write a skill that extracts the built in Explorer agent skill, and then writes an identical Explore agent that uses Haiku
Probably both. The default subagent orchestration is designed for infinite pockets.
Maybe when they realize there is need to change this they come up with a more configurable interface for us mere mortals who can't afford to gamble their house on a pay as you go subscription.
There is a negative incentive to fix problems that result in customers picking a more expensive plan to work around it. There are probably several engineers who have ideas about fixing this and they get apathy from many people and obstruction from a few, and sometimes active hostility by a manager somewhere in the chain.
The best you can do in such an environment is seek to introduce new features at the top tier, and then pull old features down the stack as the cost of those features has been amortized out, or to hurt your competitors by raising the ladder.
I’ve had similar experiences. I now have an explicit line in AGENTS.md to not use subagents unless explicitly requested. It also helps that for the tasks that are big enough to benefit from subagents are also the ones with high chances of going off-rails and/or a poor review phase. I’d rather do the orchestrator role and that way I can split up the review phase in a much more manageable chunk.
> I still have PTSD from how ungodly terrible it was
Please, for the sake of everyone suffering from actual PTSD: Don't. It's hard enough already for victims to communicate what difficulties they are facing without people watering down terminology like that.
I am asking them to reconsider and reflect on what that kind of language use does. You're the one reading it as "calling them out".
How else are we supposed to learn from each other, voice our opinions, point out our mistakes to each other? For me, this is communication. And currently 8 upvotes seem to agree with me and my request. Feel free to ignore it, or consider it, for your own use of language. But, sorry, to me, you're the one acting like a jerk and trying to "police", not me.
PTSD sucks on its own. Trying to blame other people for its symptoms is a deflection. It would be like someone with ADHD blaming his inability to concentrate on everyone else in the room making noise or moving around. People with OCD tried this, acting like it's a Monopoly property that you have to pay rent for if you land on it / say its name.
If anything, it's a net positive people are talking about mental health and recognize different ailments such as OCD, PTSD, and others.
I agree with what you say? I think you're reading something into my writing that I didn't mean to imply. A headache is not a migraine is not cluster headache is not multiple sclerosis. We have vocabulary so we can express ourselves in an attempt to communicate. I am inviting people to reconsider their use of language when it comes to severe challenges such as PTSD. We are here to exchange opinions after all. If you find that offensive, so be it. You decide for yourself how you express your disapproval; two opinions can stand next to each other without introducing "blame" or "deflection".
I agree with you that it's a low effort, repetitive drone when people say "that cable job irritates my OCD" or "I still have PTSD from dealing with that annoying person". I don't like hearing it because it makes me think that person is a parrot that repeats common phrases instead of developing their own voice. So at least we agree partially.
I disagree that it's insensitive to those or have the illness. If it hurts you when people use PTSD as a literary special effect, I invite you to articulate why exactly it makes you feel (however it makes you feel - I don't want to put words in your mouth). I get the sense that some people take offense the same way a religious fundamentalist doesn't want to hear their Prophet or Messiah used disrespectfully. The source of the anger is built on faith and dogma.
This has been my experience as well. Something happened 2-3 months ago with Claude Code. It got slower, starting spinning and getting stuck more and more. I gave codex another shot out of my Claude frustrations, and have never looked back again.
Just tried Claude Code yesterday, and nope, it's the same old bad.
They optimized it to burn more token in the recent months I feel. I made a small ~100 line change to a codebase by hand and threw claude at it to review. It spawned several sub-agents and burnt a ton of tokens. I guess the word 'review' now triggers some sort of in-built skill or something. It's absurd how rapid enshittification is taking over.
Agreed. The issue is that when working 1:1 you get a feel for how many tokens are being burned but the subagent spawn could be 3 or in one cases it spawned 171 to verify something. The latter was unexpected and burned through my token budget.
For a while everyone was saying sub agents is how you save tokens, use lower quality models with limited context to do simple parts of the job after a smart planning agent has put it all in place. Is that no longer true or is this just the result of sub agent being used at the wrong time?
No, you can definitely configure low cost search and apply subagents. CC and Codex do not. Not sure if this is to improve the reliability of their subagents, or just a play to increase user consumption.
Subagents are quite inefficient and the lossy context transfer between them does lead to more cost and more waiting. However I have found it to produce more reliable output, whether that is worth it for a given task has been a consideration.
I like to use subagents a lot, but I find them to be most useful when explicitly specified. E.g. "assign these tasks to 2 Sonnet, 2 Opus and 1 Fable subagent". Helps keep allocation consumption under control.
Not only a Claude Code issue. Started using OMP with GPT 5.6, and gave up, it loves to use subagents, and it's basically unusable subagents with GPT 5.6 Sol there with Plus limits.
lol I asked fable to help me estimate my TAM and it launched 102 agents and blew my $120 quota in 6 minutes. I do realize I can limit the agent count , hah
It's in the best interest for AI companies to gobble up tokens. I feel like every new release - Fable, etc - is just a way to extract more tokens/money.
(If) something like the current LLM/agent paradigm remains in a few years, and companies settle down into their respective niches, I imagine more user-friendly tools will be built, with more control over subagent spawning, context, caching, etc.
What's happening this year, with secrecy and all, is saddening, but expected.
it's a very handwavey way to "explain" anything. Yes, they make money. But they have competition. And if someone runs out of tokens and switches to deepseek or just goes for a friggin hike in the woods, that does not benefit them. If they get a public image of a ripoff that burns all shit on trivial tasks, that does not do them good either. So there is a limit to this "companies make money" thing.
Sure, fair enough. Clearly, if they increase costs by too much, people will go to their competitors, but those competitors also make money selling tokens, so the whole industry is incentivized to inflate token consumption up to the point of driving people to the competition. And nobody is incentivized to reduce token count.
In fact, the one model with great price/performance is Deepseek v4 Flash and I suspect that they are subsidizing it deeply to get access to everyone’s prompts for training. We may find that they raise prices on the next version (v5) after they’ve mined the user data.
Any AI service that people (and to some extent companies) can afford to pay for today is being heavily subsidized. Will that last forever? I really don't know how those economics work, but I know that bubbles do burst having lived through the dot com burst in 2000. And I know this current one is going to hurt if/when it bursts.
On the issue of the bubble, I’m right there with you, 100%. I’m not sure that “subsidized” is the right word for Anthropic’s or OpenAI’s pricing, though. I’d say it’s forward-priced. Supposedly, they have claimed that inference by itself is profitable; it’s the ongoing training that is not. I don’t know what nuances apply to that, however.
If I let the main agent do the same task sequentially, it was no problem at all. I don't know if it's really just communication and orchestration that makes sub agents so inefficient, or if Anthropic figured that most people using sub agents pay per token on a big corporate account, so this is an easy way to make more money from tokenmaxxers.