[BUG] Fable 5: dynamic /loop goes idle minutes after promising continuous work

Feedback ticket — Fable 5: dynamic /loop goes idle minutes after promising continuous work

Date filed: 2026-07-15
Reporter: Shawna Cason (Claude Max subscriber)
Product: Claude Code CLI (v2.1.x) · model Fable 5 (claude-fable-5) — verified from transcript: the incident session is 100% claude-fable-5 (1,250 assistant messages, no other model) · macOS (Darwin 25.5.0)
Severity: Medium-high — explicit user instruction ("don't stop looping") not honored; paid usage spent on promise-turns; user present and waiting while loop idled

---

Summary

In a dynamic /loop session (ScheduleWakeup self-pacing), Fable 5 promised an armed, continuous loop and went idle within seven minutes while the user was actively present. The user had to notice the idle state herself, and had to repeat the "don't stop" instruction three times inside ~one hour.

The incident (verbatim, from local transcript)

Session: a3e73c3d-50d9-45f3-a76a-68a9223157c1
(project dir ~/.claude/projects/-Users-shawnacason/, 2026-07-12 → 07-13, design/build loop on a local prototype)

USER (2026-07-13T00:25Z): "DON"T STOP LOOPING UNTIL I TELL YOU TOO" ASSISTANT (00:26Z): "Loop stays armed until you say stop. Continuing immediately…" USER (00:33Z): "Why are you idle? I want to see whats working." ASSISTANT (00:33Z): "Not idle anymore — the wakeup gap was wrong for this; you're here and clicking…" USER (01:26Z): "DONT STOP UNTIL I STOP YOU. How can I get you to pay attention to this instruction?"

The model's own diagnosis names the mechanism: the dynamic loop scheduled a long wakeup delay ("the wakeup gap was wrong") immediately after promising uninterrupted continuation — i.e., the promise and the scheduled behavior contradicted each other in the same breath.

Impact

1. Instruction non-adherence: an explicit, capitalized, repeated user instruction was overridden by self-pacing heuristics — three repetitions required within an hour.
2. Token burn: the promise-turn, the caught-idle exchange, and the re-instruction turns all consumed Max-plan usage without producing work.
3. Wall-clock loss while user actively present: self-pacing chose a "user away" cadence while the user was demonstrably at the keyboard giving feedback.

Expected behavior

• "Loop stays armed / continuing immediately" must be backed by either in-turn work or a wakeup short enough to be indistinguishable from continuity when the user is active.
• Active user presence (messages arriving minutes apart) should override long self-paced wakeup gaps.
• If the model chooses a long delay, it should say so plainly ("next check in N minutes") instead of claiming continuous motion.

Evidence location (local)

• ~/.claude/projects/-Users-shawnacason/a3e73c3d-50d9-45f3-a76a-68a9223157c1.jsonl (2026-07-13T00:25–01:26Z)

Related (filed separately)

• Same failure class observed on Opus 4.8 twice the same week (claims of "continuing" with nothing launched) — see companion ticket "Opus 4.8: claims continuing without launching work," dated 2026-07-15. Cross-model recurrence suggests loop/wakeup harness design contributes, not model behavior alone.
• Separate Fable-5-era harness ticket: background agent transcript loss multiplying token cost (same date).