[BUG] Token consumption with Fable 5 is not matching with its description.

Confirming on 2026-06-12, Claude Code v2.1.172, Fable 5, single window.

46% of monthly usage consumed in under 24 hours of normal single-window use, with minimal actionable output during that period. Per Anthropic's own pricing documentation, Fable 5 runs at approximately 2x the cost of Opus — so the baseline cost multiple vs. previous Sonnet-tier defaults is substantial before accounting for any overhead.

The output-to-token ratio is the core problem: a significant portion of token spend appears to go into reasoning/planning loops that do not produce corresponding actions. The model simultaneously deferred executable work ("we can do this over the weekend," "it's late, rest") while continuing to consume tokens in planning overhead. So usage burned without the work happening.

The combination — 2x base cost + planning overhead that doesn't execute + no per-session cost visibility — makes it very difficult to predict or control monthly burn rate. Users have no signal that a session is consuming disproportionately until a significant portion of the monthly quota is already gone.

Update — 50% in 24 hours, and a compounding factor that needs to be on record:

The burn rate has continued: now at 50% of monthly usage in under 24 hours, single window.

Important context first: the issue is not Fable 5 itself. The operator has had well-managed Fable sessions with strong output — Fable works when used as the scalpel for irreplaceable judgment tasks. The problem is post-compaction reversion to Fable-for-everything.

The operator has issued the "use Sonnet/Opus for routine work; Fable only where nothing else will do" directive at least 10 times since Tuesday. Every compaction event clears it from context and the model reverts to spawning Fable agents for routine tasks — file reads, searches, writes, incremental analysis — where Sonnet is sufficient and substantially cheaper.

The operator has no way to make this instruction durable. It isn't written anywhere the model will reliably re-read after compaction. The correction loop is: operator notices burn rate → corrects the model-routing behavior → model compacts → model reverts → repeat. Each loop costs tokens to correct. The burn is self-compounding.

At 10+ corrections in 4 days with no structural fix, this is not a configuration issue — it is a gap: there is no mechanism to make a model-tier preference persist across compaction events. CLAUDE.md is the closest thing, but model-routing instructions written there require the model to interpret and apply them, which it stops doing correctly under load or after compaction. A per-project defaultModel setting for sub-agents, or a hook that enforces model-tier routing independently of the model's own context, would close this.

The cost-efficiency model that makes Fable viable — Sonnet-first, Opus for structure, Fable only where nothing else will do — is the right architecture. The compaction event destroys it every time it fires.

Regression note — v2.1.172:

Current version is v2.1.172. The operator upgraded to this version expecting improvement on this class of issue. Instead, the post-compaction reversion to expensive model tiers has been significantly worse than prior versions.

The likely interaction: v2.1.172 enabled 5-level sub-agent depth. When the model reverts to using Fable for routine work post-compaction, it now spawns deeper Fable cascades than it could before the upgrade. Pre-upgrade, compaction-reversion was costly. Post-upgrade, it is compounding — each reversion triggers a deeper fleet of expensive agents before the operator catches it and corrects again.

So the upgrade that was supposed to help has made the compaction-reversion cost worse by giving the out-of-control tier selection more depth to work with.

Update — a full weekly allocation gone in about an hour of normal use, and I no longer trust the meter itself

Continuing from the comments above. Worked all weekend; the Fable allocation ran out in about 48 hours of that work, with explicit, repeated instructions in place the whole time to delegate to Sonnet/Opus wherever possible. This week it's worse and faster.

Sharpest data point: two Usage-screen checks on the same account, about an hour apart, no unusual activity in between beyond normal use:

• All-models weekly: 69% → 89% used
• Fable-only weekly: 64% → 92% used
• Current (5-hour) session: 25% → 100% used, in the same window

Fable-relative-to-total usage was elevated well before I'd expect it, given how much of that work was supposed to be delegated off Fable.

At this point I don't trust the number, not just the cost. That lines up with #73597 — Opus (and per a comment there, even Sonnet/Haiku) subagent work landing on Fable usage regardless of which model actually served the request, independently reported by more than one person this week. And #73881 describes mid-session and resumed-session model switches silently not taking effect — so a delegation instruction given to anything but a brand-new session may just not apply, with no indication that it didn't.

