Repository navigation
Repetitive tool-call loops with alibaba-coding-plan-cn/qwen3.6-plus #22142
Description
Description
When using OpenCode with alibaba-coding-plan-cn/qwen3.6-plus, some sessions fall into repetitive tool-call loops.
What I observe:
- One user turn turns into many assistant turns.
- Adjacent assistant turns often contain nearly identical reasoning.
- Each assistant turn often performs only one tool call, then re-enters the loop.
- The session usually eventually finishes, so this does not look like a storage or transport hang.
- This seems more like a harness-level loop amplification issue that is exposed more often by
qwen3.6-plus.
Local evidence from my machine:
- Session
ses_2845d8980ffemjHrBrf2XpIrY7had18user messages and114assistant messages. - Many adjacent assistant turns repeated almost the same reasoning, especially around checking or updating the same section again after each tool result.
- In a local sample,
qwen3.6-plussessions showed a higher assistant-to-user ratio than recentopencode-go/glm-5.1sessions. - Across stored assistant messages, Qwen also produced many more single-tool turns before reaching a final
stop.
This does not look like a simple “session got stuck forever” bug. It looks more like the loop keeps accepting repeated tool-calls from this model without enough guardrails against repetition.
Relevant code paths that may be involved:
packages/opencode/src/session/prompt.tspackages/opencode/src/agent/agent.ts
My current suspicion:
- OpenCode keeps looping while the assistant finishes with
tool-calls. - The default
buildagent appears to have no practical default step limit. - There does not seem to be a repetition guard for “same reasoning / same tool pattern again”.
qwen3.6-plusseems more likely than some other models to produce serial one-tool-at-a-time continuations, which makes the issue much more visible.
Plugins
No custom plugins involved, as far as I can tell.
OpenCode version
Mostly observed on 1.4.3.
Affected local sessions I checked:
1.4.3:ses_2845d8980ffemjHrBrf2XpIrY7,ses_289442f7affexh49ZQ2S655J74,ses_28a631ed9ffedBp4DospJDEqoE1.4.0:ses_28f1e807cffe55PnIHB9b7fK2C
I also have local qwen3.6-plus sessions on 1.3.13 and 1.4.1, but the strongest examples I inspected were on 1.4.3.
Steps to reproduce
- Configure OpenCode to use
alibaba-coding-plan-cn/qwen3.6-plus. - Use the default
buildagent on a task that requires multiple reads, edits, or repeated verification inside a repo. - Watch the session timeline.
- In some cases, the assistant will produce many short turns with near-duplicate reasoning and one tool call per turn before finally stopping.
A representative pattern is:
- Assistant reasons briefly.
- Assistant performs one tool call.
- Assistant re-enters with nearly the same reasoning.
- Assistant performs another single tool call.
- This repeats much longer than expected.
Screenshot and/or share link
I do not have a share link attached yet.
I can provide sanitized session details if needed. Example local session IDs:
ses_2845d8980ffemjHrBrf2XpIrY7ses_289442f7affexh49ZQ2S655J74ses_28a631ed9ffedBp4DospJDEqoE
Operating System
macOS 26.3.1
Terminal
Not verified from the current environment.
Activity
github-actions commentedon Apr 12, 2026
This issue might be a duplicate of existing issues. Please check:
If your issue is distinct (e.g., specific to the harness-level loop amplification without hallucination), please note that in the issue so maintainers can track it separately.
Astro-Han commentedon Apr 12, 2026
I checked the issues the bot linked.
#18415looks like the closest match.Both reports describe the same broad pattern with Alibaba Coding Plan models: the session runs through many assistant turns, the model makes one small tool call at a time, and the agent repeats very similar actions instead of converging.
What I am seeing in
#22142does not look like the same problem as#21850, where the model keeps retrying a badeditcall with hallucinated input. It also does not look like the older class of bugs where the harness fails to stop afterfinish=stop. In the sessions I checked, the model keeps returningtool-calls, and the loop keeps re-entering normally.Because of that, a small harness-side repetition guard may help both
#22142and#18415. Detecting a short run of near-duplicate tool-call turns, then forcing the model to change course or stop, seems like the most likely minimal fix.My read is:
#18415is probably the closest existing issue#22142adds more concrete session-level evidence for the same or a very similar failure modeHomosapien9 commentedon Jun 23, 2026
I'd like to work on this.
Plan: extend the existing
noProgress/DOOM_LOOP_THRESHOLD check in processor.ts to also cover
cross-message reasoning similarity and reasoning-only no-op loops,
plus add a max-steps-per-turn cap. Branch session-repetition,
PR against dev. OK?
github-actions commentedon Aug 23, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.