Skip to content

OpenCode Go service (zen/go/v1) frequent intermittent outages — HTTP 000 / 503 / Cloudflare 524 #36889

Closed
Closed
OpenCode Go service (zen/go/v1) frequent intermittent outages — HTTP 000 / 503 / Cloudflare 524#36889
Assignees
StarpTech

Description

@duruonanni
duruonanni
opened on Jul 14, 2026

Summary

The OpenCode Go service at https://opencode.ai/zen/go/v1 is experiencing frequent intermittent outages (HTTP 000, 503 Service Unavailable). These occur multiple times per day, typically lasting 6–12 minutes before recovering.

Evidence from monitoring (July 14–15, 2026)

A health-check pinging https://opencode.ai/zen/go/v1/models every 5 minutes recorded:

Time (CST) Event
22:17 down (HTTP 000)
22:29 recovered — 12 min outage
23:47 down (HTTP 000)
23:59 recovered — 12 min outage
00:05 down (HTTP 000)
00:11 recovered — 6 min outage
00:17 down (HTTP 000)
00:23 recovered

In ~5 hours, the service went down 4 times, ~42 min cumulative downtime (~14% unavailability).

Error patterns

When down, requests to /zen/go/v1/chat/completions return:

Root cause

opencode.ai sits behind Cloudflare with a 120s proxy read timeout (#33726 documents this). When the upstream model backend is under load and response time exceeds 120s, Cloudflare kills the connection and returns an HTML error page. Client SDKs cannot parse HTML as JSON, leading to HTTP 000 / connection-failed symptoms.

This pattern repeats in cycles: DeepSeek backend gets overloaded → slow responses → Cloudflare 524 → Go service appears down → load subsides → recovers in 6–12 min → repeats.

Related issues

Suggestions

  1. Translate Cloudflare 524/503 HTML into proper JSON error responses so clients can handle them gracefully
  2. Increase Cloudflare proxy read timeout from 120s for chat completion endpoints, or implement streaming to keep connections alive
  3. Add a /health endpoint independent of upstream model availability to distinguish "Go service down" from "upstream model slow"
  4. Consider a public status page (status.opencode.ai)

Environment

  • Endpoint: https://opencode.ai/zen/go/v1
  • Models affected: deepseek-v4-flash, deepseek-v4-pro (and likely all Go service models)
  • Client: OpenAI-compatible HTTP client (not OpenCode CLI)
  • Network: Direct connection from China (no proxy / VPN) — confirms issue is not GFW-related

Activity

  1. github-actions
    assigned
    StarpTech
    on Jul 14, 2026

  2. github-actions commented on Jul 14, 2026

    @github-actions
    github-actionsBot
    on Jul 14, 2026 – with GitHub Actions
    Contributor

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

  3. duruonanni commented on Jul 16, 2026

    @duruonanni
    duruonanni
    on Jul 16, 2026
    Author

    Hey @thdxr @adamdotdevin @Brendonovich — wondering if the team has had a chance to look at the Go service stability issues?

    This is affecting users across many different models and has been reported across multiple issues (this one, #35163, #32215, #33726). The pattern is clear: Cloudflare’s 120s proxy read timeout kills requests when upstream (DeepSeek) takes too long, and the error HTML leaks through instead of being translated to JSON.

    Would be great to get an update on whether this is on the roadmap. Happy to help with debugging if needed.

  4. nilcaream commented on Aug 22, 2026

    @nilcaream
    nilcaream
    on Aug 22, 2026

    +1 — hit this today (2026-08-22) across three different models, which points at the gateway rather than any single upstream.

    We use the Go endpoint (https://opencode.ai/zen/go/v1/chat/completions) from an OpenAI-compatible HTTP client with streaming enabled. Between ~14:20 and ~14:40 UTC today we saw three distinct failure modes, on three models from three different upstream vendors:

    • deepseek-v4-pro — HTTP 200, then the SSE stream is dropped mid-generation: the last chunk is a partial token, and there is no finish_reason chunk, no usage chunk (despite stream_options.include_usage), and no [DONE]. This happened both mid-reasoning_content and mid-content, after tens of KB had streamed fine.
    • kimi-k2.7-code (Moonshot) — hard 503 within ~2s of sending the request: 
      {"error":{"type":"server_error","message":"Upstream request failed: Endpoint is unavailable."}}
      with Cloudflare headers (cf-ray, server: cloudflare) on the response.
    • glm-5.3 (Z.ai) — both of the above: one stream truncated mid-reasoning_content, another HTTP 200 where the body ended before a single SSE event arrived, and one more truncated mid-content.

    What makes this interesting for the thread:

    1. It's not DeepSeek-only. Moonshot and Z.ai models failed in the same time window with the same signatures. That's consistent with the gateway/Cloudflare-level explanation in the OP, not with one overloaded upstream.
    2. It's highly intermittent, not a hard outage. In the same session, dozens of requests completed cleanly with proper finish_reason + usage + [DONE] between failures. Small probe requests (trivial prompt, capped max_tokens) to the exact same models completed cleanly minutes after a failure — then a larger request would get its stream cut again.
    3. /models stays fast and healthy (200 in <1s) throughout, so front-door health checks don't reflect it — matches the OP's point about needing a real /health signal.

    From the client side the worst part is that the truncated-stream case looks identical to a clean stop unless you explicitly check for the absence of finish_reason/[DONE] — silent mid-response deaths are much worse to handle than a clean 503.

  5. rtjhussein commented on Aug 22, 2026

    @rtjhussein
    rtjhussein
    on Aug 22, 2026

    Corroborating this on 2026-08-22 against https://opencode.ai/zen/go/v1, with two additional OpenCode Go models and both supported OpenAI streaming protocols.

    Environment:

    • OpenCode CLI 1.18.21
    • OMP 18.0.0 used as a strict OpenAI-compatible stream consumer
    • Windows 11 x64

    Observed failures between approximately 14:34 and 14:51 UTC+02:

    1. ox-alpha-free through /chat/completions: multiple HTTP-200 streams closed without a non-null finish_reason. The client correctly surfaced OpenAI completions stream closed before a finish_reason was received rather than accepting a partial answer.
    2. muse-spark-1.2-contributor through the Responses path: the SSE connection closed without response.completed, response.incomplete, or response.failed. The client surfaced OpenAI responses stream closed before a terminal response event was received.
    3. OpenCode's own runtime log also recorded repeated AI_APICallError: Service Unavailable failures from providerID=opencode-go during the same day's work.

    The failures were intermittent. Fresh minimal probes later completed successfully through both OMP and the OpenCode CLI, which is consistent with the gateway/upstream instability described here rather than a persistent client configuration failure.

    I found a separate deterministic OMP reasoning-effort mapping issue for Ox and reported that independently as can1357/oh-my-pi#9349. The evidence above excludes that 400-class mismatch and concerns only HTTP-200 streams that ended without their required terminal markers plus separate 503 responses.

    This adds two useful distinctions to the existing report:

    • The truncation affects both Chat Completions and Responses protocol paths.
    • It affects Ox and Muse models in addition to the DeepSeek, Kimi, and GLM models already reported here.

  6. jkir4n commented on Aug 23, 2026

    @jkir4n
    jkir4n
    on Aug 23, 2026

    Note for Go triage: in addition to the intermittent 6-12 min 000/503/524 outages tracked here, stealth/ox-alpha (ox-alpha-free / x-preview-f-free) has a deterministic regression since 2026-08-23 ~11:52 IST — any tools: payload on zen/go/v1 (and zen/v1) returns network_error empty / 503 Endpoint is unavailable 100% of the time.

  7. GoingTime commented on Aug 24, 2026

    @GoingTime
    GoingTime
    on Aug 24, 2026

    In the past few days, I have been experiencing frequent random interruptions, and TTFTs lasting more than 20 seconds occurring frequently when using deepseek-v4-flash.

  8. alosslessdev commented on Sep 22, 2026

    @alosslessdev
    alosslessdev
    on Sep 22, 2026

    i just had this. i am getting cannot connect to apy the socket connection was closed unexpectedly. for more information, pass verbsose true in the second argument to fetch. this never happens on fresh chats, but as the chaat receives messages they become more common. this happened after the 1.18.32 update, while older sessions were active with the previous version. i had to stop the sessions with the previous version, and start new ones telling them to look at older sessions and continue where they left off

  9. neriousy
    marked Title: Opencode Go — constant disconnects, 6–8 retries per session, unusable for 2 weeks #36857 as a duplicate of this issue on Oct 1, 2026

  10. guix77 commented on Oct 6, 2026

    @guix77
    guix77
    on Oct 6, 2026

    OpenCode Go has become increasingly unreliable for me recently. GLM 5.3 Flash and other models frequently stay stuck on “thinking” for a very long time or indefinitely.

    The same OpenCode installation, projects and workflows work normally when I switch to OpenRouter or Vercel AI Gateway, so the issue appears specific to OpenCode Go.

    This has become frequent enough that I cancelled my Go renewal today. I still have 52% of my monthly quota remaining, with 11 days left in the current period. I hope I'll be able to use it; otherwise, I'll have to request a refund.

    The lack of a public status page and official communication around service degradation also makes the service feel less professional than I would expect from a paid provider.

    I’d reconsider subscribing once the service is reliably stable, professionally operated, and still competitive enough to justify the subscription.

    EDIT: Adding a log from one affected session. Same opencode-go/glm-5.3-flash session: some requests complete within a few seconds, while consecutive ones can take ~75–100+ seconds with no error or status surfaced. It then returns to normal latency afterwards.

    opencode-go-debug-public.log

  11. neriousy commented on Oct 21, 2026

    @neriousy
    neriousy
    on Oct 21, 2026
    Member

    Thanks for the report, and sorry for the disruption. This was a temporary problem with the hosted service or an upstream model provider, and it has since recovered. You can see live status and past incidents at https://status.opencode.ai. If you still see this now, please open a new issue with the time (with timezone), model, and request ID from the console logs.

  12. neriousy
    closed this as completedon Oct 21, 2026
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