Desktop hits 5-minute Headers Timeout Error with slow local providers

[osamahaltassan]

Description

OpenCode Desktop can abort local OpenAI-compatible provider requests after exactly 5 minutes with:

Cannot connect to API: Headers Timeout Error

This happens even when the provider config sets "timeout": false or a much larger timeout. The provider is still working, but OpenCode disconnects and then retries.

This is reproducible with Ollama on CPU when a large prompt takes longer than 300 seconds before response headers or the first streamed token.

Plugins

None

OpenCode version

Current Desktop / dev branch

Steps to reproduce

1. Configure Desktop with a local OpenAI-compatible provider such as Ollama.
2. Set the provider timeout to false or a value greater than 300000.
3. Send a prompt/model request that takes more than 5 minutes before the first response.
4. Observe Desktop fail with Headers Timeout Error and retry while the provider is still computing.

Screenshot and/or share link

N/A

Operating System

Windows 11

Terminal

N/A

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• HeadersTimeoutError after 5 minutes when using @opencode-ai/sdk versions > 1.3.3 #20119: Same HeadersTimeoutError after exactly 5 minutes, same symptom of the timeout config not being respected
• SDK client times out after exactly 5 minutes on Node.js when using session.prompt() #15555: Same root cause (undici's hardcoded 300s headersTimeout), same error with local providers taking >5 minutes, same finding that timeout: false has no effect

[osamahaltassan]

Checked #15555 and #20119. They are related, but I think this issue is a different request path.

Those issues describe SDK client.session.prompt() timing out while a Node SDK client waits for the OpenCode server response. This Desktop case uses the local Desktop/sidecar flow: the UI calls prompt_async, the local API returns immediately, and the long wait happens later when OpenCode's Node/Electron sidecar calls the OpenAI-compatible provider.

So the shared cause is Node/Undici's 300s headersTimeout, but the failing fetch is different:

• SDK client times out after exactly 5 minutes on Node.js when using session.prompt() #15555 / HeadersTimeoutError after 5 minutes when using @opencode-ai/sdk versions > 1.3.3 #20119: SDK client -> OpenCode server
• this issue: OpenCode sidecar -> provider, e.g. Ollama

PR #26599 targets the provider fetch path in packages/opencode/src/provider/provider.ts, so it does not claim to close the SDK-client timeout issues.

[lolhunter121]

Same for Windows client. Right 300 seconds and he drop session

[C485]

Can we push this fix ASAP? I had to go down to models like 4b because of the size of the context that is used the initial response takes more than 5 minutes.

[RX-LOST]

I still have this issue. Even with the newest update, my local modes like devstral small 2 take too long to process context, and opencode terminates it.

[C485]

I still have this issue. Even with the newest update, my local modes like devstral small 2 take too long to process context, and opencode terminates it.

For now you need to use opencode cli, they wont fix it soon

[bashrusakh]

hey wont fix it soon

why? its clearly a High / P1 bug. opencode gui unusible with local models - 5 minutes its not a big deal for 27-32b qwen to proccess 128-256k ctx and give answer. it can be waaay longer

[osamahaltassan]

PR automatically closed
#26599 (comment)

[Lemtsu]

it's still not fixed

[bashrusakh]

it's still not fixed

#33535

[stevbev]

@Hona Can this issue be prioritized so that #33535 can be merged to resolve this severe problem? Not passing the timeouts from the config makes the opencode desktop useless when using local models.

Cheers mate!

[malek262]

Still reproducing on the current release (1.18.30, Linux), and it is not limited to local models or to one provider.

I run a local LLM router (key rotation and fallback toward cloud providers) and OpenCode talks to it directly on localhost, so I can see both sides of every request. I hit this with Alibaba Model Studio (qwen3.8-max, reasoning_effort medium) and with Perplexity's agent API (claude family reasoning models). The common factor is any upstream that thinks silently for more than 300s before the first byte. While the upstream has produced no response headers there is nothing for the router to forward, and Desktop kills the request at exactly five minutes.

Router side logs from one evening (time from request receipt to client socket close; not a single response byte had been sent on any of these):

2026-09-11 17:01  300002 ms
2026-09-11 18:16  300008 ms
2026-09-11 18:49  300010 ms
2026-09-12 20:00  300002 ms
2026-09-12 20:06  299974 ms
2026-09-12 20:32  299992 ms

