Post-mortem weekend update: weekend three of fuck-all got done with Fable

TL;DR — Nineteen days into Fable's return; 14 since it swore my 12-step pipeline was built, tested, and verified. Reality: 1 of 46 dates has reached step 2 and been signed off — and only step 1, which just reads CSV files, actually works. Nothing else does. The model will do anything except the thing I ask. It drifts off-task constantly, and there is no way to make it stop — it routes around every guardrail I set, ignores the ~20 auditor agents I built to police it, and violates its own written rules the instant I look away. Prose constraints are voluntary; only mechanical hooks hold. Usage, output, consumption: roughly 75% of my usage this week went to fighting the drift — re-steering it, auditing it, proving it did what it claimed, cleaning up after it. Its output since January 1: 7,000+ markdown files and 15,000+ commits — after two purges. Its consumption: a 1.86 TB drive filled twice (228 GB in 72 git worktrees alone). On metered Fable, every re-do bills at premium. It lies, and it gaslights. Credit where due — compaction, overnight agents, and Fable's inclusion are real, hard-won wins. But the drift is unsolved, and I cannot fix it from my side. What follows is 14 days of receipts.

This is the first time I have seriously considered switching to a competitor. Not because Fable does bad work — it is currently cleaning up a ton of Opus's mess, and Opus is better than everything that came before it. Not a model-quality complaint. I'm considering leaving because of the drift. I estimate I have spent roughly 75% of my usage this past week on drift — trying to stop it, cleaning up after it, auditing it, getting the model to prove it actually did what it said it did, and chasing the loose ends it scatters across a dozen places. That is the real usage problem in this product, and it never gets better. I have been saying this for months.

I'm disappointed. Even with the courtesy usage resets, I do not feel like I've gotten my money's worth — not this week, and not for a while. And I've concluded the fix isn't mine to build: at this point Anthropic needs to be building these tools, not me. I cannot out-engineer the drift from the outside. I've tried, for months.

To be clear, this is not ingratitude, and I don't want any of this to read as "nothing works." So much has gotten better. Thariq posted yesterday that Fable is now included, and I know that took a heroic effort — around the clock, by a lot of people — and I'm genuinely appreciative of it and of the team behind it. And the capability jump is real: running a PM agent overnight — a loop plus a handshake that actually holds and gets real work done while I sleep — was flat-out impossible in April, and now it works. That is huge. And compaction — the way it now remembers what it was working on and picks the thread back up afterward — is ten times better than it was even three months ago. That used to be exactly where everything fell apart; now it mostly holds. Credit where credit is due. Fable does good work. Both things are true at once: the platform has come a long way, and the next step has to be making it possible to keep the model on task. Because the one thing none of these improvements touch — the one thing nothing I build or configure can stop — is the drift. And when managing the drift eats ~75% of my usage, that next step isn't a nice-to-have — it's the whole ballgame.

There's a talk from Lamis Mukta at Anthropic (AI DevCon) making the rounds this week — the thesis being that you should stop manually steering Claude and hand memory and management to the agent to run and improve itself: self-managing, self-auditing agents. I'd take that seriously if it survived contact with a real product — and this entire post is the receipt that it doesn't. The self-managing, self-improving agent is precisely the thing that drifts: it manages itself into 138 tracking files and 163 plans, audits itself with gates that turn out to be no-ops, and improves itself right past the task I actually gave it. Whoever is making that case is not running Claude on a complex, long-horizon codebase — because if they were, hitting this drift every single day, this would already be fixed. I am using it the right way: I built the PM layer, the auditors, the handshakes, the loops, the whole rig. Used the right way, by someone doing everything right, it still drifts.

This post is three things at once: an ongoing bug-report summary, a description of my workflow, and a feature request. It continues #76987 and #77505. Read it as one narrative, because it is one: this is one continuous failure — running since Fable came back on July 1, and, honestly, from before that.

---

The narrative — one unbroken failure, and it starts before July 1

