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!

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

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

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.

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.

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

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

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

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

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.

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.

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

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.

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?

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

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.

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.

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

--disallowedTools Task

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.

Did it deploy five AWS m8g.12xlarge instances?

Once I realized that Anthropic is a token merchant, I start to understand Anthropic’s decision more. They are always finding reasons for you to use more tokens through them unless the users revolt or demand some guardrails.

I thought I read somewhere that according to filings for going public, subscription revenue is tiny… like 5%.

Edit: consumer Claude subs are the 5%. I’d bet most all of CC subs lump in under enterprise.

  - API & Enterprise: 75% to 85% of total revenue.
  - Business Subscriptions: Roughly 10% to 15%.
  - Individual Subscriptions: About 5%.

> I use pi btw.

When using Pi, one way to significantly reduce input tokens it yields is to ignore common bookkeeping "dot directories", such as `.git`. How to do so can be found with the following interactive Pi prompt:

  How do I configure Pi to ignore git related artifacts, such 
  as the project's .git directory?

You're making the opposite argument. Anthropic is incentivized to use less tokens in Claude Code because people are paying a fixed monthly fee for subscriptions.

> My opinion is that claude code uses more tokens simply because Anthropic makes more money that way and forces people into their subscriptions.

OTOH, this makes typical subscriptions usages consume more tokens, which are included in their flat fee.

This sounds more like incompetence than malice.

> I use pi btw

Not sure if intentionally meant as a reference, but it gives "I use Arch btw" vibes.

the amount of system prompt wastage going on in orgs is insane. we identified 400k in annual burn for zero value in just one section of our large company.

and the interesting thing about system prompt wastage is its a cost that scales non linearly with subagent use.

> This is supported by the fact that they won't let you use your sub on a different coding agent

I mean, that's a very weak argument? Isn't a much more plausible explanation that with your tooling you'll have more of a lock-in than with just your model?

If cost were the only factor of course you'd use B, but presumably you also care about quality quite a bit.

Thanks, I'm looking forward to this!

I wonder if a lot of the 33k is context, like from recent conversations.

I often find myself annoyed when Opus fixes a typo in a comment and decides to run tests, lints and whenever else it can find to run. Often it will start by stashing current changes just to preemptively check if all tests were passing before. And I can blame myself a bit because my rules do say: verify all changes with tests. But as there is that I in AI that is hyped which you’d think means it knows not to put tomatoes into fruit salad …

> prompts such as “Hey” or “commit” sometimes triggered 30+ tool calls

I read that this is because it wastes time looking through past conversations and other context to figure one what you might want it to do - a less ambiguous prompt would be better.

Why are you asking the LLM to commit? Can’t you do that yourself?

Maybe related to this minimalism, Pi doesn't come with most of the tools an LLM needs to function efficiently or effectively. I get that a blank slate is the paradigm, and you can add whatever you want, but it's too blank IMO.

Read through it an I'm curious whether setting the date and cmd on every system prompt call will cause the cache to invalidate.

I guess the cache would only be invalid if the day changed or the root directory, which would technically happen infrequently enough.

I was here looking for this comment = )

If you really want a minimal agent that you heavily customize, just skip pi (130+ transitive dependencies on the "minimal" pi-coder package) and write your own. You learn a bunch, and it's not hard. You can even ask another LLM to help you get started.

I use both now and agree they're basically interchangeable.

I appreciate that Codex is open source and OpenAI has explicitly said using the subscription with other agents is ok. OpenAI has been much more consumer-friendly recently.

What settings have you tried since it "became more opaque"? They've got a lot more settings now.

The good thing is that the competition in the field is very cutthroat with so many contenders, so if there are gains to be made they will be made, and then broadly adopted by others.

> --system-prompt ""

Doesn't the model need at least a basic system prompt to understand what tools are available?

Yep, have been using this for a long time now. No idea why everyone doesn’t.

I didn’t know you could do this. Is there any analysis of the impact, before and after? I’d love to see some charts of efficacy in real world usage.

Do you start Claude with this option? Or do you send this with every prompt?

This is interesting, because if I start a fresh session of Claude Code right now and run /context, I see the following:

   Opus 4.8 (1M context)
   claude-opus-4-8[1m]
   23k/1m tokens (2%) 

   Estimated usage by category
   System prompt: 3.9k tokens (0.4%)
   System tools: 13.9k tokens (1.4%)
   Custom agents: 235 tokens (0.0%)
   Memory files: 28 tokens (0.0%)
   Skills: 4.9k tokens (0.5%)
   Messages: 8 tokens (0.0%)
   Compact buffer: 3k tokens (0.3%)
   Free space: 974k (97.4%)

> In a pay per token situation, there is a huge conflict of interest with the harness provider and the token seller being the same party ... efficiency is less profitable.

Except there’s a competitive incentive to either use less tokens or make the tokens go further

Anthropic's cache expires after 1 hour when using subscription endpoints, and for those cached tokens cache reads are free. It's generous (compared to API pricing) but it's not 100% free.

Nice!

> When context gets too long, maki compacts history automatically: strips images, thinking blocks, and summarizes older turns.

Don’t the summaries of older turns effectively invalidate the context cache, such that you consume less tokens but more expensive tokens?