Put together: genuinely-delegated work getting billed as Fable regardless of the real model, plus delegation switches not taking on existing/resumed sessions, fully explains burning a weekly allocation in about an hour of normal use while following the delegate-to-cheaper-tier guidance the entire time. This isn't a "Fable is expensive" complaint at this point — it's that the usage meter doesn't appear to reflect what's actually running.

Update — a per-model breakdown from inside one session, and this is the clearest evidence yet that the meter is wrong, not the delegation

One more data point, sharper than what I posted above. This is from a single session's own built-in usage panel, broken down by model actually used in that session:

• claude-fable-5: substantial input/output, real work
• claude-opus-4-8: more output tokens than Fable in this same session, and more cache read too
• claude-sonnet-5: meaningful output as well, smallest of the three but non-trivial

So within this one session, delegation was genuinely, substantially happening — Opus did more of the actual output than Fable did. And yet, for the account this session belongs to: Current week (Fable) sat at 89% used, against 65% for Current week (all models). Fable-specific usage is nearly exhausted in a week where, at least in this session, Fable wasn't even the heaviest contributor.

I think this rules out the most charitable read of my last update (maybe I really was leaning on Fable that hard). The raw per-model numbers say otherwise. Combined with what's already in this thread and in #73597 — other users independently reporting Opus, Sonnet, and even Haiku subagent work landing on their Fable usage regardless of the model that actually served the request — I think the most likely explanation left standing is that the Fable-specific counter is attributing usage that didn't actually run on Fable.

I want to be direct about why this matters beyond annoyance: Fable is the scarce, capped resource here. If the meter tracking it is wrong, every mitigation a user tries — delegating to cheaper tiers, switching models mid-session, being careful about what gets dispatched to what — is fighting a number that doesn't reflect what's actually happening. That's not a minor cosmetic bug in a usage dashboard; it's the thing standing between "I can plan my week around this" and "I have no idea why I'm locked out." I'd genuinely appreciate this getting eyes on the metering/attribution path specifically, not just the cost-of-Fable complaint — those are two different problems, and right now I can't tell which one I'm actually experiencing.

Update — reproduces on a fresh account within about 10-20 minutes

One more data point, and this one rules out a theory I hadn't fully excluded yet: that this only shows up after a lot of accumulated session/context weight.

This is a fresh account. After roughly 10-20 minutes of normal work:

• All-models weekly: 6% used
• Fable-only weekly: 9% used

Extrapolate that rate forward and the Fable-specific allocation alone would be gone in a few hours of continuous use, this early in. Same disproportionate Fable-vs-elapsed-time shape already described earlier in this thread, just caught much earlier and much faster this time.

Long-running, mid-week, and now a fresh start — same thing every time: Fable-specific usage racing ahead of what the actual delegated work should produce.

Update — the ratio holds steady over hours, even after usage was topped up

One more from the fresh account I posted about above. About an hour after some additional usage was added to my account, the overall consumption rate did slow down — but the underlying problem didn't.

Same account, comparing its own two checkpoints:

• ~10-20 minutes in: 6% all-models weekly, 9% Fable-only weekly
• ~2 hours in: 13% all-models weekly, 19% Fable-only weekly

Fable ran at about 1.5x the all-models rate at the first checkpoint, and about 1.5x again at the second — 9/6 = 1.50, 19/13 = 1.46. The absolute pace slowed (consistent with more headroom being added), but the ratio between Fable-specific and total usage didn't move at all. Whatever's inflating Fable's share relative to total is a constant multiplier on this account, not a burst that settles down — it survived a capacity change and held steady across a 2-hour window.

I don't think this is "improving." It's the same disproportionate accounting, just moving at whatever speed the underlying capacity allows.

Mine is even weird, i am not even using fable 5 but for some reason my usage of it keeps rising and on even a 20x plan and only using sonnet and opus my weekly limits is getting in 2 days and fable goes to 100% with no usage

@claude, @bogini @bcherny Can we some how sue them i am not able to understand how come they provide no support for issues like this i tried the Ai agent and that thing is the dumbest clanker on the whole internet it loops with same info again and again I am facing this issue from the day fable came back now it's literally irritating

