Concurrent sessions via opencode serve can hang with ProviderHeaderTimeoutError while independent processes succeed. #53148

Description

I can consistently reproduce a concurrency difference between independent OpenCode processes and multiple sessions routed through the same opencode serve instance.

Using the same model and the same machine:

Two independent OpenCode processes can generate concurrently without the failure.

Two sessions attached to the same opencode serve instance can be started concurrently, after which one request may continue normally while the other remains stuck waiting for provider response headers.

The stalled request eventually fails with:

ProviderHeaderTimeoutError: Provider response headers timed out after 300000ms

In some runs, the logs also show:

AI_APICallError: Cannot connect to API: The socket connection was closed unexpectedly.

This makes a general provider outage an incomplete explanation, because an independent OpenCode process can continue using the same model while the server-backed request is stalled.

Expected behavior

Both sessions should be able to issue concurrent provider requests and receive their streamed responses independently.

This is particularly important because the same model can already handle concurrent requests when they are run from separate OpenCode processes.

Actual behavior

Under opencode serve, one stream may proceed normally while the other remains stuck waiting for response headers.

After approximately 300 seconds, the stalled request fails with:

ProviderHeaderTimeoutError: Provider response headers timed out after 300000ms

Some runs also produce:

AI_APICallError: Cannot connect to API: The socket connection was closed unexpectedly.

Control comparison

The important control is to run the same workload as independent processes instead of sessions attached to one server:

Independent process A ──> provider
Independent process B ──> provider

This configuration succeeds concurrently.

The failing configuration is:

Client A ─┐
├──> opencode serve ──> provider
Client B ─┘

The behavioral difference is reproducible with the same model and environment.

Evidence

The OpenCode logs consistently show the 300,000 ms provider-header timeout for the stalled request.

The installed OpenCode binary also contains the ProviderHeaderTimeoutError implementation corresponding to the observed message.

Network tracing shows the server process establishing outbound TLS connections to the provider endpoint, including Cloudflare-fronted addresses such as:

104.20.32.17:443
172.66.173.149:443

However, the current evidence does not establish that Cloudflare itself is the component causing the failure.

Current isolation

The failure appears to be associated with the shared server-side provider request path rather than the model being universally unavailable.

At this point I can establish:

independent concurrent OpenCode processes: works

concurrent sessions through one opencode serve: reproducibly fails

stalled server-side request: waits for response headers and reaches the 300 s timeout

What I cannot yet establish from application logs alone is the exact transport mechanism responsible.

Specifically, I have not conclusively determined whether:

the two requests share the same underlying connection,

they use separate pooled connections but share some other provider-client state,

the request is stalled locally before transmission,

the upstream gateway receives the second request but does not return headers, or

the upstream closes/resets the connection.

Hypothesis

The strongest current hypothesis is that something in the shared provider/transport path used by opencode serve behaves differently under concurrent streaming requests.

Possible areas worth investigating include:

provider client reuse between sessions

fetch/transport state shared by sessions

connection pooling or connection reuse

streaming concurrency

request/abort state

upstream gateway behavior when handling concurrent streams

This is intentionally described as a hypothesis rather than a confirmed root cause.

Suggested investigation

The most useful next diagnostic would be to compare the actual transport topology of the two cases.

For the server case, determine whether concurrent requests:

request A → connection X
request B → connection X

or instead:

request A → connection X
request B → connection Y

Then compare that with independent-process execution.

A minimal transport-level reproduction would also be valuable:

one shared provider client + 2 concurrent requests
vs.
two independent provider clients + 2 concurrent requests

If the shared-client case fails while the isolated-client case succeeds, that would provide much stronger evidence for a transport/client-state issue.

If both cases behave identically, the investigation should move further up or further downstream in the stack.

Workaround

For affected models, the currently reliable workaround is to run independent OpenCode processes rather than multiple sessions through one opencode serve instance.

Request

Could someone familiar with the provider/streaming path take a look at how concurrent requests from multiple sessions are handled by opencode serve?

In particular, I would like to know whether the server intentionally shares provider client/transport state between sessions, and whether there are known limitations around concurrent streamed requests.

Plugins

No response

OpenCode version

1.18.34

Steps to reproduce

Start the server:

opencode serve --port 4096

From Terminal A, attach a client:

opencode attach http://127.0.0.1:4096 -m opencode/space-bunny-free

From Terminal B, attach a second client:

opencode attach http://127.0.0.1:4096 -m opencode/space-bunny-free

Send prompts from both clients at approximately the same time, for example:

Reply with exactly: TEST-A

and:

Reply with exactly: TEST-B

Observe the server log:

tail -f ~/.local/share/opencode/log/opencode.log

Screenshot and/or share link

No response

Operating System

Linux Mint

Terminal

Xfce Terminal