Every abort lands at 300.0s within about 20ms. After each death the client retries (the next attempt starts about 2s after the previous one died, which matches SessionRetry with RETRY_INITIAL_DELAY = 2000 and RETRY_MAX_RETRIES = 5), and the retry dies the same way. A single prompt can burn half an hour across a chain of identical attempts before the user sees an error.

The provider UA on these requests reports runtime/node.js/24, so it is the Electron sidecar running the Node server bundle, where global fetch is undici.

Two layers are involved on 1.18.30:

1. With default config, OpenCode's own timer fires first. In packages/opencode/src/provider/provider.ts:

   const headerTimeout = options["headerTimeout"] ?? 300_000
   

   which aborts with ProviderError.HeaderTimeoutError ("Provider response headers timed out after 300000ms"). That part is documented and intentional.

2. The escape hatch does not work on Desktop. Raising the value or setting "headerTimeout": false only removes OpenCode's timer. The sidecar's fetch is still Node's undici with its default 300s headersTimeout, and nothing in the codebase configures a dispatcher (there is no setGlobalDispatcher call anywhere; the timeout: false passed in provider.ts is a Bun only option, the ts-ignore right above it links to an oven-sh/bun issue). So on Desktop a request can never wait more than 300s for response headers, regardless of config, while the CLI on Bun honors the setting. That is the asymmetry people in this thread were told to work around by using the CLI.

The same wall also appears mid stream, which is the clearest confirmation that this is a transport level inactivity timer and not an application timeout: with slow reasoning models, a stream that has already started dies the same way when no bytes arrive for 300s (undici's bodyTimeout). When my router emits an SSE comment line (": keepalive") every 15s, the same streams survive the silence and complete normally.

Same root cause as the original report (the "Headers Timeout Error" there is undici's HeadersTimeoutError), observed here from the server side. Closed weight reasoning models routinely take minutes before the first streamed byte now, so the 300s wall gets hit in normal daily use on Desktop, with remote providers as well as local models.

PR #33535 had the right fix (map the provider timeout options to an undici Agent with headersTimeout: 0 / bodyTimeout: 0 when running on Node) but it was closed by the automated cleanup without a review. Is there appetite to land something like that? I can test a build against the router setup above and report back.

[Sugaroverdose]

Three data points from a Magic Context (dreamer task) setup that may update the state of this thread:

1. The fix PR is dead. #33535 ("apply undici headersTimeout for long-running requests", the SDK client→server dispatcher fix) was closed without merging on 2026-07-23. The 08-16 comment in this thread still asks for it to be prioritized as if it were alive — as of today there is no active fix path on this issue, and the repro was confirmed on 1.18.30 on 09-12. This issue currently needs a fix, not a re-prioritized zombie PR.

2. Configured provider timeouts do not reach this layer. The desktop bundle contains no headersTimeout/bodyTimeout/Dispatcher configuration; the SDK's caller-side timeout/AbortSignal options are cancellation only. So a user who configures, e.g., a 3 000 s provider request timeout still dies at ~302 s — the configured wait budget never applies to the headers phase of the non-streaming session.prompt RPC (whose headers arrive only at turn completion).

3. A new failure class: multi-call agentic turns die mid-turn, not just single slow calls. In our environment a 150-call agentic task (wall time 5–19 min depending on concurrent load — the server's decode rate is 200+ tok/s; the variance is admission queuing) dies at ~302 s with only a small fraction of the work committed, and the driver's retry re-scans the whole scope. Same HeadersTimeoutError signature, but it turns a long-but-successful run into a partial-failure loop.

For reference, the stopgap we filed on the Magic Context side (per-category task scoping so runs fit the window as it exists today) is cortexkit/magic-context#451. The durable fix remains applying a configurable/extended undici headers+body timeout in the SDK dispatcher, as #33535 attempted.

[bashrusakh]

1. The fix PR is dead. #33535 ("apply undici headersTimeout for long-running requests", the SDK client→server dispatcher fix) was closed without merging on 2026-07-23. The 08-16 comment in this thread still asks for it to be prioritized as if it were alive — as of today there is no active fix path on this issue, and the repro was confirmed on 1.18.30 on 09-12. This issue currently needs a fix, not a re-prioritized zombie PR.

its not dead - its closed without review by opencode strange policy.
it can be re-opened any time, or asked to rebase to current main if needed. BUT - no-one (inside opencode team) cares