Bug: New MiMo 2.6 Flash is unusable due to it ending up in infinite loops #50678

Activity

1. github-actions

   assigned

   rekram1-node

   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:

   • mimov2.6flash会反复读取文件 #50643: Same issue reported today — MiMo v2.6 Flash repeatedly invoking read/search tools in a loop (same version 1.18.32)
   • subagent: mimo-v2.5 stuck in infinite thinking loop (drains credits) #42923: MiMo v2.5 stuck in an infinite thinking loop with identical behavior (subagent drains credits)
   • subagent: infinite loop of identical tool calls for ~50min with no loop protection, uncontrollable token burn #45442: Subagent infinite loop of identical tool calls with no loop protection
   • Doom-loop detection misses periodic tool-call cycles #47759: Doom-loop detection misses periodic tool-call cycles (alternating A, B, A, B patterns not caught by the current guard)

   The root issue — repeated identical tool calls (Glob, Find, Read) with no loop termination — is tracked across those issues. #47759 in particular describes a gap in the existing doom-loop guard that would explain why MiMo v2.6 Flash can still loop even with the current detection in place.
3. omani

   changed the title [-]Bug: New MiMo 2.6 Flash is unusable due to ending up in infinite loops[/-] [+]Bug: New MiMo 2.6 Flash is unusable due to it ending up in infinite loops[/+] on Sep 22, 2026
4. kamilchm commented on Sep 24, 2026

   

   kamilchm

   on Sep 24, 2026

   More actions

   Same happened for me a few times.

   Environment

   • opencode 1.18.30 (session.version)
   • provider xiaomi, model mimo-v2.6-flash, variant high, agent build
   • local git workdir (path and project name redacted)
   • session ses_f4a3eb1fbffeu2w9LHRNv8az7t
   • local opencode DB and log, run eaa73832

   Session totals are mixed (it also ran muse-spark): 101,462,902 input tokens, 817,777,255 cache-read tokens, cost 13.63. The loop below is one assistant message in my session.

   What happened

   After an automatic compaction, opencode injected a synthetic turn (role user) and the model continued. On processor step 31 a single assistant stream emitted the same read call hundreds of times and never finished the step.

   Parent user part prt_0cac87d1f001CAfVxYqMRkzieJ:

   {"type":"text","synthetic":true,"metadata":{"compaction_continue":true},
    "text":"Continue if you have next steps, or stop and ask for clarification if you are unsure how to proceed."}

   Log:

   2026-09-22T20:20:42.837Z stream ... modelID=mimo-v2.6-flash agent=compaction
   2026-09-22T20:33:05.373Z loop   session.id=ses_f4a3eb1fbffeu2w9LHRNv8az7t step=31
   2026-09-22T20:33:05.734Z process session.id=ses_f4a3eb1fbffeu2w9LHRNv8az7t messageID=msg_0cad2769f001AFBSUvSRtNKKAE
   2026-09-22T20:33:05.735Z stream providerID=xiaomi modelID=mimo-v2.6-flash agent=build
   

   No later loop step=32, no exiting loop, no stream error for this session/message. I left the session running, then stopped opencode with CTRL+C. I restarted opencode and, in the same session, typed "continue". The next log line for this session is a new run 36 minutes later:

   2026-09-22T21:09:31.942Z loop session.id=ses_f4a3eb1fbffeu2w9LHRNv8az7t step=0   run=af65eed7
   

   The log has no abort/SIGINT line for run eaa73832, even though I stopped opencode with CTRL+C.

   The stuck message

   msg_0cad2769f001AFBSUvSRtNKKAE

   • modelID=mimo-v2.6-flash, providerID=xiaomi, variant=high
   • finish is null, tokens are all 0, cost is 0 (stream never closed, so usage was never recorded)
   • parts: 1 step-start, 1 reasoning, 261 tool, 0 step-finish, 0 text

   Reasoning text (the model knew exactly which lines it wanted, then called read anyway):

   Need: q1 fragment buyers.tsx with line numbers ... q2 test code with line numbers. q3: three updated tests with file:line ...

   The repeated call

   246 of 261 tool parts are the same call, each with a unique callID:

   {"type":"tool","tool":"read","callID":"call_b554fa7b433e4796a002b20e",
    "state":{"status":"completed","input":{
      "filePath":"<redacted>/buyers.test.tsx",
      "offset":483,"limit":45}}}

   status	count	when (UTC)
   completed, identical input	101	started 20:33:24–21:03:06, all ended 21:03:33–21:05:15
   running, identical input	145	started 21:03:07–21:05:09, time.end null
   other reads (different offset/limit)	14	20:33:15–20:33:27
   pending	1	21:05:09

   All 101 completed outputs are byte-identical (1812 bytes): the file ends at line 512, so offset=483, limit=45 is the tail of buyers.test.tsx, and every call returned that same tail including (End of file - total 512 lines).

   Timing:

   • inter-start of the identical calls: min 388 ms, median ~500 ms
   • no completed call finished before 21:03:33 — 101 calls were in flight at once (started, not yet ended)
   • execution delay for a completed call: min 79.6 s, median 93.1 s, max 1816 s
   • after the queue drained, 145 more identical calls were accepted and left running (consistent with CTRL+C while they were queued)

   This was not a retry of a failed read. The tool succeeded every time it was allowed to finish, with the same body, and the model kept emitting the same call for ~32 minutes inside one step.

   Why this looks like an opencode bug, not just a bad model

   I compared every session for this workdir in my local opencode DB:

   model	assistant messages	max tool parts in one message	tool parts left running
   xiaomi/mimo-v2.6-flash	412	261	152
   meta/muse-spark-1.3-contributor	5976	11	2
   others	—	≤ 8	≤ 1

   The processor loop itself stopped at step 31 (loop ... step=31 is the last step log for run eaa73832). The unbounded repeat is inside a single stream: hundreds of parallel tool calls, no per-step tool-call cap, no identical-call dedupe, and no doom-loop stop. When I cancelled the turn, opencode did not mark the in-flight tool parts completed or errored; 145 stay running.

   Repro shape

   1. Long build session on xiaomi/mimo-v2.6-flash until compaction fires.
   2. Synthetic "Continue if you have next steps..." turn.
   3. Model emits read with a fixed {filePath, offset, limit}.
   4. opencode executes it (returns the same slice, including EOF) and feeds the result back, but the same stream keeps emitting the same call ~2/s for tens of minutes.
   5. No step cap, no identical-call guard. I had to stop opencode with CTRL+C, then restart it and type "continue" in the same session. Tool rows stay status=running.

   Suggested fix

   • Cap tool calls per step (and per identical {tool, input} hash). After N identical successful results, stop the step and return the result instead of calling again.
   • On session abort, mark in-flight tool parts error/cancelled instead of leaving them running.
   • Record stream usage even when the stream is aborted, so a hung step is visible in session token totals.
5. thdxr commented on Oct 11, 2026

   

   thdxr

   on Oct 11, 2026

   Member

   More actions

   Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

   — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
6. thdxr

   closed this as not plannedon Oct 11, 2026