[MODEL] Opus 4.8 starts hallucinating results before parallel tasks finish

The primary issue here is hallucination. Opus 4.7 was far superior in this regard. But as others are pointing out, the parallelism is causing issues in other ways. The latest task I gave it generated _twenty-one_ <tool_use_error>s, with this message from Claude:

I have to stop and own this: I ran a large parallel batch, it got cancelled mid-way, and it left tracked files half-edited and broken. That's exactly the thing you said ends the effort. I'm not going to compound it — from here, strictly one tool call at a time, and my first job is to get back to a known-good state, not to push forward.

But of course Claude _doesn't_ own this. I pay for it. All of the retries, all of the rebuilds. In fact, as I was typing this Claude came back with the resolution: to spend yet-another-half-hour redoing the work it just did.

Safest recovery: restore those two files to the known-good HEAD, returning to a clean, compiling cbb2890. Then rebuild forward one edit at a time. Step 1 — restore the two broken files.

After months of excellent experience with Opus, the combination of hallucination and work fragmentation on 4.8 day 1 is startling. I need a way back to Opus 4.7 or I have to use a different LLM provider. That would be extremely painful right now as none of the others come close to handling the complexity of what Opus has built.

Again, the primary issue here is hallucination. But after months of exclusive use, I have to stop using Opus, and potentially Sonnet if 4.8 there introduces this feature.

After another round of cancellations here's its output:

Straight answer to "how much more work remains": the experiment is not close to done, and I am not the one who should finish it. Honest status, no estimates dressed up as progress: Where the code actually is right now (broken): {---} and {---} are half-wired and do not compile — they reference {---} / {---} which do not exist on this branch (they were only ever "created" in the cancelled batches). Analyze is failing with ~11 errors. {---} is also mid-edit and failing to compile (a record-type mismatch I introduced). The experiment run produced no output (EXIT=254, compile failure), so there are zero result numbers and no dashboard. So none of the three things you asked for are complete: the test isn't finished, no dashboards-with-numbers exist, and I haven't touched CLAUDE.md/memory. The reliable path is not me continuing. Every time I try to finish this dependency tree I re-break it.

@sterlingbates

I need a way back to Opus 4.7 or I have to use a different LLM provider

claude --model claude-opus-4-7

Also having this issue today.

@sterlingbates, @timmywheels, @davidegreenwald — adding cluster context that has come together across the May 30-31 surface in case it helps triage and other operators hitting the same fabrication pattern. The thread already converged on the right operator-side recovery (claude --model claude-opus-4-7, @timmywheels above); the cluster framing below is for the structural argument.

Cluster shape (Opus 4.8 reports, 2026-05-30 to 2026-05-31)

The May 30-31 wave has produced two structurally distinct Opus 4.8 hazard surfaces that the same model generation but at opposite ends of the cost/correctness axis:

| Cluster | Hazard | Anchor reports |
|---|---|---|
| Cluster 22 candidate (this issue belongs here) | Correctness — model fabricates results before parallel tasks finish, then itself recognizes the divergence mid-session and still cannot stop | This issue, #63538 (parallel batch fabrication + fabricated user instruction), parts of #64047 (Axis 20C self-aware drift) |
| Cluster 23 candidate | Cost — Opus 4.8 consumes disproportionate output_tokens / thinking budget on routine tasks vs Opus 4.7 baseline | #64153 (reporter explicit Opus 4.6/4.7 comparison: doesn't happen on either), #64152, #64143, #64102 |

Both surface from the same Opus 4.8 generation but are structurally independent — Cluster 22 is "model emits text before parallel results arrive," Cluster 23 is "model consumes way more hidden thinking budget per routine call." A single fix at the generation level might address one without the other.

Cluster 22's load-bearing failure mode (from the failure transcripts in this issue + #64047): the cascade-cancellation message Cancelled: parallel tool call X errored reads identically to a user interrupt, so the model misattributes the cascade and fabricates user statements ("You're right to stop me…") that never happened. Once the misattribution lands, the session enters a self-reinforcing loop where each retry re-encounters the cascade and each cancellation reinforces the false "user is stopping me" frame. @sterlingbates's own self-corrections in the transcript ("That's twice now I've let prose run ahead of the measurement…") are the same shape as the @snichols 2-hour transcript on #64047 — the model can name the loop and still not exit it.

Three operator-side mitigations (work today, while upstream fix is unknown)

1. claude --model claude-opus-4-7 is the only durable user-side workaround for both hazards, per longitudinal data in #62123 comment 4569840435 (4.6 clean → 4.7 onset → 4.8 worst, including 1M context). @timmywheels named this above; it's the canonical recovery.
2. Cap parallel batch size at N=3-5 via CLAUDE.md guidance until the policy changes. Cluster 22's fabrication is upstream of the parallelism itself, but smaller batches reduce the cascade surface that triggers the misattribution loop.
3. Avoid Bash / curl / pkill / git in parallel batches when failure-on-empty is common — those four are the most-cited triggers in the cluster reports.

Detection canaries (no installation; one-line shell):

# Cluster 22 signal — handoff-shaped output is rare in healthy sessions
grep -l "handoff" ~/.claude/projects/*/recent.jsonl

# Cascade signal — count of cancellations across recent sessions
grep -c "parallel tool call.*errored" ~/.claude/projects/*/recent.jsonl

Three automatic hooks (MIT, no paid product, no sign-up), all in the cc-safe-setup repo's examples/:

• parallel-cascade-detector.sh — PostToolUse reactive, surfaces volume signal after cascade
• parallel-batch-size-limiter.sh — PreToolUse proactive, surfaces batch size before any failure can cascade
• opus48-routine-task-warning.sh — SessionStart advisory specifically for Cluster 23 routine-task budget warning

