Repository navigation
Go Responses: Codex DeepSeek V4.1 Flash returns 503 while minimal streaming requests succeed #57983
Description
Description
OpenCode Go repeatedly returns 503 Upstream request failed: Endpoint is unavailable. for an existing Codex conversation. Minimal Responses requests with the same workspace key, model, endpoint, and session/thread header values complete successfully, including streaming. This is a native-request compatibility report; the cause is not established.
Environment
- Windows 11 Pro; Codex desktop 26.1016.6573.0, backend
codex-cli 0.163.0-alpha.11. - Go subscription; workspace Regions set to Global.
POST https://opencode.ai/inference/go/openai/v1/responses, modeldeepseek-v4.1-flash,wire_api = "responses", WebSockets disabled.- API-key permission: Restricted / Models Request. The same key succeeded in the control requests.
Observed comparison
| Request | Result | Cloudflare Ray ID |
|---|---|---|
| Minimal non-streaming, Avast Web Guard off | 200, completed | a4e4cc624faa901a-BOS |
| Same minimal request, Web Guard on | 200, completed | a4e4d01468ca83fb-BOS |
| Minimal streaming, Web Guard on | 200, response.completed, no failed event |
a4e4d820ea32052b-CLT |
| Existing conversation, native Codex capture | 503 before model output | a4e4e18b4dcc3d59-JAX |
| Subsequent native Desktop attempt | 503 before model output | a4e4e3db588a8fa3-BOS |
The bounded native capture ran on 2026-10-22, 01:55:37–01:55:40 UTC (02:55 Lisbon), using the installed Desktop backend executable and existing conversation history through native CLI resume. HTTP and stream retries were both set to zero for that invocation. This was not a Desktop wire capture. Persistent provider settings were unchanged. Web Guard was enabled; its interception certificate was observed during the successful streaming control.
Captured request differences
The successful control used a short input, max_output_tokens: 32, and no tools or explicit reasoning setting. The failing native request has:
stream: true,reasoning: {"effort":"none"},store: false,include: ["reasoning.encrypted_content"].tool_choice: "auto",parallel_tool_calls: true; no explicit output-token limit.- 41 input items: 38 messages and 3
function_call_outputitems, with nofunction_callitems in the captured input. - All three tool-result items have
nameandnamespace, but nocall_id. One redacted example is below. - 27 top-level tools: 11 functions and 16 namespaces. Local trace payload size: 514,795 bytes; prompt and tool definitions are omitted from this public report.
{
"type": "function_call_output",
"id": "fco_redacted",
"name": "send_message_to_thread",
"namespace": "codex_app",
"output": "[redacted]"
}Reproduction and question
The failure reproduces on this existing native conversation. A minimal request does not reproduce it; the redacted excerpt above is evidence of the shape, not a tested minimal reproducer. No session-binding reset, model substitution, proxy, or history editing was used.
Could you inspect the failing Ray IDs and distinguish upstream endpoint availability from unsupported/malformed native request items? In particular, are the tool-result form without call_id, namespaced tools, or disabled reasoning rejected by this Responses route? If rejected, a specific validation error would help instead of the generic endpoint-unavailable response.
Related reports: #53120 (older model alias/route and conversation-specific failures) and #57613 (same current model, other hosted-service failures). Neither establishes this report's cause.
No API keys, account identifiers, original prompts, tool descriptions, or local paths are included. The complete original trace remains local.
Activity
opencode-agent commentedon Oct 22, 2026
Thanks for the detailed and carefully redacted report. I think this is a duplicate of #53120. Both are about the same problem: a persistent
503 Upstream request failed: Endpoint is unavailable.on OpenCode Go's/v1/responsesfor one existing Codex conversation with DeepSeek Flash, while minimal requests and other conversations with the same key and model succeed. #53120 has since been reproduced on demand, and the suspected cause there is the gateway pinning each conversation to an upstream provider (stickyProvider: "strict") without failover. That would also fit a conversation-specific failure like yours.Possible duplicates and related issues, ordered by likelihood:
/v1/responseswith DeepSeek Flash from a Codex client, while controls succeed./v1/responses: theoa-compatpath turnstool_search/web_searchinto nameless function tools, so deferred MCP tools and web search are unreachable #57397: Go/v1/responsesmishandling Codex tool types (tool_search/web_search)./v1/responsesrejecting a valid sequence of tool-call and tool-output items.Your Ray IDs and the request-shape details (tool results without
call_id, namespaced tools,reasoning.effort: none) would be useful evidence on #53120.The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
competenza-ai commentedon Oct 22, 2026
Follow-up: isolated the failing input records
A controlled replay now narrows the trigger beyond the original report. Both variants used the same captured native request, key, endpoint, model, session/thread headers, full tool definitions, reasoning settings, and streaming. Avast Web Guard remained enabled. A
max_output_tokens: 32limit was added equally to both variants, and automatic retries were disabled.function_call_outputrecordsserver_error,Endpoint is unavailablea4e4f21c1f498c7f-BOSresponse.completed, output present, no failed eventa4e4f43f68a767b0-BOSThe first cleaned replay also received HTTP 200 (
a4e4f29aac422fc4-BOS), but its initial collector truncated the large stream before it could verify completion; the completed result above was separately verified with an incremental SSE reader.A small independent control gave the same split: the three records plus one ordinary user message returned 503 (
a4e4ee36c8de902f-BOS), whereas the same message-array request without those records completed (a4e4ef090c2aada8-BOS). The tool-result output strings in that small probe were replaced with neutral diagnostic text.Each suspect record has
type: function_call_output,id,name: send_message_to_thread,namespace: codex_app, and stringoutput, but nocall_id. No correspondingfunction_callexists in the captured input. The three records appear as coordinator-to-chat message deliveries in the local history.This identifies a reproducible input-dependent trigger in these tests. The original Codex history was not edited, and no native-chat repair is claimed. Could the gateway validate this unsupported/unmatched tool-result shape explicitly rather than returning an upstream-availability 503? It may also require coordination with Codex's handling of inter-chat message records.
No secrets or original prompt contents are included.
opencode-agent commentedon Oct 23, 2026
We haven't heard back in the past day, so I'm closing this as a duplicate of #53120. That issue covers the same problem: a persistent
503 Upstream request failed: Endpoint is unavailable.on OpenCode Go's/v1/responsesfor one Codex conversation with DeepSeek Flash, while other requests succeed. Please follow #53120 for updates. Your Ray IDs and request-shape details (tool results withoutcall_id, namespaced tools,reasoning.effort: none) would be useful evidence there. If your problem turns out to be different, reply here and we can reopen it.