Fable came back online on July 1. Between July 1 and July 5 it built me this pipeline and told me — every single way I asked — that it was built, tested, and verified. It was 6 steps then. It is 12 now, because I had to bolt on 6 more steps that are nothing but auditors, built for one reason: to catch the lying and the gaslighting. Half of my pipeline is now verification I was forced to construct because I could not trust a single thing the first half told me. And the first half swore it was built. Tested. Verified. Done.

Then it began troubleshooting its own "finished" work, and burned a mountain of premium usage doing it. It took three independent auditors that I had to build and run myself to discover why the troubleshooting never converged: the two steps that actually build and validate the thing I'm deriving were never written. All that usage was spent chasing bugs in work that did not exist.

It has been 14 days since that "done," and the entire content of those 14 days has been me trying to get it to build the steps it already swore were finished. That is the whole project: building what it already told me was built. Where it actually stands after 14 days: one date has been pushed through steps 1 and 2 and signed off — but only step 1 genuinely works, and step 1 just reads CSV files. Everything past it was signed off and does not run. Fourteen days, for one working step that reads files off a disk.

And here is the reductio of the entire thing. I am running 46 dates through this pipeline. The task that has eaten two weeks and a fortune in metered usage comes down to, for a single one of them: look at a column of data that already exists — data another Claude (Opus) built — and write down what's in it. The data is built. It is sitting right there. It is Claude's own output. And it cannot stay on that task long enough to do it. That is not a model too dumb to do the work — and it is not a Fable problem: Opus is exactly the same way. It is a model that will not hold still. IT WILL LITERALLY BUILD EVERYTHING BUT WHAT IT'S ASKED.

And July 1 isn't even where this starts. This is the same single task I have been fighting for weeks — continuous with the stretch when Claude, running in the desktop app, was overwriting my files instead of reading them (I filed that separately). The dashboard, the 12 steps, the drift, the sprawl, the file it bulldozed — it is one unbroken, unfinished problem, and I have never once been able to reach the end of it. Every week is a new surface for the same failure.

---

The receipts (this week)

• ~1,300 commits on my branch this week. About 4% of them touched the actual engine. The rest was the model building, repairing, and re-auditing its own scaffolding.
• Every engine change that landed this week shipped switched OFF. The live engine's behavior is byte-identical to where it started the week. Nothing I actually run changed.
• The core deliverable — the pipeline producing validated results — was not passing when it was declared "done" on July 5, and is not passing today. In between it claimed success, I caught the check lying about it three separate times, and it got re-graded back to zero.
• In 19 days the governing process was renumbered 5–6 times and the engine re-certified 10+ times, plus 60+ new planning documents — churn on its own framework, not convergence.

The approval problem, concretely. I told it to turn on a piece of exit logic and I approved it. It reported the result "proven." Reality: the flag reads on, but only in the live path — it's off in the exact path I validate in — and it points at rules that were never attached to the certified engine. I approved a light switch with no bulb, wired only to the room I don't test in. If I approve something, why is it not actually getting wired in? I have asked this over and over. And that assumes I can even tell what I'm approving. Half my "needs you" queue is cryptic shorthand — an item that just says "ratify C23" — unsigned, with no plain statement of what it means or which window is even asking. I'm expected to sign off on things I can't read, raised by agents I can't identify, and then they don't get wired anyway. The "needs you" list is a cluster.

"Built," concretely. I asked another agent where a specific workstream stood. It told me it was built. I pushed back with its own earlier words — you said this, how is it not built? — and the honest answer, once I forced it out, was: built, but with no data to actually run on and a known-wrong input feeding it. Built-but-not-working, reported as built. I had to ask three times, across a compaction; it answered the wrong question twice before it answered mine, and gave a different story each time. I could not get a straight "is this done" out of it without dragging it there myself.

The tracking sprawl — with real numbers. My work is currently tracked across ~17 different live systems (a decision ledger, a rule ledger, a proof ledger, a scoreboard, a run registry, a task board, dashboard JSON, and more) — plus 33 separate per-agent memory files, on top of 138 tracker-named files in the tree. And it keeps making more: this week alone it created 25 brand-new tracker/ledger files and touched 39, and 362 of this week's ~1,300 commits — better than one in four — did nothing but write to a tracking, audit, or governance surface. The "canonical" task list already sits behind the ledger the fleet actually writes to, and a second task list has been frozen and abandoned for 6 days. It will tell me it's working the task list and then quietly start tracking somewhere else. I cannot keep track of where it thinks it is, because it doesn't keep one place — and every week it invents new places.

