[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
- Instruction non-adherence: an explicit, capitalized, repeated user instruction was overridden by self-pacing heuristics — three repetitions required within an hour.
- Token burn: the promise-turn, the caught-idle exchange, and the re-instruction turns all consumed Max-plan usage without producing work.
- 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).
3 Comments
Companion ticket (same reporter, same week, same failure class on Opus 4.8): https://github.com/anthropics/claude-code/issues/77728 — cross-model recurrence suggests the loop/wakeup harness design contributes, not model behavior alone.
Clarification on evidence: the
~/.claude/projects/...jsonlpaths listed are on the reporter's local machine and not accessible to Anthropic. For server-side correlation, use the session UUIDs + UTC timestamps quoted in the report (reporter is a Claude Max subscriber; an in-product /bug report referencing this issue number has also been filed from the same account). Full local transcript excerpts available on request.Retested on v2.1.220 today. Two of the three expected behaviors have landed. The third has not, and I want to narrow this issue to it.
What is fixed
Both fixes are in the contract rather than left to the model, which is the right place for them.
ScheduleWakeup'sreasonparameter is now documented as shown back to the user, explicitly so that "the user reads this to understand what you're doing without having to predict your cadence in advance." That is expected behavior 3.The
/loopskill now requires the delay to be stated in text before the tool is called, and states that re-arming is "a per-turn choice, not a default." The promise-and-contradict-in-the-same-breath failure in the original report is now much harder to produce silently.A bounded two-iteration dynamic loop today fired at 13:45:07 against a 13:45:00 target and stopped cleanly on request.
What is not fixed
Expected behavior 2, active user presence overriding long self-paced gaps, is absent, and current guidance biases against it.
ScheduleWakeupdocuments: "Idle ticks with no specific signal to watch: default to 1200s-1800s (20-30 min)."Nothing anywhere conditions that on whether the user is present. In my test I chose the 60 second floor because I judged the user was at the keyboard waiting. No instruction produced that choice. A session following the documented default, with the user sitting there watching, would pick twenty minutes and be correct by the guidance.
That is the original incident. The user was demonstrably active, sending messages minutes apart, and self-pacing chose an away cadence.
The narrowed ask
Presence should be an input to the delay decision. Concretely, any of:
ScheduleWakeupthat recent user messages shorten the fallback, with the 20-30 minute default explicitly scoped to unattended operation.Scope
Retested on Opus 5, not Fable 5, so the model-specific half of the original report is untested. The test was also two iterations over one minute against an original incident of roughly an hour, and my task was explicitly bounded, so it never faced the open-ended choice that produced the failure. I am reporting the contract changes, which are model-independent, not claiming the Fable 5 behavior is resolved.
Happy to retitle this to the presence-override ask if a maintainer prefers, since the current title points at a symptom that is now partly addressed.