Repository navigation
Sub-agents hang indefinitely on context overflow — no compaction triggered #25187
Description
Bug Description
Sub-agents (spawned via the task tool) can hang indefinitely when their context window overflows. The main agent recovers from overflow via auto-compaction, but sub-agents do not — they silently fail or retry endlessly, causing the parent agent to wait for days.
Reproduction Steps
- Configure a provider that doesn't report accurate token counts or context limits (e.g., z.ai / GLM models)
- Delegate a task to a sub-agent (e.g., WHITEHAT-IMPLEMENTOR) that requires many tool calls (reads, searches, etc.)
- The sub-agent's context grows until it exceeds the model's context window
- The provider either silently accepts the overflow or returns a non-standard error
- The sub-agent hangs — the main agent waits indefinitely
Expected Behavior
The sub-agent should auto-compact its context (same as the main agent) and continue working, or return an error to the parent agent so it can retry or adjust.
Actual Behavior
The sub-agent hangs for hours/days because:
- Overflow detection (
isOverflow()) relies on API-reported token counts which are inaccurate for some providers - No proactive check exists before the API call — overflow is only detected AFTER the stream finishes
- Some providers (z.ai) accept overflows silently without returning errors or accurate usage stats
- Unrecognized overflow errors get classified as generic API errors → retry loop instead of compaction
Environment
- Provider: z.ai (OpenAI-compatible, GLM-5V-Turbo model)
- Model context: ~200k tokens
- OpenCode: latest dev branch
- OS: Windows 11
Root Cause Analysis
Three gaps in the current implementation:
-
session/processor.ts: Overflow detection is purely reactive — only checks token counts from the API response AFTER the stream finishes. Some providers accept overflows silently, so the processor never detects the overflow. -
provider/error.ts: Not all provider-specific overflow error messages match the existing patterns. z.ai/GLM errors are partially handled (model_context_window_exceededexists) but variants liketoken limit exceededare missed. -
session/overflow.ts: When a model doesn't report context limits (context === 0), overflow detection is disabled entirely. This is by design but compounds the problem for providers with incomplete model metadata.
Activity
github-actions commentedon May 1, 2026
This issue might be a duplicate of existing issues. Please check:
finish_reason: model_context_window_exceededis treated as unknown, causing loop instead of stopping (same provider, same symptom)compaction.auto: falseis ignored when provider throws a context overflow error (overflow detection reactive-only issue)If your issue is distinct from all of the above (e.g. specifically about sub-agents not inheriting compaction behavior, rather than the provider-level overflow classification), please clarify how it differs so maintainers can track it separately.
vteran93 commentedon May 2, 2026
I am experiencing something similar, if you are using z.ai coding plan alone without chat gpt or github copilot subscription the spawn agents die in the very beginning and they do not perform their tasks.
Krypto-Whitehat commentedon May 3, 2026
It has not really to do with ZAI GLM Modells, it has likely more to do how OpenCode handle some AI Model calls...
I have the same issue with ChatGPT OpenAI API Calls through Sub Agents, Sub Agents don t get compress/Compact automatically how they should do normally like the main agent do, its likely more that issue.
github-actions commentedon Jul 4, 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.