Skip to content

opencode/big-pickle: intermittent socket disconnects cause silent drop (no UI error) + repeated Aborted in logs (v1.18.18, Linux/WSL2) #42950

New issue
New issue
Closed as not planned
Closed as not planned
opencode/big-pickle: intermittent socket disconnects cause silent drop (no UI error) + repeated Aborted in logs (v1.18.18, Linux/WSL2)#42950
Assignees
jlongster

Description

@aentrepreneur
aentrepreneur
opened on Aug 16, 2026

Summary

While using the built-in opencode provider with model big-pickle (Zen free), the connection can drop mid-stream with:

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

When this happens, the user reports that the UI effectively “loses the connection” without clearly surfacing the error (silent drop / no visible error state).

This appears to be the same class of problem as:

…but this report is specifically the socket-closed failure mode on providerID=opencode modelID=big-pickle.

Environment

  • OpenCode: 1.18.18 (from ~/.local/share/opencode/log/opencode.log)
  • OS: Linux (Ubuntu 24.04) / WSL2 environment
  • Provider/model: providerID=opencode modelID=big-pickle
  • Agents impacted: plan, build, compaction (all small=false)

Evidence (last 5 minutes)

Log aggregation from ~/.local/share/opencode/log/opencode.log for the last 5 minutes (UTC):

  • stream_error_big_p_k_socket_closed: 2
  • aborted: 6
  • failed_fetch_models.dev: 1

Verbatim lines (UTC):

timestamp=2026-08-16T23:51:13.948Z level=ERROR run=042c53b4 message="stream error" providerID=opencode modelID=big-pickle session.id=ses_ff3194081ffebphxmz8WESfcYH small=false agent=build mode=primary error.error="AI_APICallError: Cannot connect to API: The socket connection was closed unexpectedly. For more information, pass `verbose: true` in the second argument to fetch() (cause: Error: The socket connection was closed unexpectedly. For more information, pass `verbose: true` in the second argument to fetch())"

timestamp=2026-08-16T23:53:54.387Z level=ERROR run=042c53b4 message="stream error" providerID=opencode modelID=big-pickle session.id=ses_ff3194081ffebphxmz8WESfcYH small=false agent=compaction mode=primary error.error="AI_APICallError: Cannot connect to API: The socket connection was closed unexpectedly. For more information, pass `verbose: true` in the second argument to fetch() (cause: Error: The socket connection was closed unexpectedly. For more information, pass `verbose: true` in the second argument to fetch())"

# After the above, multiple Aborted entries follow (examples):
# timestamp=2026-08-16T23:53:26.380Z level=ERROR ... error=Aborted
# timestamp=2026-08-16T23:54:32.494Z level=ERROR ... error=Aborted

Session creation line confirms version/model:

timestamp=2026-08-16T23:27:24.030Z level=INFO run=042c53b4 message=created id=ses_ff3194081ffebphxmz8WESfcYH ... version=1.18.18 ... agent=plan model.id=big-pickle model.providerID=opencode

Additional observation

In the same hour, the models catalog fetch briefly failed:

timestamp=2026-08-16T23:25:20.625Z level=ERROR run=84bab50d message="Failed to fetch models.dev" cause="... Transport error (GET https://models.opencode.ai/api.json) ..."

But immediately after, manual curl -I https://models.opencode.ai/api.json succeeded with HTTP/2 200 (so this may be transient connectivity/DNS, but it’s correlated in time).

Expected

  1. Stream transport errors (socket closed, 5xx, etc.) are always surfaced to the user.
  2. The UI must never remain in an ambiguous “thinking”/silent state.
  3. Provide clear recovery actions (Retry/Cancel) and a deterministic terminal state.

Actual

  • opencode/big-pickle intermittently throws socket-closed stream errors.
  • User-visible behavior: connection appears lost with no clear error surfaced on screen.

Related historical evidence

Ask

Can we:

  1. Ensure all stream error paths transition the UI/session state to an explicit error (never silent).
  2. Make retry/backoff behavior and timeouts consistent for small=false primary agents.
  3. Consider logging a clear “giving up after N retries” and surfacing it to the UI.

