Codex backend ends Responses streams at 900 s with a retryable-looking error; gpt-6-astra sometimes streams the full 900 s without completing #51886

What issue are you seeing?

Two related problems on the ChatGPT Codex backend (https://chatgpt.com/backend-api/codex/responses). We call it from a Responses API client (AI SDK @ai-sdk/openai 3.0.89, streaming) with a ChatGPT Pro sign-in, both directly and through a local proxy.

1. Every Responses stream ends at 900 seconds, even while it is still producing events.

Since 2026-09-07 we logged every request that reached 895 s or more. All of them ended at 900 to 902 s, with this frame:

{"type":"error","sequence_number":29810,"error":{"type":"server_error","code":"request_timeout","message":"stream error: stream disconnected before completion: stream closed before response.completed","param":null}}

• Volume: 15 of 943 gpt-6-astra requests and 6 of about 88,000 gpt-5.6-sol requests.
• Routes: the cut appears on the direct route and through the proxy alike.
• Contrast: Anthropic Messages requests through the same proxy run past 20 minutes, so the proxy is not the source.

The error does not say that a duration limit was reached. A client therefore cannot tell this cut from a transient disconnect, which is worth retrying.

2. gpt-6-astra sometimes streams for the whole 900 s and never completes.

The calls are an agent loop: reasoning effort high, function tools, and a strict JSON schema for the final answer. In about 6% of these calls since 2026-10-02 (17 of 268), one response streamed until the 900 s cut. The streams had reached sequence_number 21,980 to 47,209 when they were closed.

• Not silence: the longest gap between content deltas in the failing responses was 9.6 s.
• Not input size: failing inputs ranged from 23 KB to 1.3 MB.
• Not deterministic: the same inputs completed normally on other calls.

We don't yet know whether the runaway is reasoning summary, output text or whitespace. We have added per-call counters and will post them here.

What steps can reproduce the bug?

We have no deterministic repro. The pattern:

1. Stream a POST /backend-api/codex/responses request for gpt-6-astra with reasoning: {effort: "high", summary: "auto"}, function tools, and a strict json_schema text format. The input is a code-review packet of about 20 KB to 1.3 MB.
2. In about 6% of calls, the response keeps streaming far past a normal call's length.
3. At 900 s the stream ends with the request_timeout frame above, before response.completed.

For the cut alone, any streamed response that takes more than 900 s shows it.

What is the expected behavior?

• A response that runs into a server-side duration limit says so. For example, a response.incomplete or response.failed event with a reason that names the limit, so clients can stop treating it as a retryable network fault. The limit itself could also be documented.
• A gpt-6-astra response under a strict JSON schema finishes, or stops at max_output_tokens, instead of streaming for 15 minutes.

Additional information

• When the runaways started: on 2026-09-30 and 10-01 we saw 0 runaways in 45 such calls. From 2026-10-02 on we saw 17 in 268.
• Retries: a retry of the same input usually completes normally. In 3 retries we observed, 2 succeeded at once and 1 hit a second runaway before succeeding.