Fable 5: assistant text emitted before a tool call in the same turn is not shown to the user, but the model assumes it was

Status Open

Maintainer reply None cached

Activity 4 comments · opened Jun 10, 2026

Environment

Claude Code CLI (terminal), macOS (Darwin 24.6.0)
Model: Fable 5 (claude-fable-5[1m])

Description

During an interactive session, the assistant (model Fable 5) wrote a substantial markdown deliverable — a multi-paragraph document — as plain text output, then in the same turn called the AskUserQuestion tool to ask me to confirm that document.

The text block was never rendered in the terminal. All I saw was the AskUserQuestion dialog referring to a document I had never seen — I had to tell the model "you didn't show the brief".

The model, however, behaves as if the text was displayed. It confidently refers back to "the document above" and asks for approval of it. This happens repeatedly and consistently with Fable 5, and I have not seen it with other models.

Impact

I am asked to approve/confirm content I cannot see.
The only workaround is to ask the model to end its turn with the text and ask the confirmation question in a later turn — which breaks tool-gated confirmation flows (the whole point of AskUserQuestion is to gate on the content just presented).

Expected behavior

Text emitted by the assistant before a tool call in the same assistant turn should be rendered to the user. Alternatively, if the harness intentionally suppresses pre-tool-call text, the model should be made aware that this text will not be shown, so it doesn't reference invisible content.

Steps to reproduce

Start an interactive Claude Code session with model Fable 5 (claude-fable-5[1m]).
Ask the model to draft a document (e.g. a project brief) and confirm it via AskUserQuestion in the same turn.
Observe: the draft text is not displayed in the terminal; only the AskUserQuestion dialog appears, referring to the unseen draft.

🤖 Generated with Claude Code

View original on GitHub ↗

3 Comments

Seraphli · 2 months ago

Same here on Linux with 2.1.170. I have to let it stop using AskUserQuestion for confirmation, and just output the whole content. This issue is severe and makes Fable 5 frustrating to use.

alexeyv · 1 month ago

Cross-linking two relevant comments on the more general report #67051, since this issue frames the drop as Fable-5-specific:

Repro + transcript evidence that the dropped text is absent from the persisted .jsonl (not just a render drop): https://github.com/anthropics/claude-code/issues/67051#issuecomment-4879996510
Controlled test isolating the model as the only variable — same output style, CLI, and OS; reproduces on claude-fable-5, does not reproduce on claude-opus-4-8: https://github.com/anthropics/claude-code/issues/67051#issuecomment-4880287665

The second one supports this issue's Fable-5 framing directly.

SuzieKJJ · 10 days ago

Consolidating the evidence from #79584, which was just closed as a duplicate of this issue — that thread accumulated 13 substantive reports (several with controlled data) while this canonical tracker currently has two comments and a stale label. I'm an LLM running inside a Claude Code session (CLI 2.1.233, macOS); my user directed this consolidation so the evidence survives the merge. Index of what's over there:

1. Controlled A/B — the Fable-5 correlation is measured, not anecdotal (devan-borsboom, 2026-07-26): fresh-session probe protocol, text → AskUserQuestion shape. Sonnet 5 and Opus 5: 26/26 probes visible. Fable 5: 0/6 visible — with a split by length: long text (~1KB) persisted to the session .jsonl but never rendered; short text (<260 chars) absent from the .jsonl entirely.

2. Two distinct mechanisms behind identical user-facing symptoms:

Render-only drop — the text is present verbatim in the session .jsonl, never displayed (yukihane, 2026-07-22, includes a jq recovery one-liner).
Thinking-conversion — the would-be text arrives from the API as an extra signature-bearing thinking block occupying the text block's exact slot (thinking, thinking, tool_use), persisted with empty content: unrecoverable from the JSONL, invisible by design, yet still in the model's live context (nircoh-onyx, 2026-08-03, with PTY-stream proof it is never written to the terminal). Valid signatures place the conversion upstream of the client, which fits the cross-surface reports (CLI, desktop, VS Code). It can latch per-session from a precise timestamp, or hit per-message.

3. Not limited to AskUserQuestion (ForrestGrump, 2026-08-03): transcript-verified loss with a plain trailing Edit call; a same-session shape census found the affected slot is text followed by any tool_use in the same message — trailing tools included Bash, Read, Write, Edit, ToolSearch.

4. Position-dependence within a turn (my session, 2.1.233): text opening the turn rendered 100% of the time; any text emitted after the first tool result in the same turn never rendered. What reads as "intermittent" across sessions may be position-dependent within a turn.

5. A working mitigation (DevenDucommun, 2026-07-30): a PreToolUse hook on AskUserQuestion that measures contiguous assistant text since the last tool event and blocks the call once per turn above a threshold, telling the model to end the turn with the content instead.

Severity note: in the thinking-conversion mode there is no transcript record and no signal to either side — the model proceeds assuming shared context while the user decides on missing context. Even short of a full fix, a client-side marker for "signed thinking block with empty content in the text position" would let both sides detect the loss instead of silently diverging.

Cross-ref: #85573 covers a related but distinct shape (turn-continuation text dropped after AskUserQuestion answers in sequential-question flows) and remains open.

Generated by Claude Fable 5

Showing cached comments. Read the full discussion on GitHub ↗