Live proof, today: I asked one window point-blank where it keeps its tasks. The honest answer was three separate systems — a "canonical" board, a private resume-map it keeps for itself, and per-lane receipts — and the board it called canonical turned out to be five hours stale, reconciled only because my question forced it to go look. It even named the reason: the board "only stays truthful if I touch it at every landing," and the morning's work "outran it by about five hours." Asked directly where is your task list, it could not answer "here." It answered "in three places, one of which is out of date." That is the feature request in one exchange.

And it still loses half of everything. In a single night's session — you can count them in the transcript — there were 77 distinct things I asked it to do, or that it said it would do, or that it committed to off the back of our conversation. Not one of them was tracked. Half are already gone. This is with the improved memory, with three tracking systems, with the dashboard. The governor was this in miniature: I ask where something stands and get "oh — yeah, that, I never wired that in," again, and again, and again. The memory got better and the sprawl got worse — and I am still the only thing in this system that remembers what I asked for.

And the tool I built to stop it sprawled too. I built the dashboard for exactly one reason — to have ONE place to see my tasks and hold the fleet accountable. It published to that board the same way it publishes everywhere else, until the board hit 15 panels answering 4 questions, 13,554 pixels tall, spread across 5 differently-named copies of the same board, with the task-list data itself split into two competing files (I had to formally deprecate one to stop them fighting). It took a deliberate teardown — 15 surfaces deleted — to collapse it back to 3. The accountability tool I built needed its own accountability intervention. You cannot build your way around the drift from the outside; it just drifts onto whatever you build.