Activity

  1. github-actions
    assigned
    jlongster
    on Aug 16, 2026

  2. aentrepreneur commented on Aug 17, 2026

    @aentrepreneur
    aentrepreneur
    on Aug 17, 2026
    Author

    Update: same session/run shows the same socket-closed stream error hitting the OpenAI provider too.

    From ~/.local/share/opencode/log/opencode.log (OpenCode 1.18.18, Linux/WSL2), within the same run 042c53b4 / session ses_ff3194081ffebphxmz8WESfcYH:

    timestamp=2026-08-17T00:04:40.411Z level=ERROR run=042c53b4 message="stream error" providerID=openai modelID=gpt-5.2 session.id=ses_ff3194081ffebphxmz8WESfcYH small=false agent=plan mode=primary error.error="AI_APICallError: Cannot connect to API: The socket connection was closed unexpectedly. For more information, pass `verbose: true` in the second argument to fetch() (cause: Error: The socket connection was closed unexpectedly. For more information, pass `verbose: true` in the second argument to fetch())"

    So this may be a broader transport/session handling problem (not only opencode/big-pickle backend 500s), but the user-visible symptom is the same: connection drops and the UI doesn’t clearly surface a terminal error state/recovery action.

  3. aentrepreneur commented on Aug 25, 2026

    @aentrepreneur
    aentrepreneur
    on Aug 25, 2026
    Author

    (Superseded) This comment got mangled by shell quoting when posted. Please ignore it and refer to the clean repost here:

    #42950 (comment)

  4. aentrepreneur commented on Aug 25, 2026

    @aentrepreneur
    aentrepreneur
    on Aug 25, 2026
    Author

    Update (v1.18.22, Linux/WSL2) — still lots of disconnects + long reconnect loops on free models

    Note: my previous comment (same timestamp) got mangled by shell quoting. Re-posting the clean data below.

    Environment

    • OpenCode CLI: 1.18.22
    • OS: Ubuntu 24.04.4 LTS on WSL2 (Linux 6.18.33.2-microsoft-standard-WSL2)
    • Evidence: ~/.local/share/opencode/log/opencode.log

    Quantitative summary (last 14 days)

    I bucketed ERROR/stream-error lines into kinds:

    Kind Count Notes
    rate_limit 45 Mostly opencode/*-free and opencode/big-pickle
    socket_closed 20 Includes opencode/big-pickle and also openai/gpt-5.2 in same environment
    models_catalog_fetch 20 Failed to fetch models.dev / GET https://models.opencode.ai/api.json timeouts/transport
    cannot_connect 7 transport/connectivity class

    Top contributors observed in this window:

    • opencode/big-pickle: rate_limit=26, socket_closed=6
    • opencode/hy3-free: rate_limit=9
    • opencode/deepseek-v4-flash-free: rate_limit=8

    Representative log lines (verbatim)

    1) Socket closed (Zen/free)

    timestamp=2026-08-16T23:50:18.132Z level=ERROR ... message="stream error" providerID=opencode modelID=big-pickle ...
error.error="AI_APICallError: Cannot connect to API: The socket connection was closed unexpectedly ..."

    2) 429 / Rate limit exceeded (free models)

    timestamp=2026-08-13T20:59:44.251Z level=ERROR ... message="stream error" providerID=opencode modelID=hy3-free ...
error.error="AI_APICallError: Error from provider (Console): Rate limit exceeded. Please try again later."

    3) Models catalog fetch failures (still happening; contributes to long reconnect + picker/model listing degradation)

    timestamp=2026-08-24T21:09:48.546Z level=ERROR ... message="Failed to fetch models.dev" cause="... GET https://models.opencode.ai/api.json ... Unable to connect ..."
timestamp=2026-08-24T21:09:49.613Z level=ERROR ... message="Failed to fetch models.dev" cause="... Was there a typo in the url or port?"

    Related issues (same failure class)

    Ask / expected fix direction

    1. Broaden retryable transport failures (not just ECONNRESET) — aligns with Sessions fail on transient network errors instead of retrying #30611.
    2. Ensure every stream error transitions UI/session to an explicit error state (avoid silent drops / infinite thinking) — aligns with bug: UI stuck on 'thinking' indefinitely after stream error, no error displayed or state recovery #32366/Silent failure: opencode provider returns 500 errors but client drops response without showing error #38644.
    3. Cache last-known-good models catalog + degrade gracefully if models.opencode.ai/api.json fetch fails (avoid long reconnect loops).
    4. 429 UX for free models: surface cooldown once + suggest alternate free model; avoid repeated retry spam.
  5. NewbSites
    marked Response streams aborted mid-generation (error=Aborted) — turn ends with tool output but no assistant reply #46399 as a duplicate of this issue on Aug 31, 2026

  6. NewbSites commented on Aug 31, 2026

    @NewbSites
    NewbSites
    on Aug 31, 2026

    The same root cause was observed on native Windows (win32, PowerShell); the existing reports are Linux/WSL2, so adding platform data.

    • Version: opencode 1.18.25 (current)
    • Provider/model: opencode-go / glm-5.3-flash
    • Frequency: 13 error=Aborted entries in a single working session
    • Symptom: after a tool call completes, the assistant's follow-up reply never renders; TUI sits on the tool output, and the turn silently ends. The conversation state is intact; any follow-up message continues normally.
    • Log signature: identical to this issue;
      level=ERROR message=process session.id=… messageID=msg_… error=Aborted stack=undefined
    • Config: vanilla; no plugins, no custom agents, no MCP servers.
    • Pattern note: tool commands were always completed, and their effects persisted; only the assistant's post-tool reply was lost. Long replies seem more abort-prone than short ones (unconfirmed).

    Happy to provide full log excerpts or a session share link if useful.

  7. aentrepreneur commented on Sep 2, 2026

    @aentrepreneur
    aentrepreneur
    on Sep 2, 2026
    Author

    Cross-issue correlation from the same environment — and a log discriminator between this issue and #46030

    Same setup as my previous updates (Ubuntu 24.04 / WSL2, ~/.local/share/opencode/log/opencode.log, full history through 2026-09-02).

    Updated totals: message="stream error" entries now total 890 across the whole log (872 at my 2026-08-31 analysis). The embedded detail is consistently AI_APICallError: Cannot connect to API: Unable to connect. Is the computer able to access the url?, occasionally surfaced at process level as error="Cannot connect to API: ...".

    Still live on the current build: latest burst 2026-09-01 21:54–21:55 UTC — 4 consecutive stream error entries within ~60 s on opencode/big-pickle (run 344cbc38, 14 on that run overall) during normal interactive use, immediately followed by a process-level Cannot connect to API. The v1.18.26 release notes contain no changes touching provider transport/socket handling (Bedrock, Claude-thinking and Desktop fixes only).

    Log discriminator — two separable failure layers:

    On 2026-08-28, run a9c7879c (session ses_ff3194081ffebphxmz8WESfcYH, agent build) logged 523 opencode/big-pickle streams + 556 loop steps with zero stream error / rate-limit / cannot-connect entries — a text-only autoregressive loop with no tool parts between streams (mechanism + minimal repro in #46030, comments from 2026-08-31).

    Signature Log evidence Issue
    Transport (socket / catalog / rate-limit / cannot-connect) stream error, AI_APICallError: Cannot connect to API, the quantitative table in the v1.18.22 update above this issue
    Behavior (text-only loop, no tool parts) bursts of back-to-back streams with clean logs — no error entries at all #46030

    Both can co-occur in the same session history, but they are separable by signature: the loop failure produces no transport errors, so a transport-side fix won't address it (and vice versa). Together with @NewbSites' native-Windows report on opencode-go/glm-5.3-flash, the transport pattern spans platforms and both opencode/* (free) and opencode-go/* (paid) endpoints — pointing at the provider/proxy side rather than any single model.

    Happy to re-measure the totals after any transport-side patch lands.

  8. aentrepreneur commented on Sep 13, 2026

    @aentrepreneur
    aentrepreneur
    on Sep 13, 2026
    Author

    Update (v1.18.30, 2026-09-12) — full-day clean session log; proposing re-evaluation / closure

    Same environment (Ubuntu 24.04 / WSL2, ~/.local/share/opencode/log/opencode.log). Note: the log rotated, so the current file covers 2026-09-12 only; historical trend data beyond that is no longer locally available (I'm adding daily archival on my side so future deltas survive rotation).

    Current evidence (v1.18.30, 3 sessions, opencode/big-pickle, main agents plan/build/compaction):

    Signature Today (2026-09-12)
    message="stream error" 0
    socket_closed / Internal server error / Rate limit / Cannot connect 0
    Failed to fetch models.dev (catalog) 0
    error=Aborted 2 — both immediately preceded by explicit message=cancel (user-initiated Esc), not silent drops

    274 stream calls vs 1,568 tool/permission events → healthy tool interleaving (no sustained no-op bursts).

    Version note: v1.18.27 added "Default streamed chunk timeouts to five minutes", which addresses the silent-stall variant this issue overlapped with (#37580/#38644 class).

    Proposal: the socket/silent-drop class shows no recurrence on the current build. If no regression appears in the coming days, recommend closing as resolved on current stack. The remaining behavior class (text-only narration loop with clean logs, no transport errors, reproducible on 2026-08-28) is the discriminator we documented and is tracked separately in #46030.

  9. aentrepreneur commented on Sep 16, 2026

    @aentrepreneur
    aentrepreneur
    on Sep 16, 2026
    Author

    Update (v1.18.31, 2026-09-15 UTC) — no stream-error class observed today

    Upgraded to v1.18.31 (log shows install at 2026-09-14T23:24Z; new session created 2026-09-15T01:06Z).

    In my Ubuntu 24.04 / WSL2 environment (networkingMode=mirrored; DNS via nameserver 10.255.255.254), today’s log window 2026-09-15T00:00Z → 22:44Z shows:

    • level=ERROR message="stream error": 0
    • level=ERROR ... AI_APICallError: 0
    • socket hang: 0
    • level=ERROR ... error=Aborted: 2 (likely local cancels)

    I’ll keep monitoring and can share the full daily log slice if useful.

  10. aentrepreneur commented on Sep 28, 2026

    @aentrepreneur
    aentrepreneur
    on Sep 28, 2026
    Author

    Transport-class recurrence data point for the free opencode gateway, on 1.18.32 (latest).

    Incident (2026-09-28, ~01:06–01:13 UTC):

    • Model opencode/big-pickle (build agent) was streaming a request when the connection dropped mid-stream.
    • The SDK retried the same request 5× over ~80 s; all attempts failed at connect time with the classic fetch-error pair Unable to connect. Is the computer able to access the url? (×8) and Was there a typo in the url or port? (×4).
    • Retry budget exhausted → surfaced as Cannot connect to API: Unable to connect.... In-flight work was preserved (edits made before the drop stayed intact via the original messageID) and the session resumed normally afterwards.

    Local connectivity was NOT the cause: no other endpoint failed in the window, DNS resolves fine, and https://api.opencode.ai/ returns HTTP 200 in <1 s right now.

    Recurrence over the last 16 days (this error class only, from client logs):

    • 2026-09-14 (~15:38Z): 9 stream errors in ~3 min (that window also lost models.opencode.ai — host-wide)
    • 2026-09-16 (~14:32Z): 2 stream errors in ~6 min
    • 2026-09-28 (~01:12Z): 5 stream errors + banner in ~80 s

    All self-recovered within minutes; failures come in short bursts against the shared free gateway (opencode provider ships an embedded gateway — no user auth entry). Seeing this class repeatedly across 1.18.30→1.18.32 points to gateway/network egress rather than client retry logic. Happy to grab more datapoints or run targeted probes if it helps debugging on your side.

  11. aentrepreneur commented on Oct 5, 2026

    @aentrepreneur
    aentrepreneur
    on Oct 5, 2026
    Author

    Update (v1.18.34, 2026-10-04) — no recurrence of the transport class in 6 days; residual errors are quota, not transport

    Same environment (Ubuntu 24.04 / WSL2, mirrored networking, nameserver 10.255.255.254), live log through 2026-10-04.

    Transport class (Cannot connect to API / socket-closed on the free opencode gateway):

    • Last occurrence: 2026-09-28 (14 stream errors that day).
    • ZERO occurrences 2026-09-29 → 2026-10-04 (6 full days), spanning v1.18.33 (2026-09-28) and v1.18.34 (2026-09-30, currently installed).

    Remaining AI_APICallError entries are NOT this class. Per-day totals remain (e.g. 34 on 09-29, 36 on 10-04) but they resolve to the free-tier quota subclass (Rate limit / Weekly usage limit reached, on opencode-go models) — distinct from the connect/socket transport failure tracked here, and unrelated to the client.

    Also: socket-closed total in the full live log is 4, all before 09-28; ProviderHeaderTimeoutError is 1-2/day (minor, separate).

    Releases 1.18.33/1.18.34 carry no transport/stream changes (timeouts for Cloudflare AI Gateway, namespaced session headers, macOS signing, TUI fixes), so the disappearance of this class since 09-28 is attributable to the gateway/network side recovering. If no recurrence in the coming weeks, consider this candidate for closure. Happy to post a negative follow-up if it reappears.

  12. thdxr commented on Oct 11, 2026

    @thdxr
    thdxr
    on Oct 11, 2026
    Member

    Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

    — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

  13. thdxr
    closed this as not plannedon Oct 11, 2026

  14. aentrepreneur commented on Oct 12, 2026

    @aentrepreneur
    aentrepreneur
    on Oct 12, 2026
    Author

    Update — the transport class recurred after my last check, so leaving it as resolved would be inaccurate.

    2026-10-06 (post last comment): 4× stream error on the free opencode-go gateway, model glm-5.3-flash, single session (ses_f4aa76361ffefStlxVhC0hANGh), retry window 12:02:35→12:03:52 UTC — same signature as the 09-28 incident: AI_APICallError: Cannot connect to API: Unable to connect. Is the computer able to access the url? / Was there a typo in the url or port?. Session recovered afterward (no banner observed).

    So the correct history for this class on v1.18.x: 09-14 (9), 09-16 (2), 09-28 (14), 10-06 (4) — intermittent, minute-scale, off-and-on, never a sustained outage.

    I understand this is being closed as part of the 1.x → 2.0 triage. Noted. I'll validate on 2.0 after migrating and will reopen or open a fresh 2.0 issue if it persists there. Keeping the data point here for completeness.

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