Why turn thinking off? I mean, yes, it uses less tokens, but you're using the best model OpenAI offers, but then making it as dumb as cheaper models.

We are yet to try Pi!

Anecdotally, the results from OpenCode + Claude appear to be the same if not better for our uses over the past year.

They sort of are, in that they want subscription users to have clients that behave well with the KV cache etc.

If you don't use a subscription, and pay per token instead, you can easily move to another harness.

As for context size and harnesses I did make a trivial bash agent based on this "agent in 50 lines" tutorial[0] recently, and found that for trivial work, it was about an order of magnitude cheaper and faster.

I haven't tested it on anything bigger but it doesn't seem to do the kind of proactive testing, that they do in bigger harnesses.

Codex at least has a system prompt that tells it not to consider a feature a complete until it has verified it. I'm not sure about Claude Code.

I suppose I could add that one line to the prompt, and it would get me much closer to agi :) I think Fable does this proactively even without a prompt, but I haven't tested that yet.

If Fable in my own harness is significantly cheaper than Claude Code, that would be very appealing. (I could actually afford to use it for most things!) But I think most of the cost comes from the testing it does. So we'll have to see.

[0] https://minimal-agent.com/

Fable's subscription inclusion theoretically ends EOD today. Anthropic put a wishy-washy "if we have capacity we'll continue it" thing, and given how competitive GPT 5.6 Sol is, and it is included in OpenAI's subscription, I fully expect Anthropic to extend Fable or they will have a serious exodus on their hands.

Competition is good.

You can't afford the best model. What are your specs and what models + quants have you tried?

Qwen 3.6 35B A3B and Qwen 3.6 27B can both do reliable tool calls on Pi at Q4_K_M using llama.cpp

I have just re-analysed most common failed tool-calls and adjusted the tool so that it works. I have a manual repair step on failure that programmatically attempts to fix some things. On failure, the harness reports the error, the repaired function, and the result. Overall, seems to work fine. But it's very model-specific. Most commonly the model fails on shell commands where it hallucinates some programs. If it does it often enough, I just promote those to commands in the PATH. Over time, it has happened less.

> and on-device model combination right now

That would depend entirely on what your device is. This sounds likely not to be an issue with the harness, but the capabilities of the models you've tried.

I experience almost no tool call failure using my nothing-special harness and DSv4 Flash.

Pi.dev requires some plugins to work well. Using Qwen3.6-27B/35B locally at Q8, I was quite frustrated with failed tool calls and tried many things.

Ultimately this combo worked:

1. https://pi.dev/packages/pi-tool-guard —- corrects key name synonyms and common structure errors, so tool calls succeed automatically (e.g if the model hallucinates old_str instead of oldText). It also wraps top level oldText/newText in an edits array if the tool didn’t do it.

2. https://pi.dev/packages/@aboutlo/pi-smart-edit - white-space-tolerant edits, as Qwen would sometimes add a fifth space to a four space indent

Hashline edit tools didn’t work well for me at all, they confused the model and it still failed to edit correctly. Also line removals would invalidate the rest of the file requiring re-reads. I tried pi-hashline-edit-pro, though I see it now keeps a database of hashes to help keep them stable across edits. Regardless Qwen kept thinking that the hashline prefixes were part of the source.

Well, I have to open the lid on my computer and remember my password, no?

Been my experience as well. Human corrected code is orders better than ai generated slop. Slop might get you the promotion at your day job who is still in fomo tokenmaxx mode, but highly recommend the careful review for your personal projects

I find it hilarious people think they can build on slop or on captured output from quality engineers. Intent is the most important aspect, and no code base could ever capture that

OpenCode, Crush and Pi do have the ability to fork a conversation. But cache reuse is up to the provider and not guaranteed. At some point you need to forward the cache to a more recent checkpoint, and you have a finite (unknown) number of parallel cached chats.

The Sleev (the project has been renamed to make a startup) creator was shilling their project in the OpenCode Discord. That person is very convinced they have something that no one has ever built before. They focused on token reduction without any real evals for capability impacts.

I'm generally against this context pruning without prompting or details. Sleev is very opaque about how it works and definitely will bust your cache.

OpenAI, to their credit, seems to be focusing pretty heavily on token efficiency in GPT 5.5 and beyond.

GLM isn't good enough yet.

It pays to be marginally ahead of people stuck on open models.

Given they're incentivized to increase token use, what guarantees that higher token use improves the effectiveness of the agent and isn't just artificial padding?

Is there evidence that it is actually a better agent though?

Model:

Cost, mainly. The runs went through a Claude Max subscription rather than metered API billing, and pinning an older stable snapshot kept run-to-run comparisons clean and cheap. The fixed harness payload (system prompt plus tool schemas), so the headline numbers shouldn't change too much.

That said, happy to re-run the matrix on Fable and publish the diff; payload figures should barely move, tool-calling behaviour might.

Gateway:

Meridian (github.com/rynfar/meridian); proxy that bridges the Claude Code SDK to a standard Anthropic endpoint so a Claude Max subscription can drive OpenCode-et-al.

It's the auth route for all agent traffic on the machine, not something built for the benchmark.

Elon saying that it is "Opus level" doesn't actually make it so.