Skip to content

1.2.25 timeouts are too aggressive for larger local models #17307

Closed

Description

@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

Activity

  1. added
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    perfIndicates a performance issue or need for optimization
    on Mar 13, 2026
  2. boristsr commented on Mar 13, 2026

    @boristsr
    Author

    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.

  3. Stollie commented on Mar 13, 2026

    @Stollie

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

  4. darkalfx commented on Mar 13, 2026

    @darkalfx

    I'm also experiencing this on 1.2.25

  5. handmade0octopus commented on Mar 14, 2026

    @handmade0octopus

    Also experiencing it in .25 and .26

    Only on one file though, unsure why.

  6. coygeek commented on Mar 14, 2026

    @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.

  7. wijjj commented on Mar 15, 2026

    @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?

  8. godmonero commented on Mar 15, 2026

    @godmonero

    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.)

  9. endlesstravel commented on Mar 16, 2026

    @endlesstravel

    same issue

  10. vals-productions commented on Mar 18, 2026

    @vals-productions

    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.

  11. BEEugene commented on Mar 19, 2026

    @BEEugene

    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
          }
        }
      }
    }
  12. winmutt commented on Mar 21, 2026

    @winmutt

    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.

  13. disarticulate commented on Apr 4, 2026

    @disarticulate

    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.

  14. removed
    bugSomething isn't working
    perfIndicates a performance issue or need for optimization
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on May 3, 2026
  15. rekram1-node commented on May 29, 2026

    @rekram1-node
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions