glm-4.6 stalls indefinitely on forced tool_choice, silently degrading verify, recall reranking and the eval judge

[Smana]

Summary

glm-4.6 (via the OpenAI-compatible endpoint at https://api.z.ai/api/paas/v4) hangs indefinitely on any request using the forced tool_choice form — {"type":"function","function":{"name":"<tool>"}}. It emits a single reasoning_content delta and then never sends another byte, so the stream dies on RunLore's idle timeout.

glm-4.5-air answers the identical request correctly in ~5 seconds, so this is specific to glm-4.6.

Reproduction

Identical request, only the model changes:

curl -N -X POST "https://api.z.ai/api/paas/v4/chat/completions" \
  -H "Authorization: Bearer $GLM_API_KEY" -H "Content-Type: application/json" \
  -d '{"model":"glm-4.6","stream":true,
       "tool_choice":{"type":"function","function":{"name":"submit_verdicts"}},
       "messages":[{"role":"user","content":"Verify this finding: harbor-db migration lock. Return your verdict."}],
       "tools":[{"type":"function","function":{"name":"submit_verdicts","description":"Submit verify verdicts",
         "parameters":{"type":"object","properties":{"verdicts":{"type":"array","items":{"type":"object",
         "properties":{"index":{"type":"integer"},"verdict":{"type":"string"},"confidence":{"type":"number"}}}}},
         "required":["verdicts"]}}}]}'

model	result
glm-4.6	198 bytes then silence; killed at 145s. Entire body is one chunk: delta: {"role":"assistant","reasoning_content":"The"} — no tool call, no finish_reason, no [DONE]
glm-4.5-air	5s, ~25KB, "name":"submit_verdicts", "finish_reason":"tool_calls", [DONE]

Observed the same way end to end via lore demo investigate --record on the harbor-chart-bump scenario, three times:

• twice with the default clientcore.IdleTimeout (2m): verify pass failed; keeping findings as-is err="read stream: idle stream timeout" at ~121s
• once with the timeout raised to 10m: ran 5 minutes, then stream ended before finish_reason or [DONE] (truncated upstream)

Non-forced tool calls work fine on glm-4.6 — the ordinary investigation turns (what_changed, query_logs, query_metrics, network_drops, submit_findings) all complete normally. Only the forced form stalls.

Impact

ToolChoice is how RunLore guarantees structured output. Every one of these degrades or fails on glm-4.6:

Call site	Feature
internal/investigate/verify.go:95	adversarial verify pass — falls back to keeping findings as-is, so confidence is never adjusted
internal/investigate/rerank.go:138	instant recall's calibrated fire gate — a reranker that never answers falls through to a full investigation
internal/investigate/loop.go:391	post-budget-nudge submit_findings
internal/eval/judge.go:132	the eval judge (submit_grade) — affects published scorecard numbers
internal/kbvalidate/semantic.go:77	semantic KB validation
internal/kbimport/enrich.go:54	lore kb import --model

The verify failure is logged at WARN and swallowed (by design — verify is best-effort). That is correct behaviour for a transient provider error, but it means a user running glm-4.6 loses the adversarial check silently, keeping unverified confidence scores. Since honest confidence is a core claim, this is worth surfacing more loudly than a warning.

Suggested actions

1. Document glm-4.6 as incompatible on the LLM integrations page; recommend glm-4.5-air (verified working) or routing structured-output turns elsewhere via model.verify.
2. Consider detecting repeated forced-tool_choice stream failures and surfacing them at startup or on the delivered finding, rather than only at WARN — a silently-skipped verify pass is exactly the kind of degradation this project's positioning says it should not hide.
3. Upstream: report to Z.ai / Zhipu; from the outside this looks like a server-side bug in glm-4.6's reasoning path when a function call is forced.

Verified 2026-08-02 against https://api.z.ai/api/paas/v4.