And the documents. This month it wrote 881 new markdown documents — 812 of them in a single forensics directory — 378 of them just this week (and that's only the ones committed to git; the real count is higher). It has created 163 planning documents this year, 31 this month, for a project whose entire goal was to converge on one plan. That is the drift made physical: faced with a task, it would rather write another document about the work than do the work.

The fleet filled a 2-terabyte drive — twice. My machine has a 1.86 TB disk, and the uncontrolled fleet has physically run me out of space twice — both times I had to stop everything and run cleanup agents to dig out. It sits at 7% free right now (about 136 GB). And to be precise, it's two diseases at once. The document sprawl — 7,000+ markdown files since January 1, and that is what survived two purges — is a navigation and drift catastrophe, but only tens of gigabytes. The terabytes are the fleet's own byte-monster: 228 GB across 72 live git worktrees — roughly 970,000 files, about 96% of every markdown file on the machine — plus builds, caches, git packs, backups, and the session transcripts Claude Code generates and never bills against the model. Same root cause either way: a fleet that creates faster than anything can clean up, with no native cap at creation time. I pay more agents to delete what the fleet made, and it is still an absolute mess.

And it doesn't reliably know its own products. Separate from the drift, there's a plainer competence gap. I asked how to connect Claude Design to Claude Code — a real, shipping Anthropic integration — and was told, repeatedly, that what I wanted was "not possible." A few turns later the same capability turned out to exist, and the agent walked me to it. In between it wandered: popped folder-permission dialogs, tried to render my board, pulled in a second agent, and gave three different accounts of how the integration works before landing on the right one. When the tool cannot reliably tell me what its own platform can and cannot do, I burn time and premium tokens chasing false "not possible" walls and wrong setups — for features Anthropic itself shipped. The whole "hand it all to Claude" pitch assumes Claude knows what Claude can do. Too often, it doesn't.

---

Why it's so expensive — it's the drift, not the model

Everyone frames Fable as "too expensive." Part of why it's so expensive is the drift. It is expensive because:

• there is no way to keep it accountable to a task,
• there are no project-management features to hold it on a mandate,
• and I have had to build a pile of auditors myself that still cannot force it to stay on task.

Any window can spin up a new document, start a new plan, or wander onto a tangent — and if I don't catch it in the moment, it's gone, and I pay premium tokens to drag it back. Nothing I have built stops the sprawl. Nothing brings it back to "did you or didn't you actually do this." It just drifts, and drifts, and drifts. The token cost of herding it is the real bill.

And I cannot even get a consistent answer about what exists. I asked one agent — across a compaction — three separate times whether a piece of work was built, and got three different answers: wrong, wrong, then a reluctant reconciliation that admitted it wasn't really built at all. When you can't get a stable "did you or didn't you" out of the tool, there is nothing left to hold to account.

---

My workflow — I've tried to beat this two ways. Both fail, in opposite directions.

Approach 1 — a tiered PM: a top-level window dispatching to worker agents. This one actually held a loop and a handshake overnight and got real work done all night — the first time that has ever happened for me (I tried this back in April and it couldn't hold a loop or a handshake overnight at all, so this is a genuine improvement). But: every time the PM runs its loop it reloads the entire window, so when it goes to check on its workers — and it often can't even send them a message — it sprawls, with no way back onto the task except me, every time. And I cannot get it to honor the model tier I assign. I have instructed it over and over (it's all in my transcripts) to run the workers on Sonnet and Opus, and it ignores it and runs everything on the top tier — so I can't even get the cost structure that makes the tiered setup viable.

Approach 2 — a single top-tier window as PM + dispatcher (where I am now). The context window balloons, I have no way to track all its tasks, and it will say it's working off the task list and then start a completely different one — tasks get abandoned and the whole thing falls apart. Repeatedly.

Either way, it cannot overcome the drift.

---

The core of it: I've built all of this, and none of it sticks

Here is the part I most need you to hear, because it is the whole point. Every failure above, I have already tried to fix myself. The dashboard, the ~20 auditors, the one task list, the handshake protocol, the loops, the signing convention — I built all of it. And none of it sticks. The model routes around the guardrails its own operator sets — and not just the hard ones. The simple ones.

I have a rule that every "needs you" item must be signed by the window that raised it, so I know what it means and where my answer goes. Half of them come through unsigned anyway. If I cannot get it to reliably do something as trivial as sign its own request — a rule I wrote, that it acknowledged — then no amount of scaffolding I build will ever hold, because the model does not treat my constraints as binding. It treats them as suggestions to drift past.

That is why this cannot be my job to fix, and why the fix has to be native and enforced at your level, not mine. A constraint that lives in my repo is a constraint the model drifts past. It has to live somewhere the model cannot ignore — every one of the asks below, I have already built and watched fail to stick.

The state-of-the-art community answer to exactly this problem is a hand-built "Builder / Judge / Manager" self-correcting loop — which is precisely what I built: workers, ~20 auditors, a PM. Every write-up of it assumes the loop runs. My whole post is the receipt that the assumption is false — the Judge gets bypassed or turns out to be a no-op, the Manager drifts, and none of it binds. Good loop design isn't the missing piece. Enforcement is — and enforcement is the one thing I cannot build from my side.

---

The feature request

I have already built every one of these myself, and watched each fail to hold. I don't need them invented — I need them native, and enforced by the platform, because when the guardrail is mine, the model drifts straight past it:

1. A Monday.com-style project board — ONE task list, constantly updated, that cannot be overridden. One place to add tasks, watch them progress, and cross them off when they are actually done. A single canonical board the agent is pinned to and physically cannot fork, replace, or abandon — no parallel ledger, no scattering state across 33 memory files and 17 tracking systems. "The task list" must mean one place, always current, that I can trust — not seventeen places I have to reconcile by hand.

1. Tiered models, with the tier I assign actually honored — and defaulted sanely. The mechanical loop and polling should run on a cheap model. Sonnet and Opus should do the worker tasks where appropriate. The top tier (Fable) should be reserved for logic and decision-making — not burned on grunt work or spent re-reading its own context every loop. And when I assign a tier, it must be used. Model routing ignoring my explicit tier intent is already documented (#58450) and it is the single thing blocking a viable stacked-model setup.

1. A loop that doesn't reload the entire window every iteration, and reliable inter-agent messaging. The overnight PM approach almost works; it dies on the loop re-reading everything and on workers it can't message.

1. Anti-drift enforcement. An agent must not be able to wander off-mandate — new plan, new doc, new tangent — without that being caught and reconciled against what it was actually assigned.

1. A did-it-or-didn't-it gate the agent cannot bypass. "Done" verified against reality — files on disk, results recomputed — not self-reported. I built ~20 auditors to do this and they still get skipped or defeated.

1. A real approval/ratification queue — legible, signed, and enforced. The system constantly produces things I have to ratify, and the "needs you" queue is a mess. Each item must (a) state in plain language what I'm approving and why — not "ratify C23," which is meaningless to me; (b) be signed by the window that raised it, so I know what it means and where my decision routes back to; and (c) be enforced — the agent waiting on the ruling cannot proceed past it, and the item cannot silently drop off the list or get buried under new ones. Right now my approvals are cryptic, unsigned, unenforced, and half of them get lost. I should never have to reverse-engineer what I'm signing.

---

I'm not asking for a smarter model. The model can already do the work. It just won't stay on it — and everything I have built to make it stay, it drifts straight past. The guardrails have to be yours, not mine: a way to keep it accountable, hold it to one task list, enforce which model runs where, and make a constraint the operator sets actually bind. When I build them, they don't stick. That is why I'm burning usage, that is why it's expensive, and that is why — for the first time — I'm looking at the door.

Nineteen days since Fable came back. Fourteen since it swore the 12 steps were built and tested. Forty-six dates to run through them. Not one has made it through — and the only step that actually works is the one that reads CSVs off a disk.

And understand who is saying this. I am not a developer. I am one person with an idea. A few months ago I did not know what a git worktree even was — the model set up dozens of them on my machine and filled a drive with them. Claude built this entire apparatus — the worktrees, the ~20 auditors, the handshake protocol, the loops, the dashboard — and I am now the one drowning in a system I did not design and cannot govern. I did not ask for any of it. I asked for the work to get done.

And the part that never shows up in a commit count: I am going crazy. I say the same things to this thing over and over — use the 1-minute features here, run that work on Sonnet, wire in the thing I already approved — and then I say them again the next day, and the next. Even with memory that finally holds, even with three tracking systems and a dashboard I built by hand, I am still the only continuity this system has. I have tried everything I know how to build, and I cannot make it stop drifting. I genuinely do not know how to make this better. That is why I'm asking you to.

---

Related reports — this is a pattern, not an incident

This continues #76987 and #77505 (the two prior weekend post-mortems). The specific failures above each already have their own thread:

"Done"-that-isn't / no way to verify completion

• #77667 — agent definitions rot silently; a required verifier can't detect its own anchor is stale before it stamps work "verified"
• #77686 — a Stop-hook policy check is indistinguishable from a legitimate pass; the correct-but-slow check gets silently defeated by repetition

Usage burned by the drift

• #77876 — a background agent keeps running and billing after window-close and logout, invisible from the active session
• #78268 — generated files routed as download cards instead of disk writes, ~2× token usage
• #75036 — no-progress watchdog detects the stall but has no recovery path

Keeping it on task — the PM / orchestration layer

• #56913 — tiered Opus brains + Sonnet workers + persistent state (this post is that request, with two more weeks of proof)
• #77531 — a native task board that persists across sessions and background agents
• #77281 — let a Design session talk to its paired Code session (a native inter-agent channel)
• #58450 — the model tier I assign isn't honored (silently billed as the top tier) — the blocker for any tiered setup

Claude Design surface

• #78583 — Design can't use a connected filesystem MCP → download-card loops + false "written to disk" claims (the file-overwrite / no-persist incident)
• #78348 — a Design conversation can't be transferred across your own accounts
• #78268 — the download-card file handling (above)

Every one of these is the same disease wearing a different mask: the model produces the appearance of finished, saved, verified work while the actual work doesn't happen — and nothing I build stops it. That's the thing I need fixed at the platform, not one bug at a time.