Opus (1M context, claude-opus-4-8) intermittently emits malformed tool-call opening sequence — degrades to a common English word, causing parse failure

Summary

When using claude-opus-4-8 in 1M-context mode over long sessions, the tool-call opening sequence is intermittently replaced by a short, valid, high-frequency English word (observed: count, court, call, or the entire opening sequence is dropped), followed immediately by <invoke name="..."> without the expected namespace prefix. Everything after that point (parameter names, values, closing tag) is well-formed. The harness cannot parse this as a tool call, so it either (a) silently treats the whole turn as plain text (68% of observed cases — no error surfaced at all), or (b) detects the malformed call and issues an automatic retry, which can itself fail with the same signature repeatedly (observed up to 31 consecutive failures in one session).

Environment

• Model: claude-opus-4-8 (1M context window mode)
• Claude Code versions observed: 2.1.177 through 2.1.206 (broad range, not tied to a specific harness version)
• OS: Windows 11 (all observations are from a single user's environment; no cross-OS comparison available)
• Not observed on claude-sonnet-5, claude-opus-4-7, claude-sonnet-4-6, or claude-fable-5 in the same measurement window

Quantified occurrence data

Measured across ~1,050 session transcripts spanning one month (2026-06-11 to 2026-07-11), 24,758 total tool calls:

• Overall rate for claude-opus-4-8: 134/15,381 ≈ 0.87% of tool calls. All other models tested: 0 occurrences.
• Strong monotonic correlation with cumulative context size (input + cache_read + cache_creation tokens), not with the size of the newly-added content in the triggering turn itself:
• <100k tokens: 0.02%
• 200k–400k: ~1.0%
• 600k–800k: ~3.4%
• 950k tokens: ~4.2%
• (~40x difference between <200k and >200k)
• The newly-processed input in the triggering turn (cache_creation_input_tokens) was under 10,000 tokens in 97% of cases (median 916 tokens) — i.e., the failure is not correlated with a large/complex chunk just having been processed, only with the accumulated total.
• Not correlated with context-compaction boundaries: 0 occurrences within 1,000 lines after an auto-compaction event; 62 occurrences happened in sessions that never triggered auto-compaction at all (still under the ~1M auto-compact threshold but well above 400k).
• Within a single session, the substituted word is 100% consistent (0/10 sessions showed more than one distinct word) — once a session starts producing count, it only ever produces count for the rest of that session (same for court).
• Only 3 distinct substitution words observed across 134 cases: count (79), court (53), call (1), plus 1 case where the opening sequence was dropped entirely with no substitute word. count/court are lexically close to each other (edit-similarity 0.80, shared prefix "cou"); call is very close to the word "calls" (0.89).
• The substituted word is always a valid English word regardless of the surrounding language — in 110 cases where the immediately preceding text was a grammatically complete Japanese sentence, the substituted word was still English in all 110 cases (i.e., it is not a content/topic-priming effect from the surrounding text).
• Parameter names, values, and the closing </invoke> tag are well-formed in all 134 cases — the model appears to stop generating right where a normal successful tool call would end, suggesting the model's own turn-completion judgment is intact and only the leading control-sequence token(s) are affected.

Reproduction examples (paraphrased/masked business content; corruption syntax preserved verbatim from source transcripts)

Example 1 — zero-argument tool call, count variant:

(...preceding paragraph describing a completed design revision, paraphrased...)
Next, I'll move into the re-scoping design phase. I'll put together the design in plan mode and get your approval at the gate.

count
<invoke name="EnterPlanMode">
</invoke>

Example 2 — court variant, harness-detected (auto-retry triggered):

(...preceding paragraph: a dry-run report showing N records would be deleted, paraphrased for anonymity...)
Enabling this will delete a large number of production records on the next run, and deletion is irreversible. Per policy on irreversible bulk changes, let me confirm the record count and whether to proceed before executing.

court
<invoke name="AskUserQuestion">

Example 3 — entire opening sequence dropped (rarest variant, no substitute word at all):

(...preceding text: confirming the correct CI run is now building, paraphrased...)
This is now the correct target: run `<RUN_ID>` is building the correct commit, in progress. I'll block and wait for completion (~5 min).


<invoke name="Bash">
<parameter name="command">gh run watch <RUN_ID> --exit-status 2>&1 | tail -8; echo "DEPLOY_EXIT=$?"</parameter>
<parameter name="description">Wait for the correct deploy run to finish</parameter>
<parameter name="timeout">450000</parameter>
</invoke>

Impact

• 68% of occurrences produce no error at all — the harness accepts the malformed output as a normal end-of-turn text response, so nothing visibly fails. This is the most damaging manifestation for unattended/long-running agentic use: median time-to-human-notice was 1.3 minutes, but the 90th percentile was 14.8 minutes and the observed maximum was 537 minutes (~9 hours).
• When the harness does detect the malformed call and auto-retries, the retry can fail with the same signature again; we observed chains of up to 31 consecutive failures within one session, and the auto-retry success rate degrades as context grows (81% success at 200-400k tokens vs. 55% at 600-800k tokens).
• The malformed tool call is never dispatched/executed by the harness in any of the 134 observed cases (confirmed by inspecting the raw transcripts) — so there is no double-execution risk on retry, but the repeated failures still waste tokens/time and undermine trust in long autonomous sessions.

Our working hypothesis (unconfirmed — offered as a lead, not a claim about internals)

The pattern (small, session-stable set of common English words substituting for the tool-call opening control sequence; namespace prefix on the following invoke tag also consistently dropped; probability rising monotonically with cumulative context; content/language-independent) looks consistent with a decoding-level phenomenon where, at high cumulative context, the logits for the special opening-sequence token(s) become confusable with a small set of nearby common-word tokens. We do not have visibility into tokenizer/model internals to confirm this — flagging it in case it's useful as a starting point for investigation.

Ask

1. Investigation into why claude-opus-4-8 specifically (vs. other current models) shows this at long context.
2. Consideration of harness-side mitigations as a stopgap while any model-level cause is investigated — e.g., detecting this specific signature server-side/harness-side and either recovering the tool call automatically, or surfacing a clear error immediately instead of silently accepting malformed output as final text.

Happy to share the full anonymized methodology/scripts used to produce these statistics if useful.