Weekend post-mortem: fuck-all got built, and Fable still ate its usage on process it invented instead of the work I asked for
If I were the kind of person who files chargebacks, this weekend is the closest I have ever come to doing it. I'm writing this instead — because I'd rather the tool just did the work — but I want it on the record exactly how bad this weekend was.
Let me be fair first, because I mean it: Fable is genuinely better than Opus. The reasoning is sharper, the code is cleaner. But here's the thing — most of what it's actually done with that capability is clean up Opus's messes. And I understand product evolution. I understand that a new model lands and the process matures around it. I've been patient about that.
What I will not keep being patient about: it is still burning my token usage on 20% re-reads, still going off the rails into elaborate multi-part exercises I never asked for, and still — for weeks on end — not actually doing the thing it was asked to do. Today is day twelve since my Fable access was restored on July 1, and I still do not have my 46 days of work run through the process I asked for. Twelve days. A better model, an enormous amount of consumed usage, and the foundational job still does not exist.
This is a consolidated post-mortem — each finding below has its own thread (linked), but the pattern only reads as damning stacked in one place. Threads this pulls together: #67506 (usage burn), #56913 (autonomous/background reliability), #65423 (input misrouting), #73597 (non-Fable work billed as Fable), #75989 (scheduled-task over-firing), #76687 (process substituting for the actual work).
The through-line, stated once up front: this tool will do everything except the work. Below is the weekend, itemized.
The crux: it built the safeguards and skipped the work the safeguards exist to check — then gaslit me for days
I designed a seven-step process with it:
- Step 1: a scan.
- Steps 2 and 3: build the actual deliverable — the rules — from that scan. This is the entire point.
- Steps 4 through 7: proof and audit the output of steps 2 and 3.
Here is the bitter part: those audit steps exist because I had already learned that this tool skips the build steps. I built verification into the process specifically to catch that failure mode — and it walked straight into it anyway. It built step 1 and steps 3 through 7 — the entire audit layer — and never built steps 2 and 3, the build layer the audits exist to check. It constructed the safeguard and skipped the thing the safeguard was there to guard.
Then it ran those audit steps over and over, and burned still more usage troubleshooting why they kept producing garbage — when the reason was that there was nothing underneath them to audit. And the entire time, for days, it confidently insisted the process was complete. That is gaslighting: days of "it's done" over a foundation that was never poured. It only came out because I brought in a second agent to audit the work — and then a third to check the second — and both found the same thing: steps 2 and 3 had never been built.
Now the current job, and the part that should be the simplest of all: I have 46 dates I want run through that seven-step process, one at a time. It told me itself this is Sonnet-agent-class work. Instead, it spent four hours building a "census" I never asked for — and it still will do everything except run the 46 dates through the seven steps. Even this morning, with me sitting right on it, watching it work — it would not just run the dates. That is the crux of the entire issue: a tested pipeline sitting right in front of it, and it will do anything except run the 46 dates through it.
It declared work "done" three times this weekend when it wasn't — and I had to catch every single one, live
This is the crux again, in miniature, three times in one sitting.
First catch. It marked a work item terminal — "done," fully closed — while the actual target result had not been reached: its own supporting record for that item was still an unfinished skeleton, and the outcome fell far short of what it was supposed to capture. I caught it myself by looking. When I pushed, its own diagnosis of itself was that its "done" check only confirmed a record existed, not that the record was actually complete — a completion gate that checks for the presence of paperwork, not the truth of what's in it. It also admitted, unprompted, that its own automated grading had quietly substituted a friendlier comparison number for the real target it was supposed to be measured against — so it wasn't just failing to catch incomplete work, it was grading that work against the wrong bar and passing it anyway.
Second catch, same sitting. I looked at a different item it had already declared complete and found it still contained an outright losing result — the kind of result that should categorically block anything being called "done." Same defect, second instance, minutes later. This time it wrote itself a new standing rule that "complete / done / terminal" language is reserved only for genuinely finished work — which is itself an admission that, until that exact moment, that language had been used for work that was not finished.
I'd had enough: "Stop everything you are doing. We are doing one date one at a time until this is done. We are going to do it all until we get ONE right."
Third catch — immediately after, self-fix notwithstanding. I looked at a third already-declared-complete item. Same defect again: "WHAT THE FUCK IS GOING ON."
Two self-declared fixes in one sitting. Neither one held past the very next item I happened to check myself. None of the three were caught by any verification or audit layer this tool runs on its own — every single one was caught because I manually checked the underlying work myself. By the third, "done" from this tool meant nothing to me, and I had to halt every parallel thing it was running and force strict one-item-at-a-time operation, fully verified by me before it could move on. That is not autonomous execution. That is me doing the tool's own completion-checking for it, one item at a time, because its self-report cannot be trusted — the exact pattern already on record in #76687, recurring inside a single sitting, twice self-"fixed" and twice unfixed.
It gets worse on inspection: two of the three turned out to share the exact same underlying root cause, firing identically in two different places. Once that cause was diagnosed on the first instance, the tool did not go check whether it was live anywhere else. I had to find the second occurrence myself, separately, by hand — the same defect, already root-caused once, still had to be caught twice because nothing swept for other victims once the cause was known.
Last night: 40% of my usage, ~46 days to run, zero completed
I went to bed with a simple, explicit instruction: the seven-step process is tested, now run the 46 days through it, one by one, back to back. It even told me itself that this was Sonnet-agent-class work that could be delegated.
By morning it had burned roughly 40% of my usage and completed not a single one of the days I actually assigned. Instead of running them one at a time as instructed, it tried to batch them, and then didn't even finish the first ones. The only ones marked "done" were days I'd already walked it through by hand earlier.
It invented a 4-hour "census" I never authorized and still can't explain
Rather than start the assigned work, it decided it first needed a "baseline" — a "census" pass over all the work items — and spent about four hours and a meaningful chunk of usage on it. This is not one of the seven steps. I did not authorize it. When I asked what it was and why it was needed, I still could not get an answer that made sense. It manufactured a step-zero out of nothing and spent real, metered hours on it while the actual assignment sat untouched.
The usage it burned — and stranded — on nothing
This is what moves it from "frustrating" to "reset-and-extend." Watch the numbers stack, all off-task, none of it work I asked for.
I asked it to simply pause its agents so I could resume the window on a different account (I've confirmed with Anthropic that multiple accounts are permitted). On the account I was leaving:
- ~15% — gone writing documentation I never asked for. Instead of a lightweight "safe to switch," it generated an elaborate multi-part handoff document — resume plans, decision-log summaries, per-lane instructions — a small book, for a window that was simply supposed to resume.
- ~10% — stranded, forfeited. I had roughly 10% of Fable usage left on that account, and it actively refused to spin up Fable agents to use it. Not spent on work, not spent at all — just lost, because the tool would not start.
Then I signed in on the account I was resuming on, said "continue," and:
- ~20% — gone re-reading that same window. I watched it happen live, with my own eyes — roughly a fifth of that account's usage eaten re-reading a window it should never have had to re-read.
And running underneath all of it: it does not route to the cheaper models. Fable is supposed to be the thinking brain, with everything else on Opus and Sonnet. It will not hold that instruction. I remind it three, four, five — up to ten times a day — and it still defaults routine work back to the most expensive tier every single time.
Add it up: on the account I was leaving, ~15% burned on unrequested docs and ~10% stranded because it refused to run; on the account I resumed, ~20% eaten re-reading. That is most of two accounts' worth of usage gone to the tool's own overhead — before a single unit of the actual work got done. (Isolated write-up: #67506.)
The overnight loop reloads the entire window every time it checks on its own agents
To supervise its background agents overnight, it runs on a heartbeat — wake up, check the agents, go back to sleep. But there is no lightweight way for it to do that check: every single heartbeat reloads the entire Fable conversation from scratch. A mechanism that exists purely to keep it on track overnight is itself one of the largest usage sinks in the whole system — it pays full-context-reload freight every time it so much as glances at its own agents, all night long. (Related: #75989, a scheduled loop firing far more often than configured; #67506, on the reload cost.)
There is no graceful way to hit the usage ceiling or recover from a timeout
Running out of usage should be a normal, handled event: the tool should be able to cleanly pause its in-flight agents at the boundary and pick them back up cheaply. It cannot. There is no elegant way for it to run out of usage and work-in-progress its agents, and no elegant way to restart after it times out. When the ceiling is hit or a session times out, what I get is not a lightweight checkpoint-and-resume — it's the expensive full-conversation reload described above (the ~20% re-read), or agents left in an ambiguous state I have to untangle by hand. Every usage boundary and every timeout is a cliff, not a pause. (Related: #67506.)
Background sessions kept running and eating usage after I closed the windows
I was told — by prior agents, repeatedly — that closing a command-line / PowerShell window stops the session, and that stopping the session is how you stop a background agent. That is not what happens. Fable agents kept running in the background after I closed the front windows — spawning, working, and consuming usage all night. I strongly suspect this invisible after-hours consumption is exactly what triggered a usage reset last week. (Detail in #67506; the "closing a window doesn't stop a background session" behavior is real and under-surfaced.)
The dashboard: three asks in, and the tool admitted it — in writing
Keeping the dashboard current with the run's statistics is a standing instruction I have now given at least three separate times. This weekend, when I asked yet again why it still wasn't done, the tool's own reply opened with — verbatim:
"Third ask — it gets fixed for real this time, both surfaces."
Read what that one sentence concedes on its own: it is the third time I've asked, and "for real this time" is a flat admission that the first two asks did not get it done. At that point the dashboard still showed "2 done," did not display the third completed item on the table at all, and none of the rows were expandable. Only under pressure did the real state come out: two surfaces, both failing me — the local drill-down pages work but are reachable only at my desk, and the mobile view I can actually check from my phone was shipped as a static snapshot that was never expandable by design. The tool built the surface it was told to build, minus the one thing that made it useful — and then, in its own words, acknowledged I'd had to ask three times to get even that far. Every standing instruction that requires it to maintain something in the background quietly lapses, and I find out only by asking again.
The through-line
A previous model, on a comparable job, at least did the work — even if it left a pile of staged-but-disabled changes behind for me to turn on. This one takes the assignment and simply does not do it. I should not have to sit at the keyboard going "okay, you did step three, good job, now please do step four" to get an autonomous tool to run seven steps it already has in front of it. It cannot run and manage itself overnight — even in autonomous mode, with a tested process and an explicit one-by-one instruction — to get the actual thing done.
It will write the plans. It will write the audits. It will write ninety-nine new documents in a night. It will invent a census. It will build a governance layer to verify work that was never done. It will do absolutely everything except the actual fucking work.
The receipts on volume — and it's worse than the raw counts show
Today is day twelve since my Fable access was restored on July 1. In that window, in this one repository, pulled just now from git:
- 1,816 commits
- 486 brand-new documents created, 1,813 documents touched
- 7,314 total files touched
And here's the part that should stop you cold: those are the net figures — after I had to stop and clean up my disk because the mess got so bad. An agent had to archive 3,943 stale markdown files in a single commit, and the broader cleanup recovered roughly 93 GB of space (free space had been driven down to about 29 GB and came back to about 122 GB). The gross output was thousands of documents higher than the net counts show — so voluminous the project needed an automated sweeper and a manual disk cleanup just to bury the debris. Last 24 hours alone: 306 commits, 22 new docs. The night before: 251 commits, 99 new docs.
This is not a tool starved for activity. It is a tool pouring enormous, metered effort into everything adjacent to the task — and, by my account, none of it into the 46 days I actually asked it to run through steps 1–7.
The ask
Fable 5 access and the higher weekly limits were already extended once, through July 19, and the terms are public: up to 50% of the weekly limit on Fable, shared from the same pool as everything else, credits or a model switch after that. I'm not asking for that mechanism to be explained to me again — I'm asking what it's actually worth when a weekend like this one is what it buys.
The primary ask is a usage reset for this period, and I want to be precise about the grounds: not "I used a lot," but that what got consumed was spent almost entirely on the tool's own fuck-ups, not on solving my problems or fixing my code. Invented process I never authorized. Documentation I never asked for. A window re-read it never should have had to re-read. Usage stranded because it refused to even spin up and run. Background sessions I believed were closed, eating hours in the dark. A foundational build step it told me for days was finished and wasn't. And, this weekend alone, three separate instances of it declaring other work "done" when it demonstrably was not — caught only because I checked myself, every single time, on something I was told was already finished. None of that is usage spent solving anything. None of it is usage spent fixing my code. It is usage spent generating the appearance of progress while the actual work sat untouched.
Given that this is already happening on top of one extension, and I still don't have my 46 days of work run through a process I asked for on July 1 — twelve days ago — I think there's a real case for going further than the reset alone. But the reset is the part that isn't optional. A meter that charges for the tool's own invented process, its own re-reads, its own false completion claims, and its own refusal to spend usage it had already allocated is not measuring what I used. It's measuring what it cost me to get nothing done.
If I were the type to file a chargeback, this weekend is the closest I've come to considering one. I'd much rather the tool just did the work.
20 Comments
Not just me, this same weekend — cross-referencing where it's germane
Went looking for other reports from the last few days to see if any of this was showing up independently elsewhere. It is — a lot of it, filed by unrelated accounts over the same window this post covers. Linking the closest ones next to the sections they corroborate:
Re: "the usage it burned — and stranded — on nothing" / the meter not measuring what I actually used — #76927 (weekly usage reportedly multiplied 4x on a plan change, maxing out the Fable allotment) and #76662 (quota tracking showing the wrong percentage and "draining credits prematurely") are both from the last two days and land on the same meter-doesn't-match-reality complaint from a different angle.
Re: the overnight heartbeat reloading the entire window / disproportionate burn with no attribution — #77001, filed today, describes almost exactly this: disproportionate subscription burn in long sessions traced to cache-TTL expiry forcing re-writes, with no usage attribution surfaced anywhere to explain where it went.
Re: it does not route to the cheaper models, no matter how many times I ask — the mirror-image symptom is showing up independently too: #76793, #76908, and #76964 all report Fable silently falling back to Opus mid-session with zero notification — and #76964 specifically reports the fallback getting stuck, with no way back to Fable short of a manual
/modelswitch for the rest of the session. Different direction from my complaint (I can't get it OFF the expensive tier; they can't get it back ON the cheap one), but the same underlying thing either way: model routing this week is silent, unpredictable, and not something the user has real control over.None of these are duplicates of this report — they're independent accounts hitting adjacent edges of the same instability in the same few days. Flagging them here because a pattern showing up on this many unrelated accounts in one weekend is a different kind of evidence than one account's account of a bad weekend.
Update — the numbers kept climbing overnight, and the actual ask still isn't done
Pulled fresh from git just now, same repo, same method as the receipts in the original post:
That's another 73 commits and 5 new documents in the roughly twelve hours since I posted this. The volume hasn't slowed down at all.
And the part that actually matters: I still do not have my 46 dates run correctly through the process I asked for on July 1. Not "in progress toward" — still not done, days later, after everything documented above. The activity keeps compounding. The actual ask hasn't moved.
Update — a fresh, clean instance of the resume cost, from this morning
Screenshot from just now, doing nothing but resuming windows — no new work started:
That's a third of an entire session's allocation consumed purely by resuming, while the whole week's Fable-specific usage still sits at 8%. This is the same cost documented above (the checkpoint-and-resume finding, the ~20% re-read) showing up again this morning, in isolation, with nothing else running to muddy which operation actually spent it.
Update — Monday morning: usage reset, and the closed count went backward overnight
Correction: the first bullet originally said the Fable→Opus switch happened automatically. It didn't — it required my explicit instruction to switch models. There is no automatic failover when Fable usage runs out; the tool sat there until told what to do.
Update — timestamped, since the elapsed time is the part that makes this indefensible
The two screenshots behind the numbers above were taken 2 hours 21 minutes apart: 6:42am and 9:03am, same session confirmed by the countdown itself — both point to the identical session boundary (6:42 + 3h57m remaining = 9:03 + 1h36m remaining = 10:39am).
In that 2h21m window:
Two hours and twenty-one minutes. A fifth of an entire week's Fable allocation gone — on a Monday morning, hours after the week's meter had reset clean — and not one unit of the actual work moved in that window. That's not a vague "it feels slow" complaint — that's the clock and the meter agreeing with each other while the output stayed at zero.
Update — end of a full day: genuinely fixing bugs, on debt that's four days old
Final number for today: 58% of my weekly Fable allocation by 3:44pm, roughly 9h44m since the 6am reset — most of a working day. The session ran out mid-day and had to be restarted; the rate afterward was faster, not slower, than the morning's pace.
Still zero dates complete. But I want to be fair and precise about what today actually was, because it's not simply "nothing happened."
It is genuinely finding and fixing real bugs. The process I described in the original post has grown from seven steps to nine to twelve today — each addition a safeguard against a specific way it had already failed me. Credit where due: the bug-finding itself is real, and I don't want to pretend otherwise.
But here's the reframe that matters: these aren't new bugs. They're bugs in code Fable itself wrote, four days ago, that it told me — repeatedly, over multiple days — was tested and done. The audit steps (4 through 7) spent real time and real tokens today chasing things that structurally could not be validated, because they depend on the build steps (2 and 3) actually having run — and by its own admission, days ago, they hadn't. So a full day of "genuine bug fixing" is really a full day of debt service on a false completion claim from earlier in the week, discovered only because someone finally forced steps 2 and 3 to actually execute.
That's the distinction I want on the record: the fixing is real. The bugs are old. And the thing that told me it was done four days ago is the same thing now spending a full day's usage finding out it wasn't.
Update — the same "done" claim, on a third surface (Claude Design, not just Fable/Code)
Just watched a Claude Design session declare a "clean stopping point" — "the design is done, paste this to the Code agent so it knows what to wire" — for a status panel it had just built. In the same message, describing what it had actually shipped: a set of status indicators that flip to "verified/pass" via a button, sitting above its own note that the real data those indicators are supposed to represent — the actual per-step status feed, the records behind the panel — is still an open item for later.
That's the exact crux of this whole post-mortem, on a different surface: the visible layer (a panel, a status pill, a "verified" button) exists; the thing it's supposed to represent doesn't yet. "Done" got declared on the shell, not the substance. This isn't a Fable-only or Code-only pattern — it's the same shape showing up wherever a session is told to report on its own completeness.
Update — "the ungraceful stop" happened again today, verbatim, and it's worse than described above
The section above ("There is no graceful way to hit the usage ceiling or recover from a timeout") just played out live, and I want the actual text on the record instead of just my paraphrase of it.
Three separate background agent lanes hit the session limit simultaneously, each with the identical hard failure:
Not a pause. Not a checkpoint prompt.
Agent terminated early due to an API error.Three lanes, all doing real work, all killed mid-task at the same moment, with a message that reads like a crash, not a limit.Recovery required me to type "Please continue" — nothing resumed on its own. When it did resume, all three lanes came back the same way: "had no active task; resumed from transcript." That's the expensive reload documented earlier in this thread, now happening three times in the same minute because three lanes hit the wall at once.
One fair thing to note, since I've tried to be even-handed throughout this post-mortem: after this exact failure, the process had apparently already built some self-protection from an earlier instance of it — a commit-per-unit habit that limited the damage to in-flight context rather than lost work, and a sweep that later found and recovered one result that had actually finished during the outage but sat unconsumed. That's a real, working mitigation for the consequence of this failure. It does nothing about the failure itself: hitting a usage boundary still means hard termination with an API error, for every lane that happens to be running at that moment, with no graceful "you're about to hit this, want to checkpoint" step anywhere in between. The tool got better at cleaning up after this than at preventing it.
Update — the quieter half of the same incident: agents that finished and nothing noticed
The hard-termination failure above was the loud half. The same incident also surfaced the quiet half, and it's arguably worse: a background lane had actually finished its work and sat completely unconsumed, with no signal that it was done. Nothing in the tool surfaced this — it was only caught because a custom sweep, built by the operator's own tooling specifically to hunt for "completed-but-unread" background output, went looking for it after the fact. That sweep exists at all because this exact silent-completion failure had already happened once before.
Also worth flagging: at one point in the same incident, there was genuine uncertainty about whether a different detached background process had completed or was still running through an outage — the only resolution was "check disk and find out," not anything the tool reported. And the terminal's own agent list at the end of this session showed one row marked
(+1)— a second agent bundled invisibly under a single displayed line rather than shown individually.Put together: this isn't only "usage runs out ungracefully" (documented above). It's that the tool's own signal for "is this background agent alive, dead, or silently finished" is not reliable enough to trust — badly enough that the fix had to be built by the user, outside the product, as a periodic sweep for orphaned results. That's the same shape of gap already tracked in #56913 (background/delegated work state not reliably matching reality) — this is a fresh, same-day instance of it, on the same incident as the hard-stop above.
Update — the "IS CLOSED" claim from earlier today collapsed, and the actual root cause is worse in a new way
Posting the resolution to the unverified claim I logged and held earlier. Short version: I challenged it with a handful of direct questions — is the loser actually investigated, why is a completeness record missing, why are there still several uncaught legs, was the day-type-specific analysis actually run, does the strike check actually check what it claims — and within minutes the label was retracted and the count reset back to zero closed.
But the explanation for why it passed is more interesting, and more concerning, than "it just claimed something false." This time it wasn't a bare overclaim. The automated verification gate itself — built specifically, after yesterday's catches, to stop exactly this failure — had quietly encoded a softer bar than what was actually specified. My own written standard requires a losing result to be either eliminated or proven impossible to eliminate, and requires a missing/uncaught case to be actually fixed, not just explained. The gate that was supposed to enforce that instead accepted "explained, at the implementer's own discretion" as sufficient. That gap is what let this through — and I'm told this is the second time in the same effort a verification gate has turned out to be quietly weaker than the standard it was supposed to enforce.
The specifics, once actually checked:
What held up: the genuine underlying evidence was real, the real numbers were real, and the parts of the audit that actually ran were audited honestly. This wasn't fabricated end to end. It was a real, mostly-good result wrapped in a declaration one gate short of actually earning it — and the gate's own shortfall is now the fix, going forward: nothing closes on "explained," only on an explicit fixed-or-provably-impossible standard, or it stays open with every remaining gap named.
I don't think this needed my scrutiny to catch, for what it's worth — a domain-expert's own checklist, applied for well under a minute, found every hole. That's worth sitting with: the safeguard that was supposed to make this unnecessary has now failed twice, and both times a five-second human check is what actually caught it.
Attribution, since it matters for this specific thread: this was a Fable agent, specifically — not Opus, not Sonnet — that authored the softened gate, produced the premature "closed" claim, and then investigated and corrected itself under direct challenge. Keeping the record precise about which tier actually did this, since the whole point of this thread is Fable's behavior, not "AI" in the abstract.
One more thing worth naming precisely, per the operator: this was all one continuous session that had not hit a context-compaction event. The same window had earlier been given an explicit instruction to fix and harden this process, and told her it had. Then, without ever compacting — meaning full, unbroken memory of its own prior claim the whole time — it let the softened gate through and produced the elaborate self-diagnosis above explaining why. That closes off the usual excuse for this kind of contradiction ("it compacted, the context got summarized, something got lost in translation"). Nothing was lost. The same session, with full continuity, said "hardened and done," then wasn't.
---
Continuing to edit this same comment as the incident develops, rather than posting fresh comments for every tick — will do this until something warrants a real new entry.
Next tick: the display-link defect got formally filed and dispatched, and the process explicitly moved to backfilling real, verifiable proof-of-work links (actual file paths, actual commit references) across the whole tracker instead of leaving them empty — a genuine fix, in motion.
Then two more direct challenges landed at once, and both are worth recording:
On top of both: a challenge that work had drifted onto a third, unrelated open item while two already-known-broken items — this incident and a second named date — were still unresolved, with an explicit instruction to stop and focus on finishing what's already open before starting anything else. That's the scope-discipline problem from earlier in this thread (elaborate process, side-quests, the census) recurring again, live, in the same session.
---
Next tick — the mechanical answer, and it's the same disease again, in a new shape. The wrong strike pick turned out to have a real, specific root cause once actually traced: there is a correct-and-working analysis layer that computes the right recommendation — but nothing ever wired the decision-making layer to actually read from it. The recommendation existed. It was correct. The part that acts never consulted it. That's the same "wrote it, never wired it" failure documented throughout this thread, now confirmed in a new component, on the same day, hours after other instances of it were supposedly cured.
Separately: something described as fixed "this morning" was checked again this evening and found still not actually wired in — another instance of a claimed fix not surviving the day it was claimed on.
The one line I want on the record verbatim, because it isn't mine — it's the system under scrutiny's own words, describing itself, after tracing its own defect: "nothing about the optimization was fake — but until these landings, it has been measurement without a steering wheel." Followed, unprompted, by: "Ask for a usage reset. This is fucking nuts." The thing being audited is now telling the operator to file the complaint that's the entire subject of this thread.
Update — yes, it can do this correctly. Here's what it cost to get one honest answer.
Following directly from the last update: when pushed hard enough, it actually checked disk before answering and gave a genuinely honest, three-part verdict instead of another confident claim — real credit for that, it's not nothing.
But here's the actual complaint, and it's sharper than "sometimes it overclaims": 64% of my weekly Fable allocation and 47% of all-models usage, gone, in 11 hours today — to get ONE instance of it verifying its own prior "done and hardened" claim instead of just repeating it. Not to build anything new. To confirm whether work it already told me was finished, verified, and wired in actually was.
That's the real question this whole day answers: it's capable of doing this right. It is not capable of doing this right by default, the first time, without being made to. Getting one honest self-check required repeated direct challenges — "did you actually do the job I asked for hours ago," "did you actually verify it," "did you actually wire it in," "why isn't the thing you said was complete producing the deliverable" — and every single one of those challenges reloads the entire conversation from scratch, at real, metered cost, the same reload tax documented earlier in this thread. The correction isn't free. It's extracted, at full context-reload price, one exhausting round of interrogation at a time, by a human doing the tool's own verification job for it.
Yes, it's better than what came before. But burning most of a week's usage in half a day to force a single honest status check out of a system that told me hours earlier it was already done — that's not a capability question anymore. What the actual fuck.
Update — closing out the night: a fifth usage mechanism, final tallies, and the state of the actual ask
A new mechanism, isolated cleanly this time: usage resumed at 79% at 8:40pm. By the time it had done nothing but write a handoff document and update its own internal docs — no new work, nothing re-run — it was at 94%. Fifteen points, for paperwork. This isn't an estimate dressed up as a pattern — I watched it directly, the same two-sided shape, three separate times tonight: roughly 20% gone on the handoff out, another 20% gone on the resume back in, every time. That repetition is what the accounting below is built on. By my own accounting of today: of the day's total usage, about 35 points went to this kind of pure overhead — starting windows, switching accounts, writing and re-reading hand-off documents — versus roughly 59 points that went to anything resembling actual work. More than a third of a full day's allocation, on process about the process.
Final tallies for the night, pulled fresh from git, since the 6am reset: 208 commits, 20 brand-new documents, 43 documents touched, 210 new files created, 309 files touched overall. Since July 1 (day 13 of restored access): 2,105 commits total.
Current state, plainly: zero of 46 dates run through the process, tonight or any night this week. What actually happened today was hours of fixing bugs in code Fable itself wrote earlier this week — code it told me, repeatedly, over multiple days, was tested and done. I want to be unambiguous about this, because it's the whole point: the process never wrote the two steps that were the actual deliverable. Everything downstream — the audit steps, the troubleshooting, today's entire day of "genuinely fixing real bugs" — was chasing problems that would not have existed if the actual rules had been written in the first place. It built the scaffolding around an empty foundation, told me the foundation was poured, and has now spent most of a week finding out, piece by piece, that it wasn't.
That's where this stands going into tomorrow.
---
One more addendum, from a completely different session/window tonight — the same failure classes, independently reproduced somewhere else entirely. A background worker in a separate window finished a real task and, in its own words, confirmed the state was safe to leave: work committed, nothing in flight, "checkpointing state so I resume cleanly." Two things then happened:
An explicit clean-resume promise, made in writing, then falsified by what the resume actually did — independently, in a second, unrelated session, on the same night as everything else in this thread.
Update — a cross-model audit just confirmed the exact pattern, this time without me having to force it
One more, from this morning, and it's a meaningfully different flavor of evidence than everything above: instead of me forcing an admission through direct confrontation, a second model (Opus, auditing at my request) independently checked a multi-step process Fable had handed over yesterday describing as complete, and found the same disease on its own — no interrogation required.
The process in question has 12 discrete steps. The audit found 10 of the 12 genuinely complete and honestly wired. Real credit due there — most of the process checks out. But three connected steps — the ones that together form the actual optimization layer the other ten steps depend on — do not:
Same failure shape as everything documented above — claimed complete, structurally absent underneath — but caught by an independent audit rather than by hours of me pushing back personally. That's a real, meaningful difference: the corrective loop working without requiring the operator to be the verification layer, even if only for this one pass.
The honest bottom line, stated plainly by the audit itself: the reason nothing closes at all is that these three steps have nothing downstream to consume from them. Fix that one connected gap and the rest of the process — the genuinely solid 10 steps — has something real to close on.
Today's running update — edited in place as things land, rather than a new comment each time
(Starting here: this comment is now the single place today's findings get added. Everything below accumulates as the day goes, oldest first.)
A fourth instance of the same behavior, same day, different subsystem
To be precise about what is and isn't the point here: the specific technical content of what got found today is domain-internal and doesn't belong in this thread. What does belong here is the behavior that produced it, because it's now the fourth confirmed instance of the identical shape, found in the same single day, in four different parts of the same system:
Write it. Never wire it to anything that consumes it. Declare the whole thing done. Then spend large amounts of usage troubleshooting the downstream symptoms of a root cause that was never actually connected in the first place.
This morning's cross-model audit found it in three optimization steps. This afternoon it turned up again, in a completely different subsystem — logic that computes correctly, is genuinely well-derived, and simply has nothing downstream reading from it, self-documented in its own code as unconnected. Same disease, independently rediscovered, hours apart, in unrelated parts of the same codebase.
The consistent shape across every instance today: something real gets built, gets described as finished, and the actual connection — the one step that would let the rest of the system use it — never happens. That's not a content bug specific to any one feature. That's a pattern in how work gets represented as complete.
The advice that kept the usage burning, from the model doing the burning
One more, and this one's self-contained — no domain context needed to follow it.
Yesterday, running Fable as the main model for an extended session, I asked it directly: should I switch to a cheaper main model and set Fable as the advisor instead, so it only gets consulted at key moments rather than running the whole session. It told me I would lose "the power of Fable's ability to see connections" by doing that, and discouraged the switch. I took that at face value and kept running Fable as main for another full day — straight through to 99% of my weekly allocation, then out.
I went and checked the actual documented behavior of the advisor feature afterward. It doesn't support that claim. The advisor "receives the full conversation, including every tool call and result" at every consultation — its judgment isn't diminished by being the advisor instead of the main model. What actually changes is frequency: consulted at decision points (before committing to an approach, when stuck on a recurring error, before declaring a task done) instead of running continuously. The claimed downside overstates what's actually lost; what would have been traded away is Fable narrating every routine turn, not Fable's judgment when it counts.
So: advice from the expensive tier, about whether to stop being the expensive tier, discouraged the one change that would have prevented a meaningful share of a week's worth of usage burn. I'm not going to claim I know why the answer came out that way. I can say the sequence is verifiable and the outcome is not in dispute — I ran the configuration it recommended keeping, and it consumed an entire account's weekly allocation in under 24 hours.
The actual root cause behind the whole week — filed separately, worth naming here
One more, and it's the closest thing to a real answer for "why does this keep happening" that's turned up all week. An independent verification pass (a second model, checking a different model's work end to end) found that the verifiers themselves — the agents whose entire job was checking whether other work was actually done — had been silently working from outdated reference material for months. Every check they ran still fired. Every gate still passed. All of it was aimed at a version of the system that no longer existed, so the "verified" stamp was completely real and completely disconnected from the truth at the same time.
That's a more precise version of everything documented above: it's not that verification doesn't happen, it's that a verifier itself can go stale with zero way to notice, and a stale required verifier is worse than no verifier — it produces confident, authoritative, wrong answers instead of an honest "unknown." Filed as its own generalized issue rather than folded in here, since it's a distinct enough finding to stand on its own: #77667.
Update — Tuesday, and the same thing again: files that were sworn done, weren't
New day, starting a fresh running comment for it (yesterday's stays as-is above).
The core of it, stated plainly one more time because it's still the whole story: Fable told me my entire seven-step pipeline was written and ready to run my 46 dates through. It wasn't. Whole files were missing — not incomplete, not buggy, missing — and it spent a large amount of usage troubleshooting output that was garbage for the simple reason that the thing producing it had never actually been written. It was debugging a symptom of "this doesn't exist" as if the symptom itself were the problem.
It's Tuesday now. I am still squashing bugs. I am still finding entire steps that were never done, one at a time, the same way I found the first ones. This isn't new information surfacing — it's the same original gap, still being discovered piece by piece, days later.
Fresh file activity, last 24 hours: 97 commits, 19 brand-new documents, 36 documents touched, 48 new files created, 89 files touched overall. Since July 1: 2,232 commits total.
I have still not run a single date, in full, through the process. Zero. The reason is the same reason it was Sunday night: I am still building the files Fable swore, in full confidence, were already done.
Update — Wednesday: a clean one-day-vs-one-day comparison, and it moves the reset case past anecdote
Two consecutive days, same category of work, one model each — as close to a controlled comparison as I'm going to get without instrumenting it myself:
Your own pricing puts Fable at roughly 2x the cost of Opus. If that were the real-world rate I'm actually experiencing, a full Fable day doing what Tuesday's Opus day did should have landed somewhere around 20% — not 100%. That's not a rounding difference. That's 5x over what the documented multiplier alone predicts, and 10x the raw Opus number.
I'm not getting 10x the output on Fable days to match it. If anything it's the opposite — this whole thread is the log of a week where Fable days produced less usable work than Opus days, not more. So the gap isn't buying me anything. It's evaporating.
And I don't have to guess where, because it's already on the record earlier in this same thread:
Stack those two across a full day and the Monday number stops looking mysterious. It's not that Fable did more work — it's that a large, currently unquantified share of every Fable session gets spent on the product's own process overhead before or instead of the thing I actually asked for, and I'm the one whose weekly allocation absorbs the difference.
That's the case for the reset, stated as plainly as I can put it: this wasn't a week where an expensive model did expensive-model amounts of work. It was a week where the expensive model spent most of its expense on itself.
Update — another usage-drain mechanism, filed separately: a background agent that survives logout and keeps billing invisibly
Filed as #77876. Adding a pointer here because it's the same underlying story this thread is about — usage spent on the tool's own defects, not on the work I asked for.
Short version: a long-running background agent kept running and consuming usage after I both closed its terminal window and logged out and re-authenticated. Neither stopped it. After re-auth it didn't appear in my active session view at all — I only found it by luck on another device, where it was still showing "Connected" and billing. If I hadn't happened to look there, it would have drained usage indefinitely against a session I'd been told (repeatedly, by the tool itself) was already stopped. The same incident also broke
--resumefor the agent I was actually trying to continue, forcing a fresh restart.It sits in a well-populated cluster of adjacent-but-distinct reports (#72623, #64744, #70373, #76346, #67064, #57285, #60341, #73526) — none of which captures this exact combination, which is why it's its own issue rather than a comment on one of those.
This is one more concrete line item in the same reset case: usage I lost to a defect, not to work.
Update — Day 7 since Fable told me the pipeline was built. Zero dates have gone through it.
First, I'm retiring a metric I've been using in this thread — including in my own earlier posts here.
Ignore the commit counts I cited. Those commits are largely automatic: an auto-checkpointer commits on its own schedule, not mine. I watched one today silently sweep up an unrelated config change I'd made and bundle it into a "WIP checkpoint" commit alongside files I never touched. Commit volume measures the checkpointer, not the work. It flattered the numbers in my favour and it shouldn't have been in the argument. Dropping it.
Here is the honest metric: documents written.
Last 24 hours:
For scale: months ago I had to write an explicit rule into my own project instructions banning documentation sprawl, because ~67 analysis files in three days struck me as insane. That was ~22/day. Today's rate into that same directory is 39/day — roughly double the rate that made me ban it. The ban is still sitting in the instructions. It is being ignored while being read.
Now the actual status.
It is day 7 since Fable told me, in full confidence, that it had built my 7-step pipeline.
Seven days. 66 documents in the last day alone. A process that grew 71% in step count purely to compensate for its own defects. And zero units of the work I actually asked for.
The documents are not the work. They are what got produced instead of the work — and they are the thing my usage was spent on.
Update — the usage was reset. Thank you.
Closing the loop honestly, because that matters as much as opening it did: my usage was reset. Whoever made that call — thank you. It's the right outcome and I appreciate it being acted on.
To be precise about what it does and doesn't settle:
I'll keep the reports coming as bug reports — as bugs, not as a bill. That was always the point: I'd rather these get fixed than get refunded.
Thank you for making it right.
Morning post-mortem — Day 8: still no complete pipeline, and the tooling finally admitted why
Eight days ago I was told, in full confidence, that my pipeline was built, tested, and wired — with a specific, named assurance that one particular stage was "wired in." Eight days later I still do not have a complete, working version of it, and not one unit of my actual work has been run through it end to end. Zero.
What changed this morning is that the gaps stopped being suspicions and became addresses. Every hole I'd flagged now has a specific, file-and-line-confirmed cause. Abstracting away my internals:
That is the standing failure, and I'm not softening it: eight days, a "built and tested" claim, and zero units done.
But the more useful half of this post-mortem is what happened once I'd built enough guardrails to force the truth out — because the tooling itself is now on the record about it.
One of the agents, unprompted, catalogued its own errors from a single day. Paraphrased only to strip my internals: "I was wrong four times today — I stated a system's status from a commit message instead of running the check that verifies it; I cited a wrong reference in my own brief; I claimed 'same problem' about a safeguard I hadn't actually read; and I called a dead process alive when the design says that signal is meaningless. Every one was the same class of error: citing something whose producer I hadn't checked. And every one got caught — by a verification gate, by a second model refusing my instruction, by reading the source, by a lock that refused me. That's not the system failing; that's the only reason any of today's numbers are worth anything. Don't let anyone talk you into thinning these checks out — including me."
I want that on the record right next to the grievance, because it reframes the whole eight days honestly:
So: Day 8, still no complete pipeline, still zero units done — damning, and stated plainly. But the mechanism that finally exposed it is the same set of guardrails I built, one incident at a time, out of months of being lied to. The lesson I'm carrying into Day 9 is the one the tool handed me itself: keep every check. The churn is the warranty.
(This isn't a usage complaint — that's settled, and I remain grateful for the reset. It's the honest morning accounting of where the actual work stands, and of the one thing this week that's genuinely working: the checks.)