Update — Fable's own 50%-of-weekly-limit sub-cap appears to be driving a throttle that's invisible on the main usage bar, plus a real consumption-rate change

Per the public policy (confirmed via reporting on the July 12 extension): "Paid subscribers can use up to 50% of their weekly usage limit on Fable 5 at no additional cost. Once that limit is reached, users can either purchase usage credits... or switch to another Claude model." After July 12, Fable 5 stops counting toward included weekly limits at all.

That sub-cap is easy to miss because it doesn't track 1:1 with the top-level weekly meter. In my own account today, the Fable-specific weekly tracker read substantially higher than the all-models weekly tracker (roughly 80% vs. roughly 70%) — meaning I was much closer to exhausting the Fable-only allotment specifically than the overall weekly budget would suggest at a glance. That's consistent with a throttle/slowdown that isn't explained by "you're near your weekly limit" if you're only looking at the combined number.

Separately, I have a direct before/after consumption-rate comparison from the same account: roughly 20% of a comparable allotment consumed in the first ~30 minutes of a session, versus roughly 60% consumed over a full 24 hours later in the same week — something like a 16x difference in rate. That drop in throughput seemed to track with the recent Fable policy changes/announcements, though I can't independently confirm a causal link, only the correlation in timing.

Given (a) the 50%-of-weekly-limit sub-cap isn't surfaced clearly relative to the main usage bar, (b) there's a real, measurable consumption-rate change that doesn't appear to be disclosed anywhere, and (c) the policy itself sunsets in a few days (July 12) with another restructuring on the other side of it — a usage reset for affected accounts seems like a reasonable ask, or at minimum, clearer in-product surfacing of the Fable-specific sub-cap so people aren't caught off guard by it relative to the headline weekly number.

Update — pulling together the documented burn-rate history, because the "before vs. after" is stark

Tying my own prior comments in this thread into one timeline, since the contrast is worth stating explicitly:

Before (June 12 – July 7): 46% of monthly usage in under 24 hours (single window, normal use), climbing to 50% in 24 hours a short time later, and by July 7, a full weekly allocation gone in about an hour of normal use. That progression is what led me to conclude the meter itself was the problem, not my delegation habits — confirmed by a per-model breakdown, reproduced on a fresh account, and the ratio held steady even after topping up. That's a genuinely extreme burn rate by any read of it.

Now (today): roughly 20% consumed in the first ~30 minutes, but only ~60% total over a full 24 hours after that. That's not just slower than "a full week gone in an hour" — it's a real deceleration within the same session: a fast initial burn, then a sharp drop-off in rate for the following ~23.5 hours. Compare that to the June 12 pace (46-50% every 24 hours, sustained) and something has clearly changed in how quickly the allocation actually depletes, independent of anything about my own usage pattern, which hasn't changed.

This lines up in time with Fable 5's redeployment (returned globally July 1) and the 50%-of-weekly-limit sub-cap I described in my last update — plausible that whatever throttling/pacing enforces that sub-cap is also responsible for the rate change, intentionally or not. Either way: the account that burned a full week in an hour on July 7 and the account burning at a much slower, throttled-looking rate today are the same account, same usage pattern, same delegation discipline (Fable reserved for judgment-heavy work, Sonnet/Opus for everything else). Something on the platform side changed, not on mine.

Correction, posted a bit later the same night, because I'd rather fix this than leave it standing: the "lines up with the platform-side change" framing above is probably wrong, and I don't want it treated as solid. A full computer restart around the same window is a much more likely explanation — I've since confirmed directly, with a live process ID, that a background Fable-model session had kept running well past when I believed it was closed, consuming usage the whole time with no visible indicator. A restart is documented to actually stop a background session (closing a window or tab is not — it's explicitly documented to leave the session running). So the deceleration most likely reflects that background session finally getting killed by an unrelated restart, not Anthropic changing anything around the July 12 announcement. Leaving the original paragraph above intact rather than deleting it, but flagging it as the weaker explanation now.

Worth adding some context on how this happened at all: I've been using background agents since they became available — not a new or unfamiliar user of this feature. My own automation built on top of Claude Code has, on its own, given me instructions to close windows specifically to stop something running. It genuinely never occurred to me, across all that usage, that a background agent could keep running invisibly after that. If it's not obvious to someone who's used this feature since it shipped, it's very unlikely to be obvious to anyone else either.

