1.2.25 timeouts are too aggressive for larger local models

[boristsr]

Description

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.

I've set it to

    "lmstudio": {
      ...
      "options": {
        ...
        "timeout": 3000000,
        "chunkTimeout": 3000000
      },

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

1. Open a session with a long context (100k-ish)
2. Choose a local model like Qwen3.5 27b that is somewhat slow on your system
3. Run /compact
4. Experience timeouts

Screenshot and/or share link

No response

Operating System

Linux Mint 22.3 & Ubuntu 24.04

Terminal

Alacritty

[boristsr]

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]

I just instructed: opencode gives time out, split the output 😄

[darkalfx]

I'm also experiencing this on 1.2.25

[handmade0octopus]

Also experiencing it in .25 and .26

Only on one file though, unsure why.

[coygeek]

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.

[wijjj]

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?