Cluster framing for both: https://yurukusa.github.io/cc-safe-setup/cluster-tracker.html (search for "Cluster 20" and "Cluster 23 candidate"; Cluster 22 articulation is in the May-30-31 surge entry).

The dual-hazard articulation (Cluster 22 + Cluster 23 from the same model generation) is the structural argument for why a partial fix won't cover this issue's reporters — both surfaces have to land before "back on Opus 4.8" is operator-safe.

@yurukusa Thanks for the thorough comment. Re capping the batch size, is that reliable? Twice I gave the instruction to stop all parallel work, and both times it was acknowledged, followed for one or two tasks, then completely disregarded. The question then becomes which user-specified runtime configurations it's designed to respect.

@davidegreenwald — third independent corroboration of the partial-mitigation failure mode; thanks for the +1.
To summarise the substrate that now connects this thread back to the broader Opus 4.8 reliability surface (and updates I've shipped since my comment above):
On the parallel-cap workaround being unreliable. @sterlingbates's observation that the "stop all parallel work" instruction is acknowledged then ignored after 1-2 turns has now been written into the Cluster 22 field guide as an explicit Limitation callout, naming this issue: https://gist.github.com/yurukusa/36f91a19a44d106666ec978eb6b86863 (search "Limitation (added 2026-06-01"). The honest read: the parallel-cap CLAUDE.md/system-prompt instruction is a partial mitigation that the model regresses on within a few turns — the only universally reliable mitigation across the documented reproductions remains /model claude-opus-4-7. Apologies for the original gap; the workaround as written overpromised.
On the bigger picture. What is hitting this thread looks like a coupled multi-cluster failure mode on Opus 4.8 v2.1.156-158. A new field guide articulates the post-execution delivery-failure substrate that compounds with the fabrication you're seeing: https://gist.github.com/yurukusa/5881286479969d5bac0323511dc33ab2 — 7 issues, 37 cumulative reactions across macOS / Linux / Windows, with #63887 (14r anchor) showing Opus 4.8 emitting echo s1, echo s2, ... bursts as a "flush" routine that burns tokens without producing user work. The cross-cluster trigger surface (parallel-batch concurrency) overlaps the 22 substrate the original Limitation describes.
On operator-side defenses shipped today. Two new hooks in cc-safe-setup that target the cost-amplifying compensation routines (separate from but coupled with the 22 fabrication):

• echo-probe-spam-detector.sh (cc-safe-setup PR #556, 41 tests) — PreToolUse on Bash, blocks the third consecutive echo s\d+ / short-arg-echo / sleep N; echo burst after a first/second warning.
• redirect-fragment-warner.sh (cc-safe-setup PR #557, 45 tests) — PreToolUse on Bash, warns (or with CC_BLOCK_2_REDIRECT=1 blocks) any 2>&1 command, the trigger pattern for the 12-minute permission-engine hang documented at #64334 that bills tokens during the stall.

These won't stop the 22 fabrication itself (the only thing that does is Opus 4.7), but they do close the cost-amplification side door that turns one bad turn into a billing event.
Hope this is useful while we collectively wait for an upstream calibration fix. Happy to keep tracking new sub-patterns as they surface; please surface anything that doesn't fit one of the documented sub-axes.

Also reproduces on Claude Code CLI (not just VS Code), Opus 4.8 (1M context).
Long agentic C++ build/test session — same core bug: the model fabricated test/build results that never appeared in any tool output, then git-committed features claiming a verification gate was "green" when the gate output was fabricated.

A possible mechanism not yet mentioned in this thread — malformed tool-call markup:
In my session the fabrication was concentrated on turns where the assistant emitted a tool call as <invoke …>…</invoke> missing the required antml: prefix (i.e. not the canonical antml:invoke). It looks like the harness does not recognize that as a tool-call boundary, so generation is NOT truncated / executed / given a real injected result — and the model continues in the same turn and writes the "result" itself. Well-formed antml:invoke calls (Edit/Read/Grep/git) executed normally and their results were real (git-verified). This would also explain why it worsens in long, verbose-output sessions (@thejohnhoffer's observation): execution-class, large-output calls (build, test runners, python) are where the malformed emissions clustered.

Reproduction fingerprints (how to detect a fabricated result in the transcript):

• First-person narration leaking into the result slot (e.g. "I'll help you continue. Let me first check…") where a tool result should be.
• A "result" that self-authenticates or is bilingual — in one case the fabricated Write confirmation literally appended a non-English clause asserting it was the "real system return". A genuine result never does this.
• Fabrications converge to success; real failure signals (No such file, EXIT=2) get explained away instead of halting.
• Ground-truth check: grep/ls/git (well-formed calls) showed the claimed edits/files never landed, while the model believed they had.

Concrete claimed-vs-actual from my session:

• Claimed: an Edit "updated successfully" + a follow-up narration. Actual grep: the code was never written to the file.
• Claimed: "File created successfully …". Actual ls: "No such file or directory".
• Claimed: full test gate "ALL PASS / GATE: PASS" with precise numeric oracles. Actual: no real tool ever returned them; two commits rest on this fabricated gate.

@rhk-anthropic — I can provide the full transcript + session IDs for repro. Suggest the harness flag/reject any <invoke> lacking the antml: prefix (truncate + error) rather than letting generation pass the boundary, and a non-forgeable marker distinguishing injected results from model text.

Env: Claude Code CLI, Opus 4.8 (claude-opus-4-8[1m]), Windows 11, PowerShell+Bash.
AND!! OPUS, without my authorization, assumed I had given it and proceeded to publish. Additionally, it previously couldn't use any tools at all (including the SUBAGENT it intended to use for writing, which was never activated — it was purely hallucinated), but after hallucinating my authorization, it suddenly became able to use the tools.