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
1.2.25 timeouts are too aggressive for larger local models #17307
As of 1.2.25 I'm getting a lot more timeouts on larger context sessions with local models like 1.2.25. With default settings I got an error after 2 minutes of prompt processing on a 100k context session of SSE read timed out.
After adjusting timeouts in opencode.json to 300,000 milliseconds it improved but doing a compaction still generated a less descriptive timeout of TimeoutError: The operation timed out after 5 minutes.
Which is 50 minutes which has resolved it for now. I couldn't see an obvious specific timeout in the diff between 1.2.24 and 1.2.25, but it's definitely more aggressive now and started occuring with a silent update.
Plugins
No response
OpenCode version
1.2.25
Steps to reproduce
Open a session with a long context (100k-ish)
Choose a local model like Qwen3.5 27b that is somewhat slow on your system
As a side note, love the project and the work btw! Keep it up. Logging the ticket mostly as documentation if others experience the issue, if you need to triage it low priority.
Seeing the same TimeoutError: The operation timed out on v1.2.26 (CLI, macOS, Apple Silicon).
Setup:
OpenCode CLI 1.2.26
Provider: github-copilot/claude-sonnet-4.6
macOS 15 (Darwin 25.3.0), Apple Silicon
Node.js via Homebrew
Reproduction:
Running 5 parallel headless verification sessions (opencode run -m github-copilot/claude-sonnet-4.6 --agent verification-master "..."), each dispatching sequential per-file Task subagents. Two of the five sessions crash with TimeoutError: The operation timed out within the first few minutes of subagent dispatch. The other three survive but some subagents return empty output (recorded as PARSE_FAILED by our orchestrator).
The sessions are not idle — they are actively dispatching Task calls when the timeout fires. Appears to be the same SSE/stream timeout regression described here, not an idle timeout.
same here with qwen3.5 27b q8. its just overthinking, i need to tackle this too. of course. but i'd expect that opencode wouldn't care about the overthinker here. thats my problem. no?
I had the issue with macOS, opencode 1.2.27 and followed suggestions above to bump up the timeouts. It did not help as I still ended up with a timeout error at approximately the same step each time and I decided to reboot the computer and try again.
Rebooted, started opencode, entered the same prompt.
Unlike before the reboot the prompt processing was interrupted with a request to give a permission filesystem access needed for processing with possible options to allow once, always allow, deny. It was at the moment I would get a timeout before the reboot. The prompt continued and finished after I provided the necessary permission.
Based on this I think opencode might need to add some more handling when the OS asks for permissions.
Not sure if this a bug, but opencode should suggest to increase it if it happens to often, I suppose.
Here is a simple example for zai coding plan, just put it to opencode config home directory e.g. ~/.config/opencode/opencode.json (create a new file or append to existing one into provider settings).
In 1.2.25 there was a changelog for "Fixed chunkTimeout" which sounds to me like it wasnt working before. Then in 1.2.27 they increased from 2min to 5min. I believe I have been having issues since 1.2.25. Using lemonade/llamacpp/qwen 3.5-120b on a Strix Halo, so prompt processing is slow and when I dump the prompt I get these timeouts.
Yesh, I get Gateway Timeout and it appears to completely disrupt whatever the expected loop is suppose to be; it's happening because of having to boot the model into memory, but after that it's not occuring. Neither timeout:false nor chunkTimeout: 3000000 prevents it. Once the model is loaded and a new session is made, it does go fine.
we disabled those timeouts by default due to many complaints, at some point for durability we will prolly need to reinstate some sort of default timeout for various situations but it will ofc always be configurable.
Activity
boristsr commentedon Mar 13, 2026
As a side note, love the project and the work btw! Keep it up. Logging the ticket mostly as documentation if others experience the issue, if you need to triage it low priority.
Stollie commentedon Mar 13, 2026
I just instructed: opencode gives time out, split the output 😄
darkalfx commentedon Mar 13, 2026
I'm also experiencing this on 1.2.25
handmade0octopus commentedon Mar 14, 2026
Also experiencing it in .25 and .26
Only on one file though, unsure why.
coygeek commentedon Mar 14, 2026
Seeing the same
TimeoutError: The operation timed outon v1.2.26 (CLI, macOS, Apple Silicon).Setup:
github-copilot/claude-sonnet-4.6Reproduction:
Running 5 parallel headless verification sessions (
opencode run -m github-copilot/claude-sonnet-4.6 --agent verification-master "..."), each dispatching sequential per-file Task subagents. Two of the five sessions crash withTimeoutError: The operation timed outwithin the first few minutes of subagent dispatch. The other three survive but some subagents return empty output (recorded as PARSE_FAILED by our orchestrator).The sessions are not idle — they are actively dispatching Task calls when the timeout fires. Appears to be the same SSE/stream timeout regression described here, not an idle timeout.
wijjj commentedon Mar 15, 2026
same here with qwen3.5 27b q8. its just overthinking, i need to tackle this too. of course. but i'd expect that opencode wouldn't care about the overthinker here. thats my problem. no?
godmonero commentedon Mar 15, 2026
same here with GLM 4.7 8bit
Setup:
OpenCode CLI 1.2.26 Running on Ubuntu 25.10
Provider Openai API: LM Studio 0.47 (Build 2) with macOS Tahoe 26.3, Apple Silicon
Opencode Error 1:
Preparing write...
Tool execution aborted
Error: SSE read timed out
LM STUDIO SERVER DEBUG: Client disconnected. Stopping generation... (If the model is busy processing the prompt, it will finish first.)
endlesstravel commentedon Mar 16, 2026
same issue
vals-productions commentedon Mar 18, 2026
I had the issue with macOS, opencode 1.2.27 and followed suggestions above to bump up the timeouts. It did not help as I still ended up with a timeout error at approximately the same step each time and I decided to reboot the computer and try again.
Rebooted, started opencode, entered the same prompt.
Unlike before the reboot the prompt processing was interrupted with a request to give a permission filesystem access needed for processing with possible options to allow once, always allow, deny. It was at the moment I would get a timeout before the reboot. The prompt continued and finished after I provided the necessary permission.
Based on this I think opencode might need to add some more handling when the OS asks for permissions.
BEEugene commentedon Mar 19, 2026
Not sure if this a bug, but opencode should suggest to increase it if it happens to often, I suppose.
Here is a simple example for zai coding plan, just put it to opencode config home directory e.g. ~/.config/opencode/opencode.json (create a new file or append to existing one into provider settings).
{ "$schema": "https://opencode.ai/config.json", "provider": { "zai-coding-plan":{ "options": { "timeout": 3000000, "chunkTimeout": 3000000 } } } }winmutt commentedon Mar 21, 2026
In 1.2.25 there was a changelog for "Fixed chunkTimeout" which sounds to me like it wasnt working before. Then in 1.2.27 they increased from 2min to 5min. I believe I have been having issues since 1.2.25. Using lemonade/llamacpp/qwen 3.5-120b on a Strix Halo, so prompt processing is slow and when I dump the prompt I get these timeouts.
disarticulate commentedon Apr 4, 2026
Yesh, I get Gateway Timeout and it appears to completely disrupt whatever the expected loop is suppose to be; it's happening because of having to boot the model into memory, but after that it's not occuring. Neither
timeout:falsenorchunkTimeout: 3000000prevents it. Once the model is loaded and a new session is made, it does go fine.rekram1-node commentedon May 29, 2026
we disabled those timeouts by default due to many complaints, at some point for durability we will prolly need to reinstate some sort of default timeout for various situations but it will ofc always be configurable.