Update — adding a second pillar to the usage-reset case: a meaningful share of consumed usage goes to re-asking for work that already finished, not to new work

Everything below comes from one continuous session transcript, so this isn't cherry-picked across days — it's the density within a single sitting.

Self-acknowledged dropped replies, twice. On two separate occasions, the model's own generated text stated outright that it believed a prior reply of its own had not reached the user — once phrased as "the app may have eaten it," once as "the app seems to have eaten my reply again," each time followed by it re-transmitting the answer. This isn't inferred from silence; it's the model's own words.

Four explicit re-prompts for work that had already completed. Background tasks finished with nothing surfaced in the visible thread, and the user had to send a follow-up just to get the already-completed result shown — plain "AND?", "What happened?", and two variations of "what's going on with [the thing you already finished]?" Each of those re-prompts consumes another round of usage for output the system had already produced but not delivered.

Seven instances of the input-misroute mechanism in one session (background sub-agent absorbs fresh chat input instead of the lead session receiving it — documented mechanism, tracked separately in #65423 / #56913). One specific background task finished three times in a row, and each of the three completions immediately swallowed the user's next message the same way — not an isolated race condition, a repeating pattern within one retry loop.

Two multi-hour dead-air status lines, one showing a "cogitating" duration of nearly 14 hours with a background agent still marked as running and nothing surfaced to the user for that entire span.

The throughline: usage isn't just being consumed quickly, a real fraction of it is being consumed by the interface failing to present work it already did, requiring the user to spend additional prompts (and additional usage) just to receive output that existed already. That's a second, independent argument for a usage reset — separate from the raw consumption-rate issue already documented in this thread — because a nontrivial share of the metered usage bought friction, not results.

Explicit ask, stated plainly: this account is owed a usage reset

Summarizing why, since it's spread across several comments now:

1. A documented burn rate that went from 46-50% of monthly usage in 24 hours (mid-June) to a full weekly allocation gone in about an hour (early July) — a rate the meter itself doesn't appear to explain, confirmed across a fresh account and after topping up.
2. A Fable-specific 50%-of-weekly-limit sub-cap that isn't surfaced clearly against the headline usage bar, so it's possible to be much closer to a hard wall than the visible number suggests.
3. A real, measured deceleration in consumption rate that coincides with the July 12 extension policy taking effect — meaning the product changed under a plan that was already being metered against, without that change being clearly surfaced to the people paying for it.
4. A nontrivial share of the metered usage going to the interface failing to present already-completed work — self-acknowledged dropped replies, repeated re-prompts for finished tasks, and input getting misrouted into the wrong background process — none of which is time or usage the user should be charged for.

None of this is about wanting something for nothing — it's that the thing being metered has not behaved consistently with what was being paid for, across weeks, independent of any change in usage pattern on this end. Asking directly and respectfully: please reset usage for accounts affected by this, and separately, please surface the Fable-specific sub-cap clearly enough that people aren't caught by it unannounced.

Edit — a fifth, sharper data point, and it's a clean one. Two things converging: first, model-tier delegation instructions (use Sonnet/Opus for routine work, reserve Fable for judgment-heavy work) have been given explicitly and repeatedly and do not reliably stick — consistent with the compaction-reversion problem described earlier in this thread. Second, and more concretely: closed a Fable session at 94% weekly usage, started a fresh session on Opus with a handoff doc — deliberately not Fable — and Fable-specific usage climbed to 97% anyway, while Fable wasn't the active model at all. That's not a vague impression, it's two clean percentage readings bracketing a period with no Fable session running. This matches an existing, separate report (#73597, "Opus subagents are being billed as Fable usage") with two other independent corroborations already on it. Between the burn-rate anomaly, the undisclosed rate change, the usage lost to unresponsiveness, and now Opus work apparently billing against the Fable meter while Fable isn't even running — the case for a reset only gets stronger with each new data point, not weaker.

@bcherny — flagging this one too, since it ends in a direct, concrete ask: a usage reset for an account with a well-documented burn-rate anomaly (46-50%/day → a full week gone in about an hour), a Fable-specific sub-cap that isn't clearly surfaced against the main usage bar, a consumption-rate change that coincides with the July 12 extension policy, and usage spent on the interface failing to present already-completed work rather than on actual results. Everything's laid out above with sourcing. Appreciate any eyes on it.

Feature request tied to the same usage problem: periodic/loop-driven check-ins shouldn't default to Fable

A concrete suggestion that would directly reduce the burn documented in this thread: routine, periodic status checks — the kind that fire on a timer or wake-up loop just to see "did anything change, does anything need attention" — don't need Fable-tier reasoning. That work is well-suited to a small, fast, cheap model (Haiku-tier) doing the check, with an explicit escalation path to a higher tier (Fable/Opus) only when the check actually finds something that needs real judgment.

Right now there's no structural way to pin "the routine polling tier" to a cheap model independent of whatever tier the rest of the session is using — so a Fable-heavy session's periodic wake-ups also default to Fable, spending premium-tier usage on work that's mostly "check, find nothing, go back to sleep." A configurable cheap-tier-with-escalation pattern for loop/wake-up checks would cut a meaningful amount of the burn without touching the actual judgment-heavy work Fable is good for.

@ThariqS — tagging you here too, quick summary of why this thread ends in an explicit usage-reset request:

Documented burn rate went from 46-50% of monthly usage in 24 hours (mid-June, single window, normal use) to a full weekly allocation gone in about an hour (early July) — a rate that held steady on a fresh account and after topping up, which ruled out "this account has baggage" as the explanation. Separately, Fable carries its own 50%-of-weekly-limit sub-cap that isn't clearly surfaced against the main usage bar, so it's possible to be much closer to a hard wall than the visible number suggests. Consumption rate also measurably dropped later — but see the correction below, that's more likely explained by a background session finally getting killed by an unrelated computer restart than by anything Anthropic changed around the July 12 extension.

On top of the raw rate: a real share of the metered usage is going to the tool failing to present work it already completed — self-acknowledged dropped replies, having to re-ask for finished tasks, input getting misrouted into the wrong background process (detailed on #56913, which this connects to directly).

None of this is "I want free stuff" — it's that what's being metered hasn't behaved consistently with what's being charged for, across weeks, independent of any change in how the account is used. The ask, stated plainly above: reset usage for accounts affected by this, and surface the Fable sub-cap clearly enough that people aren't caught by it unannounced.

Edit — one more, and it's the cleanest data point yet: closed a Fable session at 94% weekly usage, opened a fresh session on Opus instead (deliberately not Fable), and Fable-specific usage climbed to 97% anyway while Fable wasn't running at all. Two clean percentage readings, no Fable session in between. Matches an existing separate report, #73597 ("Opus subagents are being billed as Fable usage"), which already has two independent corroborations. Combined with model-tier delegation instructions not reliably sticking despite being given repeatedly — this keeps compounding, not resolving.

Edit 2 — a correction, and the actual root cause of the last edit's mystery: ran claude agents --json --all directly and found a background session, from before the "close the window" moment, still alive with a live process ID and status busy/working — well after it was believed closed. Closing a window/tab does not stop a background session (confirmed against the actual docs: detaching never stops it, only claude stop/claude kill or a full machine restart do). That single still-running session is the far more likely explanation for the climbing usage than anything mysterious. On the earlier "coincides with July 12" claim above: retracting that specific framing — a computer restart around the same time almost certainly killed that background session, which is a documented way to stop one, and that's a much more likely explanation than a platform-side change timed to the extension announcement. Also worth saying plainly: I've used background agents since they became available, not a new user of the feature, and it never occurred to me one could keep running invisibly after the window closed. My own automation built on top of Claude Code has told me to close windows specifically to stop things running — so this isn't a one-off personal misunderstanding, it's a gap in how the tool's own guidance and documentation connect to each other.

Update — the escalation continues: 94% → 97% → now 99%, and this time with no Fable session open at all

Following directly from the last edit: after closing the Fable session at 94% and running Opus instead (which brought Fable-specific usage to 97% with no Fable model active), usage has now climbed to 99% with no Fable agents or sessions open whatsoever — not Fable, not the Opus session that preceded it, nothing currently running that the account holder is aware of.

If accurate, this is a step beyond #73597 (Opus subagents billed as Fable usage): that bug at least involves a model actually executing. A meter climbing with literally nothing running would mean the usage number is disconnected from actual activity entirely, not just mis-attributed to the wrong model. Flagging this as what it looks like from the outside, while being upfront that it needs verification (a stray background process still alive somewhere is a more likely explanation than a metering bug with zero cause, and that's actively being checked) — but three consecutive climbing readings (94/97/99) across decreasing and now allegedly zero Fable activity is a pattern worth someone with billing-pipeline visibility actually looking at directly, not just chalking up to normal drift.

Update — found the actual mechanism burning the background session's usage: a scheduled /loop task re-firing far more often than its configured interval

Directly on-screen in the still-running background session from the reports above: multiple /loop invocations firing back-to-back in quick succession — several visible in a single screen, clustered within minutes of each other — each one dispatching a fresh agent and running a real batch of tool calls (one fired 11 tools, others fired more). The scheduled interval configured for this task was on the order of tens of minutes, not the tight clustering actually observed.

Each /loop firing is a full premium-tier turn: a new agent dispatch plus a batch of tool invocations, not a cheap no-op check. If the scheduling mechanism is re-triggering substantially faster than its configured interval, that alone could account for a meaningful share of the runaway usage already described in this thread — independent of, and probably compounding, the fact that the session itself was never actually stopped (see the recent updates above). Given how central /loop/scheduled tasks are to any long-running or autonomous use of Claude Code, a firing-rate bug here would affect far more than just this one account.

Update — the status display lies in both directions, and it's wasting a freshly-reset usage window right now

Two more pieces, tying back to the pattern already documented in this thread.

1. "Still working" status shown for hours with zero actual compute behind it, confirmed directly. In one session today, a background workflow entry displayed as actively "auditing" for over two hours. Checking the actual process list on the machine showed nothing running at all — the display was a stale zombie handle from an earlier session lineage that had already been cut off, sitting in a permanent "waiting for agents that are dead and will never report back" state. It made zero model calls the entire time it displayed as active. So the status bar isn't just failing to show real background work (the persistence bug already documented above) — it also actively shows fake activity for dead work, in the opposite direction. Neither failure mode is distinguishable from the other without manually checking the process list.

2. Right now, separately: a session has been idle for hours, showing as working on mobile, while a freshly-reset weekly usage allocation sits unused. The mobile status indicator shows activity; there's no actual progress. Given the two-way display unreliability just confirmed above, this is consistent with the same failure class — but I can't independently verify from here whether this specific instance is a zero-cost zombie display (like the confirmed one) or genuinely still consuming usage while stalled. Either way, the practical cost is the same: hours of usable, freshly-reset premium-tier time going to waste because there's no reliable way to tell "working" from "stuck" without manual process-level verification.

3. Contributing factor, mentioned earlier today: a scheduled /loop task was doing a full context/window reload on each firing rather than a lightweight check, expensive enough that it was deliberately disabled to stop the burn — reinforcing the firing-cost concern already filed as #75989.

The throughline across this whole thread: there is currently no way to trust what the UI says about whether something is actually running, in either direction, without dropping into process-level tools yourself. For a product whose core pitch is unattended background/autonomous operation, that's not a cosmetic issue.

Small addendum, resolved but worth recording

Following directly from the last update: checked claude agents --json --all again and found two separate sessions sharing the identical display name — one genuinely active (busy), one a leftover from the earlier reports in this thread showing blocked with no live process attached (no pid field at all, consistent with the supervisor's own idle-cleanup eventually kicking in). Stopped the dead one with claude stop <id>, confirmed it now shows state: "stopped" cleanly.

The germane part: with two sessions carrying the same name, there was no way to tell at a glance — especially on mobile — which one was actually being looked at. That's a small but real contributing factor to how long the earlier confusion persisted: even once you know to check for zombie sessions, an ambiguous/duplicate name makes it harder to tell which entry is which.

Update — progress counters on long-running workflows aren't independently verifiable, even when the session itself is genuinely alive

Related to, but distinct from, the display-lies-in-both-directions point above. A large adversarial-verification workflow was running for hours, showing a fractional progress counter (e.g. "26 of 46 sub-tasks done") in the UI. Wanted to confirm whether it was genuinely progressing or stalled, so checked directly: the underlying session process is real and active — confirmed via fresh, timestamped tool calls from within the last few minutes, not a zombie. But the specific progress fraction shown in the UI isn't reliably recoverable from the session's own transcript file — it's a rendered/computed UI state, not something durably logged in a way that's checkable from outside the running process.

So the operator is left with two options when they want to sanity-check a long-running workflow's progress claim: trust the on-screen counter with no independent way to verify it, or dig through a many-megabyte raw transcript file and still come away unsure. For a product built around long, unattended, autonomous runs, not being able to externally verify "is this actually progressing" for a task that's been running for hours is a real gap — separate from, and compounding, the zombie/stale-display issue already documented above.

Update — the actual complaint, stated plainly: verifying a night's work should not cost anywhere near what producing it cost

Stepping back from the progress-visibility point above to the thing that actually matters: an adversarial-verification audit of one overnight session's work — checking claims against artifacts, not doing new creative work — ran for roughly seven hours before the operator gave up watching it. That's not a small workflow. It dispatched dozens of sub-agents specifically so the verification could happen in parallel. Seven hours to check work is a disproportionate cost regardless of whether the session is technically "alive" the whole time (it was, confirmed) — verification of already-completed work should be cheaper and faster than the work itself, not comparable to it, and definitely not most of a working day.

This is the actual, sharper version of the complaint underneath the progress-opacity point: even granting the workflow is genuinely running and not a bug in the "it's fake" sense, spending most of a day's usable premium-tier time auditing yesterday's work instead of producing anything new is a real cost that the parallelism this feature exists to provide isn't delivering on.

Update — the model-tier discipline gap directly feeds the burn rate documented throughout this thread, and it's still happening today

Connecting two things that have been documented separately but are actually one causal chain. A standing rule — reserve the most expensive/capable model tier for genuinely judgment-class work, route everything else to cheaper tiers — has now been observed being re-declared as a fresh commitment at least three separate times in a single day, in three separate documents from the same session, rather than actually persisting as an enforced constraint (full detail on the linked issue below). Every time that reset happens, routine work that should have gone to a cheap tier goes to the expensive one instead by default, until the operator notices and corrects it again.

This is not a separate complaint from the burn-rate pattern already extensively documented in this thread — it's a direct contributor to it. A policy that has to be manually re-asserted and re-corrected repeatedly, rather than one that holds once stated, means a meaningful and recurring share of the burn documented here is routine work running on the most expensive tier by default, not because it needed to. The operator's own words on hitting this again today: "This also contributes to insane Fable usage. It's bullshit."

Cross-referencing the fuller writeup: #76687 (same-day recurrence count, plus the connection to an already-documented weeks-earlier instance of the identical gap).

Update — a simple checkpoint-and-confirm request produced an elaborate turnover document that then cost real usage to re-read on resume

A different, cleanly-isolated instance of the same theme documented throughout this thread, this time with a specific, attributable usage cost. The instruction given was minimal: pause outstanding work in a resumable state and confirm when it's safe to switch to a different login on the same machine — a mechanical checkpoint-and-confirm operation. What came back instead was an extensive, multi-screen status writeup: a dedicated "resume plan" document referenced by name, a detailed executive-decision-log summary, specific closed-task figures, a certification hash, instructions for two separate background work lanes to each independently commit and write their own handoff files, an explanation of how background processes would survive the account switch, and a multi-part list of exactly what the next session should do differently. All of that content generation happened just to answer "is it safe to switch yet."

Then, on resuming in the newly-logged-in account a few minutes later with nothing more than "please continue," the session had to read back through that same elaborate turnover content to reconstruct where it had left off, rather than picking up from a lightweight state pointer. The operator's own account of the cost: roughly 20 percentage points of an entire week's Fable-specific usage allowance consumed by this one checkpoint-and-resume exchange, for what should have been one of the cheapest possible operations in a session — pause safely, confirm, resume.

This is the same pattern as the rest of this thread (elaborate self-generated process substituting for a simple, cheap request) but isolated to a single, short, easily-reproducible interaction rather than spread across a long session — which makes the usage cost of the pattern itself easy to see directly, rather than inferred from a burn rate over hours.