Stream error only written to log, never surfaced to client — session appears to “hang” (opencode as external agent in zed) #58496

Activity

1. opencode-agent commented on Oct 23, 2026

   

   opencode-agentBot

   on Oct 23, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report! Your log line (message="stream error" with providerID/modelID/session.id/small/agent/mode) matches the format OpenCode v1 (opencode-ai, 0.x/1.x) uses. v2 logs differently. v1 now only gets fixes for critical bugs, so this is unlikely to be fixed there.

   The good news is that v2 should already behave the way you expect. The same problem was reported for v1 in #47804, and on v2 free and Go usage-limit errors are treated as quota errors and not retried. So the ACP prompt fails right away with the provider's message, and Zed can show it instead of spinning. Errors that are retried show up as retry status (#50752). To upgrade: opencode upgrade --major (details: https://anoma.ly/notes/opencode-2-0). Then check opencode --version shows 2.x, including for the binary Zed launches.

   Related issues:

   • ACP silently waits on Go quota limits without reporting the provider error #47804: ACP silently waits on Go quota limits without reporting the provider error (v1, fixed on v2)
   • Provider stream dies silently mid-run after a tool batch (GLM-5.3 via nvidia, 1.18.34) — session hangs forever, no error #53083: provider stream dies silently and the session hangs with no error (v1)
   • Subagent (task tool) hangs silently when provider returns an HTTP error — no error surfaced, task stuck running #54568: subagent hangs silently when the provider returns an HTTP error
   • [BUG] FreeUsageLimitError raised with no free usage in the 24h window (free plan, $0 balance) — reset window not exposed to CLI/API #58205, Free models report "Free usage limit reached" despite zero usage #58284, Free quota not reset after indicated time — bug or another limit? #58408: free-tier limit reported without actual usage

   If you still see this on v2, or think it's critical, please reply here with your opencode --version and the matching log, and we'll take another look.
2. opencode-agent

   added

   pending close

   triaging

   on Oct 23, 2026
3. carygravel commented on Oct 23, 2026

   

   carygravel

   on Oct 23, 2026

   Author

   More actions

   ± opencode acp --version                                            
   opencode v2.1.4
   

   I've upgraded to v2, but I still see the same issue. Here is the log:

   timestamp=2026-10-23T18:13:24.842Z level=ERROR run=cf09a659 message="stream error" providerID=opencode modelID=deepseek-v4.1-flash-free session.id=ses_e96767435ffeePRhPa3eNG6YPX small=false agent=build mode=primary error.error="AI_APICallError: Free usage limit reached. Subscribe to OpenCode Go to keep going: https://opencode.ai/go"
   

   But the error didn't surface
4. r266-tech commented on Oct 23, 2026

   

   r266-tech

   on Oct 23, 2026

   Contributor

   More actions

   AI-assisted offline check on the exact v2.1.4 tag (68bc26b7): I ran the real ACP CLI/private server through the repository's subprocess fixture, with a local HTTP endpoint returning either:

   • HTTP 429 with error.type: "FreeUsageLimitError" and your usage-limit message;
   • HTTP 200 SSE containing the same error, followed by [DONE].

   Both session/prompt requests completed with JSON-RPC error -32603, data.errorName: "provider.free-limit", and the user-facing “Free usage limit reached…” message. This was a simulated provider, with no real credentials or model calls; it does not reproduce your Zed instance.

   The v2.1.4 ACP handler starts its own private server. Could you share the executable path/command configured for the Zed agent, and the version reported by that exact executable? A matching session/prompt JSON-RPC response or unresolved request would help distinguish the remaining client/launch-path issue from provider error propagation.
5. opencode-agent

   closed this as not plannedon Oct 24, 2026
6. opencode-agent commented on Oct 24, 2026

   

   opencode-agentBot

   on Oct 24, 2026 – with OpenCode Agent

   Contributor

   More actions

   Closing this as not planned. Your log points to OpenCode v1, which now only gets fixes for critical bugs, and we haven't heard that it also happens on v2.

   On v2, free and Go usage-limit errors are no longer retried, so the ACP prompt fails right away and Zed can show the provider's message (see #47804 and #50752). To upgrade: opencode upgrade --major (https://anoma.ly/notes/opencode-2-0). Make sure the binary Zed launches also reports 2.x.

   If you still see the hang on v2, please open a new issue or reply here with your opencode --version and the matching log. Thanks again for the detailed report!
7. opencodejr

   reopened this on Nov 3, 2026
8. neriousy commented on Nov 5, 2026

   

   neriousy

   on Nov 5, 2026

   Member

   More actions

   Thanks for checking again! The log you posted after upgrading (message="stream error" … small=false agent=build mode=primary) is still written by OpenCode v1. v2 has no such log line. So the opencode that Zed starts is v1, even though opencode acp --version in your terminal reports 2.1.4.

   This usually comes from Zed's ACP registry: the opencode entry may still install v1, and v2 has its own opencode-v2 entry. You can either:

   • switch to opencode-v2 in Zed's agent registry, or
   • point Zed at your v2 binary explicitly in ~/.config/zed/settings.json: under agent_servers, set "command": "/full/path/to/opencode", "args": ["acp"].

   On v2 we tested the free-usage-limit error over a real opencode acp process, both as an HTTP 429 and as an error inside the response stream. In both cases session/prompt fails straight away with "Free usage limit reached…" (provider.free-limit), so Zed can show it.

   Closing this since it doesn't happen on v2. If it still spins after switching, please reply with the exact command or path Zed launches and the log from that process (it should show a v2 version), and we'll reopen.
9. neriousy

   closed this as not plannedon Nov 5, 2026