Opus claude-opus-4-8 emits unparseable tool calls at ~1.5% rate; opus-4-7 and sonnet-4-6 have 0% failure rate

I am seeing the same failure locally, mostly around claude-opus-4-8.

Environment:

• macOS 15.7.7 (24G720), arm64
• Claude Code currently: 2.1.161
• Shell: zsh
• Platform: Claude Code CLI

From local ~/.claude/projects/*.jsonl transcripts, counting only the synthetic retry/error messages and not posting private project contents:

| Date | Claude Code version | Event | Count |
|---|---:|---|---:|
| 2026-05-29 | 2.1.156 | Your tool call was malformed and could not be parsed. Please retry. | 43 |
| 2026-05-29 | 2.1.156 | The model's tool call could not be parsed (retry also failed). | 26 |
| 2026-06-02 | 2.1.160 | malformed retry prompt | 12 |
| 2026-06-02 | 2.1.160 | retry also failed | 7 |
| 2026-06-03 | 2.1.161 | malformed retry prompt | 5 |
| 2026-06-03 | 2.1.161 | retry also failed | 2 |

The events span 16 sessions. The nearest real model recorded before these events is overwhelmingly claude-opus-4-8 (97 nearby occurrences), with only a few from haiku/older opus side sessions.

The 2026-05-29 cluster happened during tool-heavy work involving browser/tool calls and Chinese/CJK project paths/content. In affected turns, Claude Code injects the malformed-tool retry prompt and then sometimes ends with:

The model's tool call could not be parsed (retry also failed).

This still reproduces for me on 2.1.161, though less frequently than the 2.1.156 / 2.1.160 sessions.

Impact:
This is not just a transient UX issue. Each malformed tool-call retry consumes additional tokens and sometimes aborts the turn anyway, so repeated failures can waste a noticeable amount of paid usage/context budget while making the session harder to continue.

Same here on claude-opus-4-8. Adding data points from a heavy Japanese (CJK) usage profile, since long multibyte tool-call arguments seem to aggravate this.

Environment

• macOS 25.5.0 (darwin), arm64
• Claude Code 2.1.150 (Homebrew Cask)
• Model: claude-opus-4-8 (1M context)

Counts from local ~/.claude/projects/*.jsonl (only the synthetic error/retry strings, no private content):

| String | Count (all-time) |
|---|---:|
| Your tool call was malformed and could not be parsed. Please retry. | 164 |
| The model's tool call could not be parsed (retry also failed). | 219 |

Daily peaks: 2026-05-29 = 163, 2026-05-30 = 107, 2026-06-04 = 50.

Observations

• Strongly correlated with AskUserQuestion calls whose description fields hold long Japanese strings, and with Edit calls carrying long CJK old_string/new_string args — consistent with #64506 / #64955.
• Note: the Homebrew Cask is currently capped at 2.1.152, so Homebrew users can't yet reach the 2.1.156+ builds where this thread reports the rate dropping.

Additional repro: Opus 4.8 (1M context) emits a bare literal token call followed by un-namespaced <invoke> in a very long multi-step session

Confirming this on claude-opus-4-8[1m] (1M context), Claude Code CLI, macOS (darwin 25.0.0). Matches the "~76% occur when generating a new tool call after a text segment" characteristic exactly.

Observed defect shape: instead of a properly namespaced tool call, the model emitted the literal text call on its own line, then an <invoke name="..."> / <parameter ...> block without the antml: namespace prefix. The parser dropped it silently, so the tool never ran and the user only saw the turn "stall." This happened on plain Bash, Write, and WebFetch calls — all small inputs, never mid-large-output.

Strongly correlated with session length + reasoning blocks. Clean for the first couple of hours of a tool-heavy session, then began recurring every few tool calls once the conversation grew long (multi-file implementation task, several subagents spawned, multiple HTML artifacts generated). The first tool call in a turn was often fine; later ones in the same turn broke.

Self-correction does not stick. Even after explicitly intending to use the correct format and apologizing, the very next call re-broke the same way — consistent with the "(retry also failed)" / few-shot-poisoning reports (#62344, #65453). Unlike #62344 though, mine was intermittent rather than 100% self-perpetuating: correct and broken calls interleaved in the same session without /clear.

Adds a data point that this reproduces specifically under 1M-context, long-running sessions, and that the user-visible failure mode is "the agent silently stopped" (not just the JSON parse-error banner).

(English first, 日本語版は下部)

+1 — confirming the same regression from a Japanese-language user.

This is not an edge case. Every single Japanese engineer in my workplace is hitting the same issue, and multiple Japanese-speaking developers outside my company have also raised it. For users working in Japanese day-to-day, Opus 4.8 in its current state is not functioning properly and is effectively unusable.

Sessions that involve substantial Japanese (CJK) text in tool-call arguments (Edit / Write / Bash) hit parse failures frequently — long agentic sessions abort multiple times per hour. The exact same workflow runs cleanly on Opus 4.7 and Sonnet 4.6, so this is unambiguously a 4.8-side regression. Matches the 0% vs ~1.5% numbers in the original report.

This is becoming urgent because Opus 4.7 reaches end-of-life next week. Once 4.7 is gone, Japanese / CJK users will have no working Opus tier — we'll be forced down to Sonnet 4.6 just to avoid the parse failures, which is a clear capability regression for the Japanese-speaking user base.

Would really appreciate a fix — or at least an acknowledgment / ETA — before the 4.7 deprecation lands.

---

+1 — 日本語ユーザーとして同じ regression を確認しています。

これは特殊条件ではありません。 自分の職場でも日本人エンジニア全員が同じ問題に当たっており、社外でも日本語で実装している開発者から同様の問題提起が複数上がっています。日本語で実務利用しているユーザーにとって、現状の Opus 4.8 は まともに動作しておらず、全く使い物になっていません。

日本語（CJK）テキストを含む tool call 引数（Edit / Write / Bash）が多いセッションでは parse 失敗が頻発し、長めの agentic セッションだと 1 時間に何度も中断されます。同じワークフローを Opus 4.7 や Sonnet 4.6 で動かすとクリーンに完走するため、明確に 4.8 側の regression です。原報告の 0% vs ~1.5% という数字とも一致します。

来週 Opus 4.7 が EOL を迎えるため、これは急ぎの問題です。4.7 が無くなると日本語 / CJK ユーザーには動作する Opus tier が無くなり、parse 失敗を避けるためだけに Sonnet 4.6 に落とすしかなくなります。日本語圏ユーザーにとっては明確な capability regression です。

4.7 deprecation の前に修正、もしくは少なくとも認知 / ETA の表明をいただけると非常に助かります。

Confirmed on native Windows + first-party API with heavy Japanese tool-call args. Posted a full cross-session breakdown (79 malformed events, version/model exposure with a significance test, request_ids) in #62123 for anyone digging in.

Independent replication from a Japanese (CJK)-heavy profile: 30 malformed-retry events, all on claude-opus-4-8; 0 events across 23k+ assistant messages on opus-4-7 / sonnet-4-6 / fable-5; still occurring in July on client 2.1.197

Environment

• macOS 13.7.8 (Intel), Claude Code desktop app + CLI, client builds 2.1.165–2.1.197 at event time
• Model: claude-opus-4-8, including 1M-context sessions; heavy Japanese (CJK) tool-call arguments
• Single machine's retained transcripts (a second machine with a similar profile is available if more data points help)

Method — mirroring OP: scanned all local ~/.claude/projects/*/*.jsonl (954 session files), counting only entries whose message content is exactly the synthetic string Your tool call was malformed and could not be parsed. Please retry.. One caveat worth passing on to anyone else doing this: naive substring counting gave 590 hits, but 560 of them were echoes (the string quoted inside docs, file reads, and discussions about this bug that end up in transcripts) — only 30 were genuine synthetic error messages. Model attribution = model of the immediately preceding assistant message in the same session; denominator = assistant message count per model.

