✅ Done! Found it — yes, we've hit this before, and there's a fairly concrete answer. The prior occurrence (the one Juan was remembering) In

#proj-agent

, Aug 1 — Juan (U0A9RLDPQU8) opened it with a PR titled _"fix stuck detecion for GLM models"_: github.com/OpenHands/software-agent-sdk/pull/4332 (tracked as issue #4331). Engel (U06PYTVAES1) confirmed the behavior and dug into real trajectories. Findings from that thread: • GLM was emitting the same malformed tool call over and over — e.g.

terminal

with

command: "C-c"

and

is_input: false

(so the Ctrl+C never worked and it retried forever), and

file_editor

create

calls with a

path

but no

file_text

. • The loop was hard-killed by

StuckDetector._is_stuck_repeating_action_error()

after 3 identical action+error pairs → terminal

STUCK

→ "Agent error". • PR #4332 (merged Aug 4) changed that: instead of terminating immediately, the SDK now injects one corrective nudge naming the repeated action and its error, and only hard-terminates if the model repeats it once more. So "give one last chance before stopping it". • Engel's hypothesis: several models were post-trained on OpenHands'

file_editor

(and even old

str_replace

) tool, so tool-schema adherence is the weak spot — plus a suggestion to eval GLM with simpler tools. • The actual fix that landed for the endpoint side: Alex (U08H0CRU1V4) — "GLM-5.2 should be fixed after we changed providers from fp4 to fp8", and Juan confirmed it worked fine afterwards. That's the "it was a problem with the endpoint" part. • Also flagged there: Z.ai's own report used temperature=1.0 for GLM, so it's worth checking our profile matches (we later added a resolver entry doing exactly that — "Add glm-5.2-fireworks resolver entry; set GLM family temperature to 1.0", PR #3852). Related threads worth reading •

#proj-agent-canvas

, Aug 20 — garbled/DSML output and loops with DeepSeek v4 + GLM-5.2. Graham's agent traced it to a serving-backend streaming/tool-call parser bug, not the SDK: vLLM #53227, SGLang #35563 / #14695. Same conclusion: provider/inference, not context management. •

#questions

— a self-hosted Qwen user looping on "Your last response did not include a function call…" 100s of times; root cause was simply a wrong base URL missing

/v1

. Cheap thing to double-check in any self-hosted setup. •

#automations-debug

— the "chars problem" with GLM, Juan's verdict: "an inference problem and not an SDK/agent-canvas one." About the issue he linked software-agent-sdk #3112 is "OpenHands' performance gap vs Claude Code on open-weight models (Kimi-K2.6 / GLM-5)" — an external EvoClaw-Bench report, already closed as completed. It's about score/wall-clock gaps and turn counts, not this specific repeating-tool-call bug. Its comments do add some SDK hardening ideas around condensation and parallel tool-call recovery, but it's not the answer to his symptom. So what to tell him (self-hosted GLM-5.3 via vLLM on 2× DGX Spark) 1. This is very likely a serving-side issue, not OpenHands — the fp4→fp8 provider switch is what fixed the same symptom for us. Check the quantization of the vLLM weights first. 2. Make sure the vLLM tool-call parser matches the model and

--enable-auto-tool-choice

is on — a mismatched/streaming parser produces exactly these repeated malformed calls. 3. Set temperature=1.0 for GLM (that's what Z.ai used in their own evals). 4. Verify the base URL ends in

/v1

(bit us before). 5. On the SDK side, #4332 is merged, so he should upgrade — he'll get the corrective nudge instead of an instant "Agent error", and stuck detection / max iterations are adjustable. There are still open PRs (#5707, #5783) fixing `maxIterations`/`stuckDetection` not being forwarded in some paths, so it's worth pinning a recent version. If he can share a trajectory, the fastest signal is the same one that cracked our case: look at the exact repeated tool call — whether it's a malformed call (parser/quantization) or a valid but redundant one (then it's genuinely stuck detection / prompt territory).