[Zen Go] ox-alpha-free /v1/responses still 500 on 2026-08-26 despite merged responses-adapter fixes — Codex (Go plan) remains fully down #45104

Summary

Since ~2026-08-23, ox-alpha-free on the Zen Go endpoint (https://opencode.ai/zen/go/v1) returns HTTP 500 on every /v1/responses request \u2014 regardless of streaming or tools. The same model succeeds on all four /v1/chat/completions variants. This is a deterministic 100% outage for clients speaking only the Responses wire protocol (OpenAI Codex CLI/Desktop) on the Go subscription.

This corroborates #44910 with fresh 2026-08-26 data: the failure persists after yesterday's merged adapter fixes (#45013, #45050, #45081, #45085).

Environment

• Endpoint: https://opencode.ai/zen/go/v1 (Go subscription)
• Client: Codex CLI 0.147.0 (wire_api = "responses"), Windows 11
• Probes fired directly at opencode.ai (local proxy bypassed; browser UA to avoid CF 403)
• Two independent Go-subscription keys produced identical split behavior on 08-25 \u2192 rules out account-level rate limiting (also: no 429 anywhere, instant 500)

Probe matrix \u2014 2026-08-26 00:25 UTC (ox-alpha-free)

Control deepseek-v4-flash: all 8 cells \u2192 200 OK.

Client-side symptom

Codex retries 5 times then surfaces "We're currently experiencing high demand" \u2014 misleading, since upstream answers with an instant 500 (<1s), not a load-shedding response.

Timeline

• 08-23: tools-bearing requests begin failing (Zen API: x-preview-f-free / ox-alpha-free fails with "Endpoint is unavailable" for any request containing tools #44300, ox-alpha-free via zen/go/v1: any tools payload returns network_error/503 since 2026-08-23 (was working 02:55-06:11) #44382)
• 08-24: transient recovery noted in opencode-go (zen gateway): HTTP 500 on chat/completions when tools array is sent (ox-alpha-free) #44503, regressed afterwards
• 08-25 ~13:00 UTC+8: entire /v1/responses path down for non-DeepSeek models ([Zen Go] /v1/responses returns 500 for all non-DeepSeek models (mimo/glm/ox-alpha) while /v1/chat/completions works #44910 \u2014 its evidence matrix matches mine cell-for-cell)
• 08-25 15:50\u201322:14 UTC: responses-adapter fixes merged: fix(ai): route response events by output index #45013, fix(ai): replay responses history independently of storage #45050, fix(ai): accept responses calls without item ids #45081, fix(ai): send responses instructions at top level #45085 (fix(ai): replay native hosted tool items #45038, fix(ai): preserve provider-defined responses item ids #45094 still open)
• 08-26 00:25 UTC: probe unchanged \u2014 responses still 4/4 cells 500

Minimal repro

# -> 500 in <1s
curl -s https://opencode.ai/zen/go/v1/responses \
  -H "Authorization: Bearer $GO_KEY" -H "Content-Type: application/json" \
  -d '{"model":"ox-alpha-free","input":[{"role":"user","content":[{"type":"input_text","text":"reply ok"}]}]}'

# -> 200 OK
curl -s https://opencode.ai/zen/go/v1/chat/completions \
  -H "Authorization: Bearer $GO_KEY" -H "Content-Type: application/json" \
  -d '{"model":"ox-alpha-free","messages":[{"role":"user","content":"reply ok"}]}'

Ask

The merged responses-adapter fixes (#45013/#45050/#45081/#45085) don't appear to have reached the Zen Go gateway yet. Could you confirm whether they're pending deployment to the go/v1 route, or whether this needs a separate fix? Happy to re-run the full probe matrix once deployed.