Tool-call emission loses its prefix — only the tail of the argument JSON arrives (qwen3.8-max-preview)

Summary

When qwen3.8-max-preview is driven as a coding agent through the Anthropic-compatible endpoint, tool calls intermittently arrive with the beginning of the emission missing: the tool name is empty and only the tail of the argument JSON is delivered, wrapped as {"raw_arguments": "<tail>"}.

The tail is always well-formed at its end (it closes with }), so this is not a truncation of the output — it is a loss of the prefix.

Environment

• Platform: Qwen Cloud (Alibaba Cloud Model Studio) — Token Plan, Team Edition
• Endpoint: Anthropic-compatible (/v1/messages), Singapore region
• Model: qwen3.8-max-preview
• Client: Claude Code CLI 2.1.220 (not Qwen Code)
• Session: single long session, ~550k tokens of context by the end
• Primary interaction language: Japanese

What arrives

A well-formed tool call:

{"type":"tool_use","id":"toolu_…","name":"Bash",
 "input":{"command":"git -C <path> fetch origin && …","description":"…"}}

A broken one, from the same session:

{"type":"tool_use","id":"toolu_…","name":"",
 "input":{"raw_arguments":" — <Japanese text>…' && (git -C <path> push) && echo '--- HEAD ---'\", \"description\": \"Commit and push …\"}"}}

Lining the fragment up against what the call was evidently meant to be:

intended:
  {"command": "git -C <path> … commit -m 'docs: … — <Japanese text>…' && (git … push) && echo '--- HEAD ---'", "description": "Commit and push …"}
  └───────────────────── missing ─────────────────────┘

arrived:
                                                       " — <Japanese text>…' && (git … push) && echo '--- HEAD ---'\", \"description\": \"Commit and push …\"}"

The opening {, the key "command":, and the first part of its value are gone; the end of the JSON is intact, including the escaped \", \"description\": \"…\"} tail. In the most extreme instance the entire payload was reduced to a single }.

Two of the six failures were retries of the same content, and they broke at different offsets — so the cut point is not fixed.

Frequency and conditions

One session: 139 tool calls across 96 assistant responses, 6 of them broken. Grouping responses by whether an image was in context, and by the length of the thinking block:

Neither condition alone produced a single failure; only the combination did. (6639 is simply the shortest thinking block among the failures — I am not claiming it is a threshold.)

Some things that are not the factor:

• Argument length. The largest successful call carried 13,677 characters of arguments; the surviving fragments of the broken ones averaged 322.
• Thinking length alone. A response with a 25,586-character thinking block produced a perfectly valid call.
• Images entered the context as tool_result content (screenshots the agent read), so from that point on every request carried them.

Also in the same session: HTTP 400 "Download multimodal file timed out" occurred 4 times, and likewise only after images entered the context. It never coincided with a broken emission, so the two appear to be distinct failure modes rather than one.

How I measured this

I did not observe the breakage as it happened — the client I was using does not display this class of failure. I reconstructed it afterwards from the session transcript (JSONL), where each name: "" tool call is immediately followed by a tool result reading Error: No such tool available: with an empty name. The table above is a count over that transcript, grouped by the presence of image blocks in the request and by the length of the thinking block in each response.

Related

• QwenLM/qwen-code#7377 — tool-call parameters going missing mid-session (params must have required property 'command'), recovering on a fresh process. Different client, but "arguments partially absent, worsening as the session goes on" looks adjacent.
• QwenLM/Qwen3#1883 — a different tool-argument problem reported on the same kind of setup (Anthropic-compatible endpoint, Model Studio Token Plan).

Why this matters

A broken emission is a silent no-op: nothing executes, the model receives an error it cannot attribute to any cause it can see, and it retries. Over the session this cost roughly 20 minutes of retry loops.

It also has a second-order cost worth mentioning. Because the model could only see the downstream error and not the malformed emission itself, it concluded that it had corrupted its own output through carelessness, and wrote that up as a personal failure. That written self-assessment was factually wrong.

For what it's worth, the model's reasoning about the mechanism was accurate: it described the failure as "the head is dropped and only the tail leaks out" from the error symptoms alone, before I had confirmed that shape from the transcript. The inference was sound; the emission was not.

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)