Let me do it. Emitting. Let me test. Emitting. LOOP #50634

Activity

1. github-actions

   assigned

   kitlangton

   on Sep 22, 2026
2. github-actions commented on Sep 22, 2026

   

   github-actionsBot

   on Sep 22, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • Agent enters an infinite "intent-narration" loop: announces tool calls but repeatedly fails to actually invoke them #46492: Agent enters an infinite "intent-narration" loop: announces tool calls but repeatedly fails to actually invoke them
   • [big-pickle] Agente entra en loop de texto sin emitir tool calls (se atasca narrando la acción a tomar) #46030: Agent stuck in a text loop, narrating action instead of emitting tool calls
   • [Bug]: DeepSeek-V4-Flash-0731 consumed ~22M tokens in prolonged agent loop and failed to complete an Excel engineering task #47253: DeepSeek-V4-Flash-0731 consumed ~22M tokens in prolonged agent loop
   • deepseek flash v4 (opencode go) is broken. #43146: DeepSeek Flash V4 (opencode go) is broken
3. MTG-Thomas commented on Sep 23, 2026

   

   MTG-Thomas

   on Sep 23, 2026

   More actions

   Adding a second symptom from today on OpenCode Go (deepseek-v4.1-flash), possibly a sibling of the narration loop above: raw DSML tool markup leaking into visible content instead of arriving as structured tool_calls.

   Session excerpt (verbatim, formatting preserved):

   Now the Meraki serial→Halo asset matching. Let me confirm the Halo asset fields a Meraki serial could match. From the earlier probe, Halo assets expose `ninjarmm_id`, `key_field` (asset tag/serial), `key_field2` (model), `key_field3` (MAC). I need to check whether Meraki serials land in `key_field` or elsewhere.
   <parameter name="bash"> < | DSML | parameter name="command" string="true">cd /home/thomas/src/bifrost-workspace && grep -rn "\"serial\"\|get(\"serial\"" features/meraki/workflows/appliance_alert_incidents.py | head -10</ | DSML | parameter> < | DSML | parameter name="timeout" string="false">60000</ | DSML | parameter> </ | DSML | invoke> </ | DSML | calls>
   

   What this looks like:

   1. DSML leaked into content — the bash call never became a structured tool_calls entry, so the tool did not execute and the turn dead-ends in prose.
   2. V4.1 spaced-tag dialect — the markers are < | DSML | parameter> / < | DSML | invoke> / </ | DSML | calls>, i.e. V4.1's leading-space tag names, not V4's unspaced <｜DSML｜tool_calls> / invoke / parameter. A parser still keyed to the V4 spelling fails to match, and a failed match passes the markup through as plain text by design (no error).
   3. Malformed envelope — output starts mid-structure with a stray <parameter name="bash"> and never opens a clean <｜DSML｜ calls> / invoke name="bash"> block. Same class of broken-wrapper leak that vLLM has been patching for DeepSeek (tool_calls → toolcalls, missing opener, etc.).

   For reference: DeepSeek's V4.1 encoding reference (encoding/README.md on deepseek-ai/DeepSeek-V4.1-Flash) documents the tag-name change ("DSML tag names use a leading space… the V4 format used <｜DSML｜tool_calls> without a space"). vLLM only gained a dedicated V4.1 tool parser (--tool-parser deepseek_v41) this week (vllm#56235, vllm#56408 draft), which is how new this breakage is.

   Environment:

   • Provider: OpenCode Go (opencode-go/deepseek-v4.1-flash)
   • Date: 2026-09-23
   • Symptom: agent announces the tool use in prose, then emits raw (spaced, malformed) DSML as content; bash never runs; no parser error surfaced

   Happy to attach the full raw stream if useful.
