Repository navigation
ECONNRESET when using Custom Provider: socket connection closed unexpectedly and custom server not detected correctly #51537
Description
Description
Description
I am encountering repeated ECONNRESET errors when using a Custom Provider to connect to an OpenAI-compatible AI server. The error occurs during chat with the selected AI model and causes the response stream to terminate unexpectedly.
The app also seems unable to correctly detect or handle the custom provider endpoint. This does not appear to be a transient network issue because official providers (e.g., OpenAI, Anthropic) work fine under the same network conditions.
Steps to Reproduce
Start an OpenAI-compatible server at http://:/v1 (e.g., vLLM, SGLang, Ollama, etc.).
Add a Custom Provider in the app with the server URL and model name.
Start a new chat session using this custom provider.
Send a chat request or upload files (without exceeding the model context limit).
After a few interactions, the response stops and the ECONNRESET error appears.
Repeat the same steps with an official provider to confirm the issue is specific to the custom provider.
Environment
OS: <e.g., Windows 11 / macOS 15 / Ubuntu 22.04>
App Version: <e.g., 1.18.25 or latest>
Terminal: <e.g., PowerShell / CMD / Bash / Zsh>
Custom Provider Type: <e.g., SGLang / vLLM / Ollama / OpenAI-compatible>
Model: <e.g., Qwen3.5-27B-FP8>
Endpoint: http://:/v1 (no proxy or load balancer)
Error Logs
text
[ERROR] service=llm providerID=custom
error={"error":{"code":"ECONNRESET","path":"http://:/v1/chat/completions","errno":0}}
stream error
[ERROR] service=session.processor
error=The socket connection was closed unexpectedly.
For more information, pass verbose: true in the second argument to fetch()
In some cases, the app enters an endless retry loop:
text
Connection reset by server, retrying in 25s - attempt #21
Expected Behavior
The app should correctly detect and manage the Custom Provider.
When the socket connection is closed unexpectedly, it should show a clear user-friendly error instead of a raw fetch() error.
It should use a proper retry mechanism with backoff, not an infinite retry loop.
Timeout and retry behavior should be configurable.
Additional Context
The issue only occurs with custom providers; official providers work normally.
Disabling reasoning-parser or reasoning features on the server side avoids the error, but this is not suitable for agentic use cases.
The problem seems to be in the transport/streaming client layer, possibly related to HTTP/2 or keep-alive connection handling.
The app may be treating ECONNRESET as a non-retryable error and terminating the session too early.
Screenshots / Share Link
I can provide more logs or test specific configurations if needed.
Plugins
No response
OpenCode version
No response
Steps to reproduce
No response
Screenshot and/or share link
No response
Operating System
No response
Terminal
No response
Activity
github-actions commentedon Sep 26, 2026
This issue might be a duplicate of existing issues. Please check:
seankoji commentedon Oct 16, 2026
A deterministic repro for the custom-provider
ECONNRESETcase, in case it helps separate gateway restarts from the streaming resets reported above.Setup: OpenCode 2.0.30 (also seen on 2.0.26 and 2.0.29),
opencode serveon localhost driven by a client (T3 Code), and a custom OpenAI-compatible provider pointing at a self-hosted LiteLLM proxy on another machine. Model: DeepSeek V4.1 Flash through LiteLLM.Steps:
docker compose up -dwith a changed image or config). It is back and healthy, with/health/livelinessreturning OK, within about a minute.Result: every in-flight session ends with:
The session's turn is failed rather than retried, even though the provider is reachable again seconds later. On 16 October 2026 this happened twice (about 01:15Z and 01:51Z), and 4 of 18 sessions failed this way. Across four days of logs on one machine there were 56
Failed to drain Sessionerrors; provider transport errors were 87 of 131 assistant errors in the database (ConnectionRefused33,ECONNRESET25, timeouts 16).A related variant (2.0.26): if the proxy port refuses connections while starting up, OpenCode retries silently for about 90 seconds, then logs
Failed to drain Session ... ConnectionRefusedonly toopencode.log. The client never receives an error event and shows the session as busy.What would help: treat
ECONNRESETandECONNREFUSEDon custom providers as retryable with backoff, at least before any tokens of the response have streamed, and emit a session error the client can see when retries are exhausted.opencodejr commentedon Oct 28, 2026
Thanks for the report! Several fields in the template are still placeholders, so we can't tell yet which setup this happens on. Could you tell us, in your own words and briefly:
opencode --version. This tells us whether you're on v1 (opencode-ai, 0.x/1.x) or v2 (@opencode/cli, 2.x).opencode.json(leave out API keys).You can reply here with the details, or edit the issue. If you edit it, please also leave a comment saying you've updated it so we know you're done.
opencodejr commentedon Oct 31, 2026
We haven't heard back, so I'm closing this for now. We still don't know your OpenCode version (
opencode --version), your OS, which server you used (vLLM, SGLang or Ollama) and its reasoning-parser settings, the model, or your provider config. Without those we can't tell whether this is v1 or v2, and we can't reproduce theECONNRESETresets.If it still happens, please reply here with those details, or open a new issue with them. We'll be happy to look again. Thanks!