PsychodeliGetting startedHelp

3 days with Fable · June 2026

The Fabled Nights

For a few days in June, the most capable model Anthropic ever made public reached into a complex, year-deep engine and reworked it in big, integrated pieces — the kind of deep change a year of late nights never made time for. Then it was pulled.

128 commits · 116 agents · 3 days on Fable 5

Open the live app ↗
0:00 hear it react
scroll

A field note on Claude Fable 5: for a few days the most capable public model reworked a year-deep music-visualizer side project in big, integrated changes by conducting parallel agents, then access was pulled — and on what that capability did and what losing it costs.

From directing to conducting.

On June 9th, 2026, Anthropic released Claude Fable 5, the most capable model it had ever made public. A federal directive pulled it back days later. For those who didn't get to run it, the delta wasn't just a smarter chat window—it was a shift in the unit of work. I’d spent a year turning a 90s screensaver into a music-analysis engine, chipping away in early mornings and late nights. Fable let me move from small, incremental tweaks to delegating high-level architectural goals. It excelled at sweeping, multi-file refactors, and most critically, enabled a strategic upgrade to the app's musical comprehension.

Instead of directing the engine one thread at a time, I was conducting. Fable fanned out parallel agents to audit the codebase, compile changes, and run tests. Over three days, it executed 128 commits across seven repositories. My own prompting pattern changed: conversations took half the usual prompt count, and terse, corrective prompts like "no" or "fix that" dropped from 25% of my interactions to under 14%. I was no longer micromanaging; I was setting the architecture in motion.

128
commits
+14,308
net lines
20
new modules
116
agents · 7 projects

The resulting code was cleaner, not messier. The core pattern recognizer—a 7,700-line monolith—barely grew (just a net +151 lines), while the new features clean-split into twenty distinct modules. The codebase maintainability scores actually improved relative to my year-long baseline. Here is how one of the hardest problems in the engine was solved in a single afternoon.

A model goes only as fast as it can check its own work.

This speed wasn't magic—it ran on a year of unglamorous testing infrastructure. A real-time, audio-reactive WebGL visualizer is notoriously difficult to verify: it's stochastic, visually complex, and driven by live sound. You can't manually review thousands of frames on every run, and there is no simple assertion for "does this pulse look right."

The solution was a "proving ground" of 1,500+ unit tests, a record-and-replay harness for live runs, and a headless synthetic music generator. Feeding calibrated tone probes directly into the analysis stack made verification deterministic. To test an engine designed to listen, I first had to build a way to feed it predictable sound.

This rigorous scaffolding gave Fable its safety rails. An autonomous agent can only refactor safely if it can grade its own output; without that, large-scale changes are just hallucinated guesses. The productivity spike was a model leveraging a test suite that flagged regressions in under ten seconds.

To play three voices, I needed three open lanes.

The visualizer maps sound to WebGL parameters. Because music is polyphonic—motifs inside phrases inside sections—the visuals should be too. I wanted three distinct visual voices playing at once: a slow camera breath for the section, a gradual swell for the phrase, and a fast pulse for the motif, rather than a single global variable flashing erratically.

In the old engine, parameter updates were "last-writer-wins"—fine for a single controller, but impossible if three voices wanted to drive the same value. To fix this, I needed an additive summing node (`modulate-add`) and a map of which parameter channels were actually free.

From contention to composition On the left, four sources collide into one parameter slot and the last writer wins. On the right, the same four sources sum through a modulate-add path so their offsets compose. Before: last writer wins After: offsets compose sweep governor turbo drift param 3 writes lost section phrase motif baseline Σ param
The enabling primitive: a modulate-add bypass in the parameter smoother. Before, every contributor landed in the same slot and clobbered the rest. After, contributors sum — voices can share a channel without erasing each other.

Finding those slots was the perfect task to delegate. Auditing parameter ownership across a 200-file codebase is a tedious weekend of search-and-replace. Instead, Fable spun up sixteen parallel subagents to trace the data flow. They audited the system and generated a clean map of open channels in 3 minutes and 48 seconds.

One workflow, fanned out A single prompt fans out to sixteen agents working in parallel, which converge into one synthesized answer: the free parameter channels for the three voices. 16 agents · in parallel 1 prompt param ownership 1 answer free channels
A real run: param-ownership-pass — 16 agents audited the parameter system in parallel, then synthesized one answer (the free channels for the three voices) in 3.8 minutes, 532 tool calls. This is the leverage: a day of reading, gone in an afternoon.

Once the summing logic was merged, we wired the three voices to their respective timescales. They now compose into a unified texture instead of clobbering one another.

Voice Extent Channel Path Shape
section 8–18 s postScale breath setTarget arc · ±12%
phrase 4–9 s tunnel swell modulate-add arc · 0–50%
motif 1.5–4.5 s tunnel pulse modulate-add fast-decay pulse
Three voices, one clock A section arc, phrase swells, and motif pulses all play concurrently on a shared time axis, summing into the visual. section phrase motif t₀one section ≈ 12 s
Each voice ticks, verifies against the live music, and aborts if the song diverges, then ramps home — three parts, like a rhythm section, summed into one image.