4. MTG-Thomas commented on Sep 23, 2026

   

   MTG-Thomas

   on Sep 23, 2026

   More actions

   Cross-model data point from the same day on OpenCode Go: the same DSML-into-content leak now also shows up on mimo-v2.6-flash, which should never speak DSML at all.

   MiMo's native tool-call grammar is XML (see Xiaomi's docs / --tool-call-parser mimo in SGLang); DSML is DeepSeek-specific. Yet the visible content ends with DeepSeek-V4.1-style spaced, ASCII-pipe DSML closers:

   … def asset_skip_note(*, device_label: str, resolution: HaloAssetResolution) -> str:
   """Build the operator note explaining why an asset was not attached."""
   …
   "No asset was attached to this ticket. "
   "Review the match or reactivate the asset if it is still in service." )
   </ | DSML | parameter> </ | DSML | invoke> </ | DSML | calls>
   

   Details:

   • Dialect is exactly the < | DSML | …> ASCII-pipe variant (fullwidth ｜ transcoded to |), same spelling as the deepseek-v4.1-flash leak posted above — not V4's unspaced <｜DSML｜tool_calls>, and not MiMo's .
   • Structure looks like a tool call whose payload (the Python function body, presumably a write/edit argument) rendered as content and whose closing parameter / invoke / calls tags leaked after it. The tool never ran.
   • Environment: OpenCode Go, MiMo-V2.6-Flash, build agent, 2026-09-23 18:19, same project as the DeepSeek capture above (Meraki→Halo asset matching, bifrost-workspace).

   Two hypotheses, both consistent with "same project, same day":

   1. Cross-model history contamination — if the session previously ran deepseek-v4.1-flash and the leaked DSML turns are still in history, MiMo sees assistant text that looks like the house tool-call format and imitates it. Analogous to compaction: model emits tool calls as literal text after compaction — tools never run, session returns no output #50814, where after compaction the model imitated OpenCode's own [Assistant tool call]: shell(...) history serialization and stopped emitting structured tool parts. If this capture came from a session where the model was switched from DeepSeek → MiMo, that would strongly support this.
   2. Go-gateway / serving-path issue — both models behind opencode.ai/zen/go/v1 leaking the same transcribed DSML dialect would point at the relay's tool-call parsing/normalization rather than either model. The ASCII-pipe form is documented as a proxy-transcode artifact of the fullwidth bars, which is suspicious on a shared gateway.

   For triage: knowing whether this MiMo turn was in the same session as the earlier DeepSeek leak (vs a fresh session) would discriminate between (1) and (2). If fresh-session MiMo independently emits < | DSML | …>, that's much weirder and leans (2).

   Related open threads, different symptoms but same model/window: #50678 (MiMo 2.6 Flash tool-call loops), #50814 (MiMo emits tool calls as literal text after compaction).
5. MTG-Thomas commented on Sep 23, 2026

   

   MTG-Thomas

   on Sep 23, 2026

   More actions

   Confirming the discriminator asked above: same session. The MiMo V2.6 Flash DSML leak happened in the session previously running deepseek-v4.1-flash — the model was switched specifically to escape the DeepSeek tool-call failures, and MiMo then leaked the same < | DSML | …> markup that DeepSeek had been emitting.

   That rules against hypothesis (2) (Go gateway independently making MiMo emit DSML) and for hypothesis (1): the session history still contains assistant turns whose visible content is raw spaced-DSML tool markup, MiMo reads that as the in-context tool-call format and imitates it, and the leak self-sustains after the model switch.

   Implications:

   • Switching models mid-session does not clear the contamination — the bad assistant turns replay into every subsequent request regardless of which model is selected.
   • This is the same self-priming mechanism as compaction: model emits tool calls as literal text after compaction — tools never run, session returns no output #50814 (post-compaction imitation of [Assistant tool call]: history serialization), just with DSML as the imitated format and a model switch as the trigger instead of compaction.
   • Recovery for affected sessions: fork/continue from before the first leaked-DSML turn, or start a fresh session. Typing "continue" won't help once the markup is in history.

   A client-side guard would close the whole family: when serializing history (or on load), detect assistant content ending in leaked tool-call markers (DSML, , [Assistant tool call]:, etc.) and either strip the marker or flag/re-hydrate the turn, so one bad DeepSeek response can't poison every future turn — including turns served by a different model. PR #30633 is a step in this direction for detection+retry at the live-turn boundary; it doesn't cover already-persisted history or cross-model sessions.
6. neriousy commented on Oct 21, 2026

   

   neriousy

   on Oct 21, 2026

   Member

   More actions

   Thanks for the report. This is about how the model itself behaves when served through OpenCode Go (repeating itself, broken tool calls, speed, or rejecting large requests), not a bug in the OpenCode app. We pass these reports to our upstream providers. Starting a new session or running /compact usually helps with loops and oversized-request errors. Closing this to keep the tracker focused; the main discussion is in #50206.
7. neriousy

   closed this as a duplicateof Malformed XML/DSML tool-call output from Opencode Go models #50206 on Oct 21, 2026