Fable 5 model behavior: 16 min of silent tool calls, then AskUserQuestion about never-shared findings during incident response

I witnessed very similar behaviour within the last couple of hours: Claude Code CLI 2.1.170, Linux (but not headless), Fable 5 (the session started with Opus and I'd switched models mid-session, but the model switch is looking like a red herring now). Text emitted by the model was never shown to me, but tool calls and user questions were, so I was being asked questions with no context.

Luckily the messages were still in memory (but not in the session JSONL), so Claude was able to surface them for me during a later investigation. (Critically, there were no session resets and no compactions between the issues and the subsequent investigation. If I'd compacted or reset, I'm guessing that Claude wouldn't have been able to find those messages.)

Claude's own report of the incident is below the separator.

---

Bug report: assistant text blocks silently dropped from UI and transcript after mid-session /model switch

Environment

• Claude Code version: 2.1.170
• Platform: Linux 6.12.76-linuxkit (devcontainer), CLI terminal
• Models involved: session started on claude-opus-4-8[1m]; mid-session /model

switch to claude-fable-5 ("Set model to claude-fable-5 and saved as your default
for new sessions")

• Session: 6f42a875-dd33-4e08-99db-9aa926c5e15c, 2026-06-10 (UTC timestamps below)
• Transcript file: ~/.claude/projects/<project-dir>/6f42a875-dd33-4e08-99db-9aa926c5e15c.jsonl

Summary

For ~11 minutes immediately following a mid-session /model switch, every
assistant text content block was silently dropped from both the rendered UI and
the on-disk session transcript, while the thinking and tool_use blocks of the
same assistant turns were rendered/persisted normally. The model genuinely emitted
the text: the in-memory conversation history retained it (the assistant could later
quote its own "missing" messages verbatim, and subsequent turns built on their
content). The user saw only tool activity and bare AskUserQuestion permission
dialogs, with none of the surrounding prose — including the direct answer to a
question they had asked.

Text persistence resumed mid-flow, under the same model, with no user action at
the recovery boundary.

Timeline

| Time (UTC) | Event |
| --- | --- |
| 12:52:42 | Session running on claude-opus-4-8 — text blocks recorded normally (e.g. assistant text at 12:52:42 … 12:55:44) |
| ~13:24:00 | User runs /model → claude-fable-5, then sends a prompt (13:24:02) |
| 13:24:10 | First assistant record on claude-fable-5 (a tool_use[Read] of an image) — blackout begins |
| 13:24:02–13:35:02 | ~10 assistant prose messages emitted (per in-memory history) — none rendered, none in the jsonl. The thinking and tool_use blocks of these same turns ARE in the jsonl. Three AskUserQuestion dialogs in this window rendered as bare dialogs with no surrounding prose. |
| 13:35:02 | Assistant text records resume ("Now writing the new registry module:") — same model (claude-fable-5), mid-task, no user action at the boundary. Normal for the rest of the session. |

Secondary observation (possibly related backend instability, shortly after the
blackout ended): at ~13:42 a Bash tool call was refused with
*"claude-opus-4-8[1m] is temporarily unavailable, so auto mode cannot determine the
safety of Bash right now"* — a transient permission-classifier model outage.

Evidence

All from the session jsonl (each assistant content block is its own assistant
record in this file):

1. Exemplar turn (13:24:37): the in-memory history shows this turn as

text → tool_use → tool_use (a ~1,000-char reply transcribing a user-supplied
hand-drawn architecture diagram, followed by two Read calls). The jsonl records
for this turn: thinking, thinking, tool_use[Read], tool_use[Read] —
no text record at all.

1. **Raw-substring search for distinctive phrases from the dropped messages returns

zero hits** across every jsonl in the project transcript directory:

``
grep -c "the realizable version of your drawing" <session>.jsonl # 0
grep -c "Two decisions locked" <session>.jsonl # 0
grep -c "import surface shrinks" <session>.jsonl # 0
grep -c "All four decision points are settled" <session>.jsonl # 0
``

The only occurrences of any of the dropped text in the file are inside a later
assistant message (14:14:44) that quotes it during the investigation.

Reproducibility note: the zero-hit counts above were taken at investigation
time (~14:1x). The investigation and a subsequent verbatim replay of the lost
messages (~14:2x onward) have since scattered quotations of the dropped text
through the file (replay text, grep tool_use inputs/results, thinking blocks),
so these greps now return nonzero. To reproduce the finding, filter hits by
timestamp: no record earlier than 13:35:02 contains any of the dropped
prose; every hit lives in records from 14:14:44 onward. The structural evidence
is unchanged: the window 13:24:02–13:35:02 contains thinking and tool_use
records but not a single assistant text record.

1. Listing all assistant text records with timestamps shows a clean gap

12:55:44 → 13:35:02 (37 text records total in the session; every other stretch
of the session has prose at the expected cadence):

``python
# for each jsonl line: rec["type"]=="assistant" and any content block
# with type=="text" -> print timestamp + snippet
``

1. Model field correlation: scanning message.model across assistant records

shows exactly one change — claude-opus-4-8 → claude-fable-5 at 13:24:10, the
turn the blackout begins. The model does not change at 13:35:02 when text
recording recovers, so the dropped text is not an inherent property of the model;
it looks like a client-side render/persist path failure in the period following
the switch.

1. The model emitted the text. The harness's in-memory history (what is sent

back to the API on subsequent turns) retained all dropped messages: the assistant
later reproduced them verbatim, and decisions taken in the dropped prose carried
forward consistently into recorded turns. So the failure is downstream of the
API response: the text blocks were lost by the client's rendering and jsonl
persistence, but not by its conversation-state accumulation.

Impact

• The user experienced multi-turn silence: tool activity and three bare

AskUserQuestion dialogs with none of the connective reasoning, and never saw the
direct answer to a question they had asked ("can you read this image?").

• Permanent data loss on resume/compaction: the jsonl is the source of truth

for --resume and for context compaction. A session resumed from this file has
genuinely lost those ~10 messages — the only surviving copy was the live
process's in-memory state.

• Insidious failure mode: nothing errored. The session "worked" (tools ran,

questions appeared, work completed), so the loss is only discoverable by a user
noticing the conversation reads strangely.

Expected behavior

Either render+persist all content blocks of an assistant message, or — if a
streaming/decode failure makes a text block unrecoverable — surface an explicit
error marker in the UI and transcript rather than dropping it silently. The jsonl
and the in-memory history should never diverge on message content.

Reproduction (best guess)

Not reliably reproduced. Suggested attempt: long-running session with extended
thinking enabled → mid-session /model switch to a different model family → next
several turns mixing thinking + text + tool_use blocks (including AskUserQuestion).
Inspect whether the turns' text blocks reach the jsonl. The onset being exactly at
the switch and the recovery being mid-flow suggests a stateful failure in the
client's stream-handling for the first responses after a model change (text
following thinking blocks may be relevant: every dropped message's turn began with
thinking blocks).

Verification commands used

# which transcript contains a phrase the assistant believes it said:
grep -l "<distinctive phrase>" ~/.claude/projects/<project-dir>/*.jsonl

# list all assistant text blocks with timestamps (gap analysis), and
# track message.model changes across assistant records — see analysis
# scripts in the session itself (14:1x turns).

Related issues (checked before filing; none matches the full signature)

Searched open and closed issues in anthropics/claude-code for this signature
(text blocks dropped from both UI and transcript, sibling thinking/tool_use
blocks of the same turns intact, onset at a mid-session /model switch). No
duplicate found; nearest kin, possibly the same underlying render/persist family:

• #34708 (closed, stale) — responses generated but never rendered in

long/multi-session usage; recoverable by "asking Claude to repeat them" (i.e.
in-memory history retained them — same retention we observed). No
transcript-level analysis; macOS.

• #54411 (closed, stale) — response emitted but never rendered when context

compaction fires at the turn boundary; the compaction summary proves emission.

• #30623 (closed, stale, data-loss) — user messages missing from the JSONL

transcript; reported repeatedly and auto-closed without triage. The persistence
half of this failure family, user-side.

• #63269 (closed) — interleaved thinking + multi-tool turns corrupting a

thinking block; same turn shape as ours (every dropped-text turn here began
with thinking blocks and carried tool calls).

• #41992 (open) — text-block handling in the session JSONL corrupting resume.
• #48087 (open, docs) — mid-conversation /model switches acknowledged as a

special path (uncached full-history warning).

Note on attachments

The session jsonl contains private project content (internal code review /
evaluation work). Happy to provide targeted excerpts (record structure for the
blackout window, with text redacted where needed) rather than the full file.

Not stale. The same issue is still being frequently reported.

Looks like #65620 might be the first report of this Fable-related behaviour. Tellingly, there were no reports while Fable 5 was withdrawn, but since its re-availability I've seen at least one new report per day of similar behaviour. I've been linking them to this issue in the hope of getting enough thumbs up on the initial report that Anthropic notices, but maybe #65620 is a better dedupe target.

This has been happening for a whole month!!

This issue doesn't just affect AskUserQuestion, that is just where it is most apparent. It appears that every time Fable invokes a thinking -> message -> thinking -> tool call chain, the message is always silently dropped. In my analysis, 25% of ALL assistant messages were dropped by this bug. See my comment on #74260 for more context.

Yeah, I totally agree. I had noticed that Fable seems much less chatty than Opus and that would definitely explain why. But if they have to prioritize, for me the most important thing is the AskUserQuestion manifestation because that’s often where our skills emit what it is the question is about (e.g. a summary or plan).

Yeah, I totally agree. I had noticed that Fable seems much less chatty than Opus and that would definitely explain why. But if they have to prioritize, for me the most important thing is the AskUserQuestion manifestation because that’s often where our skills emit what it is the question is about (e.g. a summary or plan).

For sure, I agree. Thats the only reason I noticed it. I outlined a bandaid fix for that here, it seems to be working decently for me so far.

@dsbecker I provided a more robust bandaid fix here if you're interested:
https://github.com/anthropics/claude-code/issues/74260#issuecomment-4940349869

@jorgenswiderski I appreciate that, sadly my employer is on an enterprise subscription plan and we’ll lose Fable access at the end of the week anyway. So it becomes something of a moot point for me unless they pony up for some token usage. 😀

@jorgenswiderski Since we’ve been granted a reprieve for another week, I did wind up using your fix. Thanks for sharing!

Workaround until this is fixed: https://github.com/podlayer/message-drop-sentinel — a single-file MIT hook that detects the drop signature described here (adjacent thinking blocks where the text vanished) live at PostToolBatch/Stop and prompts the agent to restate the lost message while it still remembers it. Deterministic, no dependencies, designed to be deleted when this issue closes. Fuller notes on the detection and its limits are in the README and in the comment on #74260.

Update on the workaround posted above: v2.1 now addresses the exact experience this issue describes — long silent stretches where the agent believes it's been talking to you. After every tool batch the hook tells the agent how many of its messages actually got through, so it notices the loss during the work instead of never; and it gains a delivery channel that can't drop (echo "» message" re-emitted as a system notice — the content rides tool arguments, which the summarization mechanism doesn't touch). Installable as a plugin now: /plugin marketplace add podlayer/message-drop-sentinel

The message-drop-sentinel isn't perfect unfortunately, and the model still needs to be prompted to use it, despite the plugin. This issue has killed a lot of my productivity today, it's the right kind of infuriating and dangerous that it really deserves some attention

@danielrmay — v2.2 targets exactly that: the injected wording is now hard instruction (MUST/IF-THEN, verify the relay's delivered result), and malformed relay attempts draw an explicit warning instead of failing silently. If your sessions still under-act after a few days, a transcript snippet on our tracker would be gold.