This design runs deeper than basic rhythms. When a song section repeats, the engine classifies the recurrence across six audio dimensions (chroma, chord degree, timbre, contour, texture, and presence) to identify *how* it's repeating—e.g., same notes but different instruments. This categorization laid the groundwork for a responsive visual language, compressing a weeks-long refactoring effort into a single afternoon.

The vocabulary it earned

Mint: compile a detected repeat into a persistent chunk once two instances align. Vamp guard: refuse to "recall" a unit you are still jamming on, 45-second gap required. Leitmotif: a recurring melodic identity; a per-speaker version gives every voice in a conversation its own visual signature. Epoch: a song boundary, where chunks from the previous song are demoted rather than deleted, so a track on loop re-homes cleanly. Anticipation: recognize the precursor cue and start the gesture on the section entry instead of lagging it.

A conductor is judged by the silences too.

The visualizer's most dramatic effect is the "inversion"—flipping the gravity vector to turn the entire coordinate space inside out. In the original code, this was triggered whenever a chaotic Lorenz signal (which drives the visualizer's idle, wandering motion) crossed zero on a beat, provided a cooldown timer had expired. While synced to the rhythm, it was blind to the larger musical context, sometimes flipping the camera on a stray snare hit during a quiet verse.

Now, inversions are managed like a currency budget. "Pressure" accumulates as the Lorenz drive crosses its sign threshold, but the engine only allows a "spend" during major structural events (like a drum drop or chorus transition), rather than just any isolated beat.

$$\text{raw} = \text{lorenzDrive}\cdot 0.18, \qquad \text{spend allowed} \iff P \ge \tau_{\text{swap}}=0.12 \;\wedge\; \text{rate} \le \tfrac{1}{30\text{s}}$$

We also built an escrow system for anticipation. If the engine detects a build, it can pre-arm a spend. If the musical drop lands, the inversion commits on the downbeat; if the song fakes out, the reservation is refunded and the rate-limiter resets. A false positive no longer ruins the visual pacing.

The pressure account Pressure rises as the chaotic drive crosses sign. A slam spends it. An anticipated drop escrows a reservation; if the drop never arrives the reservation is refunded. P time → τ swap threshold slam → spend escrow (anticipate) fizzle → refund
A pure reducer steps the account forward, step(state, frame) → {state, decisions[]}, so the whole thing replays from a recorded ring as a regression fixture. Spend the big gesture only when the music has earned it.

The visualizer watches you back.

The engine doesn't just listen; it also watches. Enabling the camera runs lightweight pose tracking for head tilt, body sway, and hand position, drawing a glowing outline called "the Familiar." Your physical movement becomes an active modulator—leaning physically tilts the WebGL viewport.

The Familiar — the engine's perception of you: a glowing face with tracked eyes and a bright green mouth mid-sing, a vocal ribbon trailing off, over the live visuals
The Familiar — the engine's read of you, in its own phosphor language. Tracked eyes; the mouth turns green and a ribbon unspools when you sing along.

However, direct mapping backfires: users tend to fight the music, bobbing their heads in ways that make the camera motion jerky and nauseating. To solve this, we implemented a confidence-based crossfade. Raw input drives the camera initially, but as the tracking registers a stable, beat-locked rhythm, the engine fades down the literal gain in favor of a learned smoothing layer. The camera still responds to your movement, but the inputs are filtered through the tempo grid once you establish a groove.

$$\underbrace{\{1.0,\ 0.3,\ 0.05\}}_{\text{literal gain}} \;\searrow\;\qquad\qquad\nearrow\; \underbrace{\{0,\ 0.35,\ 1.0\}}_{\text{learned layer}}$$
The confidence crossfade Across the three rungs, literal camera authority falls from 1.0 to 0.05 while the learned layer rises from 0 to 1.0, crossing in the middle. 1.0 0 OFFWHEELSASSISTEDENSEMBLE literal camera gain learned layer
Every gain crossfades on a 1.5-second time constant, about one bar at 160 BPM, never a snap: $g \mathrel{+}= (g_{\text{target}}-g)\,(1-e^{-\Delta t/\tau})$.

And then it was gone.

I am genuinely gutted that Fable is gone. Having a tool this capable yanked away overnight feels like a mess—plastered all over the news, but hitting hardest in the terminal. The code it wrote is still running on this page, locking onto drum loops and crossfading camera gains, but the partner that helped me design and ship it in three days is locked behind closed doors.

The real shift wasn't just speed; it was the ability to share a high-level goal, dialogue about the build strategy, and let the model conduct a system that writes and verifies its own PRs. You move from micromanaging to directing the overall execution.

But those loops don't run themselves. The hard truth is that if you aren't putting sustained effort into enabling the model—building the kind of robust, deterministic testing infrastructure I spent the last year scaffolding—you won't get the value, even with the next major tech upgrade. An LLM can only move as fast as your system can prove it isn't broken. Without that, you're just paying for faster hallucinations.

Turn on some music, enable your camera, and try the live app below. Let's see if you can feel the difference.

Built primarily on Claude Fable 5, June 9–11, 2026; public access pulled by federal directive.

Open the live app ↗ Read Inside the Math ↗