Repository navigation
[Network connection lost] due to Context overflow at model limit misclassified — no compaction, no retry, session dies!! #33376
Description
Description
Hey, spent some time digging into a session crash and traced it to what I think is a gap in the error classification path. Wanted to share findings in case it helps.
What happened
Long-running session (heavy tool-calling, sequential thinking) hit the model's context window limit. The next request exceeded it, provider returned a context-length error. Instead of triggering auto-compaction, OpenCode classified the error as "Network connection lost." (an UnknownError) and killed the session immediately.
The error is not retryable and doesn't trigger compaction — so the session is just dead with no way to recover.
Why it happens
The issue is in fromError() in packages/opencode/src/session/message-v2.ts. There's a catch-all at the end:
case e instanceof Error:
return new NamedError.Unknown({ message: errorMessage(e) }, { cause: e }).toObject()When the provider returns a context-length error wrapped in a generic Error (not an APICallError), it hits this case instead of being recognized as a context overflow. The function never reaches ProviderError.parseStreamError() because the error is instanceof Error.
Then in retry.ts, retryable() only handles APIError — so NamedError.Unknown gets no retry, and the processor calls halt().
Repro
- Long session with a model that has a defined context limit (mine was mimo-v2.5-free @ 1,048,576 tokens)
- Heavy tool-calling workflow that grows context incrementally
- Continue until you're right at the limit
- Send one more message — session dies with
"Network connection lost."
Suggested fix
Before the case e instanceof Error: catch-all, detect context overflow patterns:
case e instanceof Error: {
const msg = errorMessage(e)
if (/context.*(length|window|limit|exceed)|token.*limit|input.*too.*long|maximum.*context/i.test(msg)) {
return new ContextOverflowError(
{ message: msg },
{ cause: e },
).toObject()
}
return new NamedError.Unknown({ message: msg }, { cause: e }).toObject()
}This way context overflow from any provider gets classified properly and triggers auto-compaction.
Related issues I found while digging
Some of these might be the same root cause showing up differently:
- 502
provider_unavailableerrors from OpenRouter are not retried, causing subagent/session aborts #22448 — 502provider_unavailableerrors not retried. Same error classification gap but for a different error type. The numericcodecheck inretry.ts(typeof json.code === "string") doesn't handle numeric codes from OpenRouter. - [BUG]: Desktop task execution is unexpectedly interrupted with file watcher Invalid handle and undici terminated errors on Windows #29589 — undici
TypeError: terminatedon Windows. Also falls through toNamedError.UnknowninfromError(). Same catch-all gap. - Session token usage grows unbounded via cache.read and causes unrecoverable context-window errors #30649 — cache.read token inflation. Makes this worse because cumulative token counts can make the session think it's already over the limit when the actual context is smaller.
- Network Connection Lost #20060 — "Network Connection Lost" (labeled
bug+core). Probably the same thing. - Request size exceeds model context window #10220 — "Request size exceeds model context window". Same class of issue.
Environment
- OpenCode v1.15.7 (crash), v1.15.11 (retry), v1.17.9 (current — bug still present)
- mimo-v2.5-free via OpenCode Zen (1,048,576 token context)
- Windows 11
Not sure if this is the right place for all of this or if some of these should be separate issues. Happy to split or combine however makes sense for the team.
Plugins
custom framework
OpenCode version
1.17.9
Steps to reproduce
-
Start a long-running session with a model that has a defined context window limit (e.g., mimo-v2.5-free with 1,048,576 token limit)
-
Use a heavy tool-calling workflow — sequential thinking, file operations, web searches — anything that incrementally adds tokens to the context each turn
-
Keep going until the session's total tokens are right at the model's limit. In my case, the session reached 1,048,572 tokens (4 below the 1,048,576 ceiling)
-
Send one more message that would push the total over the limit
-
Expected: OpenCode triggers auto-compaction, reduces context, retries the request
-
Actual: Session dies immediately with error "Network connection lost." — no compaction, no retry, session unrecoverable
The error shows up in the session data as:
{
"name": "UnknownError",
"data": {
"message": "\"Network connection lost.\""
}
}
This is a context_length_exceeded error from the provider that got misclassified by fromError() in message-v2.ts.
Screenshot and/or share link
No response
Operating System
Windows 11
Terminal
Windows Terminal
Activity
github-actions commentedon Jun 22, 2026
This issue might be a duplicate of existing issues. Please check:
If your issue is distinct from these, please clarify what makes it different. Otherwise, consider adding a comment to the most relevant existing issue.
AdityaPagare619 commentedon Jun 22, 2026
The issue is completely different bec it talks about the network problems spawning due to flaw in logic of code and also miss bug discusses about the miss alignment between model and open code itself so its more about these not just the networks failure or timeouts only!
kdttrackgps-ship-it commentedon Jun 25, 2026
Same issue here on Windows with DeepSeek. Severity: session dies completely with no recovery — no compaction, no retry, just 'Network connection lost' and the session is gone.
Environment:
The error is clearly the same as described — catch-all in fromError() classifies provider errors as UnknownError instead of recognizing them as context overflow or retryable transport errors. The undici TypeError: terminated on Windows (issue #29589) is also the same root cause.
Hoping this gets prioritized — it makes long sessions unreliable on Windows.
kdttrackgps-ship-it commentedon Jun 25, 2026
Same issue here on Windows 10. Additional data point for the team:
Environment:
Symptoms:
After extended sessions (30min+) with many tool calls, the session dies with terminated — no recovery, no compaction, session unreachable. Have to restart OpenCode entirely. This happens regularly, sometimes multiple times per day.
Notes:
fromError()catch-all inmessage-v2.tsmisclassifies the provider error asUnknownErrorinstead of triggering compaction or retry.Workaround attempt:
Shorter sessions with fewer tool calls help but hurt productivity. Auto-compaction would be the correct fix — the provider just returns an error when the session exceeds context limits, and OpenCode should compact and retry instead of killing the session.
Happy to provide more logs or session dumps if needed.
kdttrackgps-ship-it commentedon Jun 25, 2026
Windows 11 + OpenCode Desktop v1.17.10, DeepSeek provider.
Same issue here. During long sessions (heavy tool-calling, sequential thinking), the session dies with 'Network connection lost' / 'Worker has been terminated' — no compaction, no retry, session unrecoverable.
The root cause matches the analysis in this issue: the romError() classifier in message-v2.ts doesn't recognize provider errors (context overflow, transport errors) before the e instanceof Error catch-all, so they get classified as NamedError.Unknown and
etry.ts calls halt().
This is also related to #29589 (undici TypeError: terminated on Windows) — same catch-all gap.
Windows 10/11 users are affected too, not just macOS. Hoping for a fix soon. Happy to provide more logs or testing.
github-actions commentedon Aug 25, 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.