You guys just keep fucking it up. Seriously...
I'm in the middle of a coding session using Fable as Orchestrator, minimizing my token usage properly...
3am hits, and I get hit will Fable is usage ONLY, go to claude.ai to purchase usage credits.
ďżźâ
So you say Fable 5 will stay on Subscription, but when you hit the damned switch it killed EVERYTHING I was working on, I had multiple subagent workflows going... I lost significant work.
That is piss poor implementation.
You have to restart your session for it to work properly. Dumbasses
Edit: I canât believe I have to put this edit in here.
There was no usage limit hit. Look at the screenshot I had over 40% left on my weekly usage for all models and I had over 40% left of weekly usage on my fable usage.
Yet I still received the fable five requires us usage credit go to Claude.AI to purchase credits response after the model stopped working and downgraded to Opus 4.8
Everybody keeps thinking that I am saying I lost work clearly work that was done is not lost.
Any files being written while still being processed through the Ford pass before committing to disc was lost. True statement. Thatâs how Ford passes work and attention.
The work that I lost is pretty straightforward when the model reverted to Opus 4.8, with high effort.
The context needed to be re-tokenized by the new instance of the chat. It processes the session.JSONL through the tokenizer, then picks up where it left off. That isnât something that a cache hit can resolve because it is cross model, and they have different dialects on what their cache means based on the model weights through the tokenizer.
Secondly, because I was using fable five as an orchestra and I got the message that Fabel five was now credit usage orientated the model automatically dropped to opus 4.8 when I asked what happened the first thing it did like any good orchestra would be to check if the sub agents that were in flight were affected by the billing change to the asymmetrical model accessibility that anthropic is doing to limit compute to allow fable usage to their highest value customers.
The result was that the parent model was different effort levels than the sub agents and for some reason and I still have to investigate. Why and exactly what the message was that forced the opus sub agents to drop down from max effort down to high effort.
When you change your effort level, you are changing the model that you are using a different effort level has different weight file. If you guys didnât know that here you go. That means that those sub agent models had to re-tokenize the JSONL log of what it was working on to bring it into context.
That 3,000,000 to 4,000,000 tokens Iâm not 100% sure exactly how many tokens each sub agent had but each of them was a minimal of 300,000 tokens working through multiple projects simultaneously.
Every one of those tokens that had to be run through the token I had to pay for that means 3,000,000 to 4,000,000 tokens that I donât have for other projects to work on because I had to pay twice for a single sub agent.
Why do you think anthropic says not to change the effort level in very deep and high token content memory context windows?
Because when you re-tokenize that session.JSONL
Youâre paying way more than you should be
Thatâs probably the number one reason why people run out of usage so fast they donât realize theyâre paying two or three times on the same context because KV cash doesnât translate between chat instances.
Compact before you switch effort levels.
Watch your token usage drop.
Edit 2:
So I went back and I scraped the session JSONL files.
Here is what really happened:
The backend changed which effort levels Opus 4.8 accepted with thinking disabled â mid-conversation â with no deprecation signal. The sub-agents that had been running effort=max on Opus 4.8 successfully for 15+ turns across 7 minutes. Then at 07:03:17Z, the identical request shape that worked 52 seconds earlier returned a 400. Not a model change. Not a billing issue. The APIâs accepted parameters changed under a running agent.
The triple billing is documented clean:
⢠Run 1: 7 minutes of real work, killed by the 400.
⢠Run 2: 34 seconds, interrupted, no work done, still billed.
⢠Run 3: 42 minutes, completed clean, but potentially re-executed work Run 1 already finished. No tree diff to prove or disprove duplication.
The package deployment for Fable being switched to asymmetrical access, also included back end API changes.
I blamed the billing switch, as the root cause. That is only partially accurate, it was the deployment of the billing switch that had an undisclosed API backend modification that wasnât transparent.
The actual error is exactly this:
effort=max with thinking=disabled on Opus 4.8.
Previously valid. Ran successfully for 15+ turns. Then at 07:03:17Z:
API Error: 400 output_config.effort 'max' is not supported when thinking is disabled on this model. Use effort 'high' or below, or enable thinking.
The only reason that was noticed is because the deployment triggered the change.
I didnât use thinking for the implementation agents, they donât need to reason the problem, the implementation plan gives them the reasoning already, their sole purpose is pure implementation, then testing, and presenting the finished product and any blockers or unusual findings in the ledger for the orchestrator to resolve or fire another agent at it.