For months I had a backlog of work I kept walking past: a sweeping refactor of how my swamp models call each other, a fleet-wide cleanup of agent configs that had drifted into chaos, security hardening that always felt too big to begin, and a slow-motion datastore degradation that had already eaten a few Opus sessions. Two weeks with Fable 5, and every one of those is now either done or genuinely moving.
Some context, because the mess was mine. My automation lives across a tangle of interdependent repos I built up over months — a watcher fleet on launchd, a PR feed, test runners, task routing — all writing to a shared S3 datastore in my homelab. I let that datastore grow a monolithic index of roughly 95MB, which meant every write from every watcher paid to sync the whole thing. Add a global write lock and a residential uplink and you get the failure I eventually walked in on: four wedged processes, one of them stuck for nearly ten hours, holding the lock while everything behind it starved. None of that is swamp's fault in any interesting sense. I stacked the hay; the needle was inevitable.
Where Opus stalled, Fable held
I want to be careful with the claim, because Opus 4.8 still does most of my daily work and its commit trailers interleave with Fable's in the same repos, same weeks. But I had two problems where Opus sessions visibly churned and gave up — a stuck browser-QA mystery, and this datastore degradation. The handoff notes from those sessions read like a tired coworker at the end of a shift.
I pushed Fable to orchestrate from the very first prompt — deliberately, because I'd watched Opus fail to delegate consistently. That failure is one of the reasons my ADW pipeline exists at all: Ruby code imposing the orchestration from the outside, because the model wouldn't hold the shape on its own. Fable held the shape. It ran the datastore investigation as an orchestrator — five subagents fanned out across machines and repos for about four and a half hours — and came back with one coherent picture instead of a pile of threads. The watcher fleet was mostly dark: 18 of 21 launchd jobs had never come back after a reboot. The "phantom" duplicate S3 keys I'd been shrugging at were real, caused by a polluted local cache that made every push double-write. And the monolithic index re-upload was blowing a request timeout on my uplink, turning every push into an eleven-minute ordeal.
What came out of it was architecture, not a patch. Latency-sensitive pollers now write to a local filesystem datastore — a quick isolation test showed the same write committing in about a second locally versus minutes over S3 — and the shared store became a cold warehouse, touched only by harvest and reporting jobs. Pushes went from eleven minutes to under two. Where duct tape was still needed, it went on with tripwires: a watchdog that kills wedged processes and releases orphaned locks, plus alert-only checks for cache pollution. Alert-only on purpose — an auto-purge racing a live sync could delete real data, and I'd rather get paged than clever.
The upstream loop
The part I'm most pleased with involved no code of mine at all. When the investigation bottomed out in swamp internals, the sessions didn't route around the problems — they wrote reproducible bug reports and filed them upstream, four in total, one of them filed by the agent entirely on its own after it caught a redundant re-upload during verification. The swamp maintainers were extremely responsive; fixes shipped within days, sometimes hours. The wins were measurable — a no-op harvest that used to take over two minutes now takes about thirteen seconds.
The same loop ran during the chaining refactor. Swamp shipped context.runModel() — models invoking other models in-process instead of nested CLI shellouts — and Fable converted four of my extensions to use it, keeping the old shellout only as a fallback on pre-execution errors, so a child LLM call can never accidentally fire twice. Along the way it proved empirically that per-method arguments weren't reaching the child model, validated the bug two different ways, traced it to the exact merge in the source, and filed it. Fixed within a day.
Agent finds bug, agent writes reproduction, maintainer ships fix, agent re-verifies the fix against our own stack — not because the fix is suspect, but because "fixed upstream" and "working in my environment" are two different claims. That is the healthiest open-source feedback loop I've been part of in a while, and half the participants weren't human.
The discipline that felt genuinely new: the docs now carry a patch retirement ledger. While the duct tape went on, we wrote down exactly which pieces to peel off once upstream landed. The watchdog and the hot/cold split stay — they're permanent architecture. The scheduling workarounds get demoted to a footnote. Knowing what to retire turns out to be a different skill than knowing what to build.
Swarms and tiers
The config cleanup was the purest test of the orchestrator shape. I asked Fable to audit every skill and command across my agent setup, using subagents, and to do none of the work itself. It ran two parallel sessions of 23 subagents each and surfaced things I would never have found by hand: a plugin manifest where 41 of 43 referenced paths were dead, and a skill file that had been silently clobbered with leftover agent chatter — the kind of corruption my sync script would have happily propagated everywhere.
The tiering pattern itself predates Fable. I'd already been running Opus subagents for evaluation and Sonnet subagents for implementation, with a separate verifier checking each unit before it counts as done. But that pattern kept needing hand-holding — I was the one re-verifying the verifiers. With Fable steering, it holds together on its own: Opus evaluates, Sonnet implements, a verifier checks, and Fable re-checks the verifier's claims against the actual tree. It's static config now, not vibes — my commands pin opus for adversarial review, sonnet for patches, haiku for commits.
Security, honestly
The hardening effort is in progress, not done. What shipped: prompt-injection defense in my PR watcher — untrusted PR text gets sanitized (hidden characters stripped, image URLs defanged so they can't exfiltrate data) and fenced in untrusted-data tags before it touches a prompt. Four hardening units, built by the tiered pattern in isolated worktrees, all waiting on my review. What exists only as a researched plan: proper sandboxing for the headless CLI fleet. I've been burned being clever here before — a previous hook-based attempt spawned recursive agents on every tool call and torched my usage limits — so I'm moving slowly on purpose.
And the humbling one, which the audit caught: a toolProfile: "readonly" parameter I'd shipped in a caller does nothing. The extension's schema has no such field, so it's silently dropped. A security feature that isn't. Fixed on a branch now, but nobody — me included — noticed until a swarm went looking.
Not everything is a Fable-class problem
My experience has led me to more or less the same conclusions IndyDevDan lays out in "Claude Fable 5 BANNED: The First Model Agentic Engineers DON'T NEED". Three of his findings match mine almost exactly. Judge the model by price per intelligent agent hour, not price per token — in his fifteen-app benchmark Fable cost about twice what Opus did in tokens, but finished roughly 20% faster, and time is the scarce resource. Fable is not an intern, it's an orchestrator — it performs like a principal engineer and shines when it delegates. And it's the first model most engineers don't need: Opus gets you 85–90% of it on most tasks, so if your problems aren't complex enough, don't pay to play. Build a stack instead.
His line "the more ambitious the instruction, the better the result" matches too. Every win above came from a big scary ask — audit the whole fleet, fix the datastore across every machine, redo how all the models chain. When I hand Fable a small task, I'm mostly paying extra for what Sonnet would have done fine.
So my stack settles out like this: Sonnet and Haiku for the work, Opus for the thinking, Fable for the missions. The missions were the projects I'd stopped starting. That's what changed.