You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
opencode-go upstream idle timeout on reasoning-heavy models with Effort=Max #30002
Bug: opencode-go upstream idle timeout on reasoning-heavy models with Effort=Max
Description
When using mimo-v2.5-pro (and likely other reasoning models) via the opencode-go provider with Build mode + Effort=Max, requests consistently fail with "Upstream idle timeout exceeded" after ~190 seconds.
The same model works fine with:
Build mode + Effort=Medium
Plan mode + Effort=Max
Root cause
During the reasoning phase (chain-of-thought), the model takes 2–4 minutes to generate internal reasoning before emitting any output tokens. The upstream model hosting provider closes the idle connection during this phase.
Meanwhile, input tokens have already been processed and billed, so the user pays for failed requests.
Impact
Cannot use reasoning models at Effort=Max in Build mode
Wasted token cost on every failed attempt
Limits the utility of the opencode-go subscription for deep coding tasks
Suggested fix
Increase the upstream idle timeout on the opencode-go backend (or make it configurable)
Alternatively/ideally: implement streaming of reasoning tokens (e.g., reasoning_content field) so the connection is never idle during the model's thinking phase — this is a standard approach used by providers like OpenAI, Anthropic, and DeepSeek.
Missing required fields: OpenCode version, Operating System, Terminal, and Steps to reproduce are all left as _No response_. These are required for bug reports so maintainers can reproduce and diagnose the issue.
Please provide your OpenCode version, OS, and a minimal set of steps to reproduce the timeout.
Please edit this issue to address the above within 2 hours, or it will be automatically closed.
This issue might be a duplicate of an existing issue. Please check:
Submit a non-trivial coding task that involves generating 200+ lines of code (e.g., "implement a full essence tracker with evidence-based progress assessment across 7 alphas and 15 activity spaces")
Wait ~3 minutes
Expected behavior
Model completes reasoning phase and starts streaming output tokens.
Actual behavior
After ~190-246 seconds an error appears: "Upstream idle timeout exceeded". No output tokens are received. Input tokens have already been billed.
#28957 - it looks like it's the same issue here.
Specific trigger:
Model: mimo-v2.5-pro
Mode: Build, Effort=Max
Plan + Effort=Max → ✅ works
Build + Effort=Medium → ✅ works
The model spends 3–4 minutes in reasoning phase without emitting any tokens, then the upstream idle timeout (~190s) kills the connection. Input tokens are billed despite the failed output. A streaming reasoning_content field would fix this.
Activity
github-actions commentedon May 30, 2026
This issue doesn't fully meet our contributing guidelines.
What needs to be fixed:
_No response_. These are required for bug reports so maintainers can reproduce and diagnose the issue.Please edit this issue to address the above within 2 hours, or it will be automatically closed.
This issue might be a duplicate of an existing issue. Please check:
If you believe this was flagged incorrectly, please let a maintainer know.
den317 commentedon May 30, 2026
OS: macOS Tahoe 26.5
CPU: Apple M4
OpenCode Desktop: v1.15.12
Steps to reproduce
mimo-v2.5-pro(opencode-go provider)MaxExpected behavior
Model completes reasoning phase and starts streaming output tokens.
Actual behavior
After ~190-246 seconds an error appears:
"Upstream idle timeout exceeded". No output tokens are received. Input tokens have already been billed.Working configurations
den317 commentedon May 30, 2026
#28957 - it looks like it's the same issue here.
Specific trigger:
The model spends 3–4 minutes in reasoning phase without emitting any tokens, then the upstream idle timeout (~190s) kills the connection. Input tokens are billed despite the failed output. A streaming reasoning_content field would fix this.
github-actions commentedon May 30, 2026
This issue has been automatically closed because it was not updated to meet our contributing guidelines within the 2-hour window.
Feel free to open a new issue that follows our issue templates.