| model | assistant msgs | malformed-retry msgs | rate |
|---|---:|---:|---:|
| claude-opus-4-8 | 20,377 | 30 | 0.15% |
| claude-opus-4-7 | 11,307 | 0 | 0% |
| claude-sonnet-4-6 | 8,135 | 0 | 0% |
| claude-fable-5 | 3,743 | 0 | 0% |

Observations

• Strictly opus-4-8-only, matching OP's model split exactly — including 0 events on opus-4-7 across 11k+ messages (our designated fallback since early June is opus-4-7[1m], so this includes substantial 1M-context usage).
• Events span 2026-06-10 → 2026-07-03, across 20 distinct sessions and 6 client builds (2.1.165 / .170 / .177 / .181 / .187 / .197). Persists across client versions → consistent with model-side origin; no silent server-side fix as of early July.
• Our 0.15% is lower than OP's 1.5%, but it is a lower bound under active avoidance: since early June we deliberately mitigate (switch to opus-4-7[1m] after 2 malformed failures, prefer one tool call per turn, move heredoc/JSON-literal payloads into files). The June cluster (29 of 30) vs July (1) mostly reflects us migrating away from opus-4-8, not the bug improving.
• We have also hit the adjacent silent variant discussed in #62123 (fabricated tool results / stray court-like prefix tokens in poisoned long sessions); not counted here since it leaves no synthetic marker string to grep.

Happy to provide the scan script or additional breakdowns if useful for triage.