Hacker News Reader

Comment by mcv | Hacker News Reader

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.

View on HN

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.

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.

Perhaps what is missing is a better memory/caching layer to avoid doing the same for explorations over and over again.

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 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 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.

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

CoT?

Chain of Thought, according to a quick search

I think I use it differently. I still mainly stick to web UI.

I write a good prompt, paste the code then copy the output code and place it into my project.

So in the end I hand assemble and I only give it what it needs to know so no extra context wasted.

The human in the loop is of course the secret sauce but this way I am highly efficient, no vibecode and I work really fast too. Everything is audited.

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.

Are the QA team bearing the brunt of the unexpected issues, bugs, performance etc or is it business-as-usual?

Amusing that you think businesses still have QA teams.

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.

Curious what industry your in and what your facing AI wise?

They do, it’s just that these days they are your users or customers.

That is indeed, the joke.

My employer has a QA team

Mine does (Sample size: 1)

> 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.

> Throw the whole thing on auto, check out, and go do something else during the day.

If that's what you're doing, you're fucked (in today's society, at least). What happens to your job when they figure out that's what you're doing?

Plenty of companies, very much _want_ this.

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.

They need somebody to blame though, and you're much cheaper than a consultant.

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.

Wow, this is almost Dilbertesque level of absurdity.

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?

Avoid making programs very complex. They can grow big and have a lot of features, but stay as simple as possible.

Depends what I want but I can give a completely new context for every generation.

I try to make everything as simple and human readable as possible because I want the audit to go fast.

I think for me I lean towards an audit optimized approach. Everything is still generated but revolves around the human-in-the-loop for review.

That's what the person you replied to is saying. You don't need this model.

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.

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.

I need the full context window to get the work done though.

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.

But how is that better than a single agent searching those "angles" sequentially?

Unless they are orthogonal they most likely require similar context anyway so multiple sub agent is just wasteful.

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

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.

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.

Using VS code if it matters.

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'.

I never thought of that. Thanks!

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.

They are just making the point that it makes sense that subagents would use more tokens because they have none of the parent's context.

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.

That is true of Anthropic's implementation but not inherent in sub-agents in general.

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.

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.

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 recently did a few tests. And always the same prompt has been cached properly.

Cache is usually not shared between agents - they can have different base prompts, tools, and be an entirely different model.

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.

Depends on if they are launched serially or in parallel then.

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

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.

If it's always the same prompt, can't they have it pre-cached globally for all?

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.

System specific stuff is probably quite limited, it can be a short dynamic segment at the end of the system prompt, perhaps.

The system behaviour is totally up to anthropic's discretion. Its current behaviour is verifiable. In claude code, spawn a subagent with

1. Agent("Test")

2. look at your token usage

3. Repeat a few times

I didn't check again as I type this message but am somewhat sure subagent doesn't cache system prompt as of maybe last week

The shared prompts are all cached so it's a cache read which is like 10x cheaper than a regular prefill

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?

Well yeah Claude caching is frustrating. If implemented correctly subagents are really cheap.

True. For Claude Code, I disabled explore subagents globally by adding this to ~/.claude/settings.json:

  "permissions": {
    "deny": [
      "Task(Explore)"
    ]
  }

Is Explore the only thing subagents are ever used for?

Should be

"Agent(Explore)"

You're right, looks like they changed it, though Task should still work.

> In version 2.1.63, the Task tool was renamed to Agent. Existing Task(...) references in settings and agent definitions still work as aliases.

https://code.claude.com/docs/en/sub-agents

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.

Very interesting approach. Thanks for sharing.

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.

It will find a way.

Don't do that; limit concurrency

"LGTM"

That'll be $50 — please.

And in my experience the sub agent performance is usually worse than just a single agent.

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.

Spawning a bunch of agents seems to happen randomly. I almost never want this.

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.

Such is the nature of tool use

In my CLAUDE.md I put:

> 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.

If there's some "find the file" task, using full context for that isn't ideal.

> 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.

> Probably because the general purpose subagents inherit the parent model

only if you don't specify which model should be used

They changed it with the release on July 1 Explore now inherits the model, it isn't always haiku.

https://code.claude.com/docs/en/changelog#2-1-198

> The built-in Explore agent now inherits the main session’s model (capped at opus) instead of running on haiku

Urgh, thanks for the heads up. I guess I need to be explicit about my choice of model 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:

https://gist.github.com/joshcartme/dd71df7b4c51c356760b28d7f...

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.

Yesterday I gave Claude Fable a difficult task. It then proceeded to spawn 415 agents. It got it done, but damn was it expensive.

This is why I happily use Codex.

I run it basically 24/7 on a ~500k line repo, and only rarely run out of quota before the end of the week.

My experience with Claude Code was very good until about 2.5 months ago, and then it suddenly turned unbelievably terrible for me.

I have not and will hopefully never look back.

I still have PTSD from how ungodly terrible it was that last week of using it.

Can you be more specific about what “unbelievably terrible” means?

> 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.

They have Coder PTSD or CPTSD.... Is that a better acronym???

Sorry just teasing.

Please don't act as the hyperbole police. People exaggerate all the time (I'm starving, etc). It's normal, and you are being a jerk to call them out.

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.

Have you ever said "I'm starving"? Do you think that undermines the experience of people actually starving in war or famine?

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.

Indeed it feels like I do the same work, ask the same questions, get the same result.

But somehow the cost has doubled in the last few months.

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.

Well, Anthropic and OpenAI make money selling tokens, so…

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.

--disallowedTools Task

Did it deploy five AWS m8g.12xlarge instances?

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.

Of course it is. How could it be anything different? Clearly, that’s how these companies make money.

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) 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.

i have globally disabled subagents for claude. otherwise one prompt ended my Pro account

Reply on news.ycombinator.com