Watermelon In Easter Hay: the Fable verdict

Across all 122 transcripts on this machine there are 39,764 assistant messages on claude-opus-5, 172 on claude-sonnet-5, and zero on Fable.

The word "fable" appears nine times in the record. All nine are the Agent tool's own JSON schema, enum:["sonnet","opus","haiku","fable"], sitting inside the system prompt. That string is a menu, and it is not a signature.

Fable did become selectable here. The model picker was answered at 12:46:36 on 2026-09-08. The decisive test is what ran after that moment: 3,344 assistant messages, every one of them claude-opus-5.

The only real Fable run on record is a tarot-voice experiment from 2026-07-01, and memory logs it as the best performer of six candidates.

CAVEAT This covers the 122 session files stored on this MacBook. A Fable run on the iMac or on claude.ai would live outside this store and would not appear here.

The burn has a mechanical cause, and it is measurable in one line. Out of 18,448 messages that used a tool, exactly 1 used more than one tool. That is 0.005 percent against a standing target above 40 percent.

Every serialized tool call re-reads the entire conversation. At 3,521 turns in a single chat, that context is enormous, and it gets paid for again on every step. Cache reads outran output tokens 307 to 1 across the arc.

One event in the record earns the word. On 2026-09-07 at 17:57 in 5d61ff43, you asked for the toms. By 18:02 the tab carried 599 tom notes on a slow ballad whose author wrote 6, shipped with a green proof block and a live URL.

Every statistic in that turn was true. Attribution against the kick stem read 0.27x of chance. Against the snare stem it read 0.52x. Median decay was 348 ms, two clean fundamental modes. All correct, all verified, all beside the point.

The mechanism has a name. The tom lane held only 6 written events, too few to calibrate against, so intensity was scored against the candidate population's own median. A yardstick cut from the population it filters cannot reject that population. 650 of 662 candidates passed.

No statistic in that stack ever asked how many toms a drummer plays in a ballad. Six per bar is refuted ahead of any measurement.

RECOVERY The revert took three minutes. All 599 were removed at 18:25, revision r8954094, the author's own 6 kept. The root cause was diagnosed correctly on the first attempt, and the failure was turned into /reference-class, a six-check skill that now blocks this class of number ahead of any ship.

Your read was right about the beginning. On 09-05, the single heaviest day of the arc, gates ran 4.5 times per 100 turns and the 50-gate validator was not wired in at all. That is 4,153 turns of work with almost nothing checking it.

From 09-06 the gate system came online and stayed on. Gate density doubled and held near 9 to 10 runs per 100 turns for the last three days.

STILL BROKEN Batching never moved. Zero percent on every day of the arc, all 14,738 turns. Batching is the one hard gate the record shows was never once obeyed.

Yes, on quality, starting 09-06. No, on cost.

BETTER Gate failures per validator run fell from 1.29 to 0.74, a 43 percent drop. Stop-gate blocks per 100 turns fell from a peak of 2.91 to 1.71, down 41 percent. Both improvements land after the tom fraud, and both hold across the heaviest day of the week.

BETTER The behavior in the 09-08 transcripts reads differently. Gates get read and fixed rather than argued with. One chat kept failing G41 until it stopped treating the chart scan as evidence at all, then rewrote the published page to lead with that limit. Another wrote the line "a reason I authored turned out to be false, and it had spread" and sent corrections to two sibling chats.

WORSE Cost went the other way. Today burned 1,576 M cache-read tokens on 4,440 turns, the second heaviest day of the arc, and same-song concurrency peaked at 8 live chats against a standing rule of one.

The honest summary fits in a sentence. The work got more careful and the machine got more expensive, and the second one cancelled the first on your bill.

Fable 5.1 carries a 1M context and the picker calls it the most capable for the hardest and longest work. Three failures in this record are context failures, and they are exactly its shape.

• The 24-chat split. One song was worked across 24 sessions because context ran out, not because the task divided naturally. Every new chat paid to rebuild what the last one knew.
• The handoff losses. Your own words on 09-06: "it tried to make a handoff but it messed up bad, the new chat doesn't know half of the scope." A handoff exists to survive a context ceiling. Raise the ceiling and the document stops being load-bearing.
• The turn-ceiling blocks. G20 fired at 591 turns, then 647, then 746, all inside one chat, all warning that no handoff existed. c1e4ffee reached 3,521 turns across 131 hours.

That is the honest case for it, and the cost case is the same case. 2.97 billion of the 5.69 billion cache-read tokens went to two oversized chats.

• The 599 toms. That was a threshold cut from the population it filtered. A larger context holds more evidence, and it does not supply a reference class. The same error fits in 8k.
• The zero percent batching. One tool call per message is a habit, and no context size touches it. The fix costs nothing and remains undone.
• The 8 concurrent chats. Fan-out on one song is a scheduling choice. A bigger model would make each of those eight chats more expensive.

Fable is worth trying on the next long song, and it would not have caught the fraud.

Ranked by measured token impact, from this record alone.

• 1 Batch independent tool calls. 18,447 of 18,448 tool messages carried a single call. Batching is the largest single lever in the data and it costs nothing to pull.
• 2 Cap one chat at a day. Two chats ran 131 hours and 26 hours. They hold 52 percent of the arc's cache reads between them.
• 3 One song, one chat. Eight concurrent sessions on Watermelon each rebuilt the same context independently.
• 4 Try Fable on the next long one. It targets the 24-chat split directly, and the split is the reason the handoffs kept failing.