Erroneous tokens per min

Same error -- on Sequoia 15.3.2 / Windows 10 +11. On the Pro account.

🖐 stream disconnected before completion: Rate limit reached for gpt-5 in organization org-4186rp37ux4fzmyzgp01lbvp on tokens per min (TPM): Limit 40000000, Used 40000000, Requested 13621. Please try again in 20ms. Visit https://platform.openai.com/account/rate-limits to learn more.

same on pro also

Same 40M token error for me too.

Pro user.

WSL2/Debian 12 under Windows 11

Just upgraded to release build today for codex-cli 0.21.0

gpt-5 / high

Linux User-PC 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun 5 18:30:46 UTC 2025 x86_64 GNU/Linux

Just exited the session. I don't think this is on the client end, this sounds like a throttle on the backend, but in case it is helpful, session token stats:

Token usage: total=205077 input=151765 (+ 3748352 cached) output=53312 (reasoning 30976)

Same thing happening to me. Ubuntu 24.04, Codex v0.21.0

same issue here happening over and over and over

So I also see this in Windows (OpenAI Teams plan), WSL2, Ubuntu, codex v0.21.0.
This is a definite regression from v0.20.0 which i've just tried and don't see the same error at all... For the maintainers, if it helps, I've used "Chat with GitHub" and it's helped me narrow down the issue - hopefully it helps get you closer to the solution:

Here’s a focused technical breakdown of the likely regression causing "stream disconnected before completion" to be more common in 0.21.0 than in 0.20.0, using your context and the actual code.

Where the Error is Triggered

The error

#[error("stream disconnected before completion: {0}")]
Stream(String),

is produced in CodexErr, and is emitted in the process_sse async function in codex-rs/core/src/client.rs. This function processes SSE (Server Sent Events) streams from the Responses API. The error is triggered if the stream is closed, errors, or times out before emitting a response.completed event.

Key locations:

// On SSE error
Ok(Some(Err(e))) => {
    debug!("SSE Error: {e:#}");
    let event = CodexErr::Stream(e.to_string());
    let _ = tx_event.send(Err(event)).await;
    return;
}

// On idle timeout
Err(_) => {
    let _ = tx_event
        .send(Err(CodexErr::Stream("idle timeout waiting for SSE".into())))
        .await;
    return;
}

// If stream ends without completed
Ok(None) => {
    match response_completed {
        Some(ResponseCompleted { ... }) => { ... }
        None => {
            let _ = tx_event
                .send(Err(CodexErr::Stream(
                    "stream closed before response.completed".into(),
                )))
                .await;
        }
    }
    return;
}

What Changed Between 0.20.0 and 0.21.0?

1. Streaming Path and Output Deltas

The most likely regression area is in changes to how incremental output events are handled. In particular, the code comments note:

// We used to ignore these events and forward the duplicated `output` array embedded in the `response.completed` payload.
// That produced two issues:
//   1. No real‑time streaming – the user only saw output after the entire turn had finished, which broke the "typing" UX.
//   2. Duplicate `function_call_output` items – both the individual *and* the completed array were forwarded, which
//      confused the backend and triggered 400 "previous_response_not_found" errors because the duplicated IDs did not match the incremental turn chain.
//
// The fix is to forward the incremental events *as they come* and drop the duplicated list inside `response.completed`.

This means a significant change was made to forward output items as they are streamed, rather than waiting for the response.completed event. If for any reason the stream ends without a response.completed, the error will be triggered.

2. Retry and Timeout Handling

There are also changes around retry and timeout configuration in tests and (likely) in user-facing code, e.g.:

• stream_max_retries
• stream_idle_timeout_ms

If these became stricter or more aggressive, you would see more transient network/SSE issues causing the error to be surfaced.

3. Error Propagation

The code path for process_sse now emits CodexErr::Stream for more event types and error conditions (e.g. stream ends, idle timeout, SSE parse error, network error).

Why Is It More Frequent in 0.21.0?

• Incremental event handling: If the SSE stream or backend doesn't reliably send response.completed (e.g. disconnects, backend bug, network blip), the new incremental forwarding makes Codex more sensitive and will surface this error more often.
• Stricter error reporting: The code is now more explicit in reporting and failing on missing response.completed, whereas older versions may have ignored or hidden this case.
• Possible changes in idle timeout or retries: If these are shorter or less forgiving, any delay or hiccup is now more likely to result in a "stream disconnected before completion".

Recommended Next Steps

1. Compare your configuration for timeouts and retries between versions.
2. Check your backend/SSE provider for reliability in always sending response.completed.
3. Review the process_sse function’s diff between 0.20.0 and 0.21.0, focusing on how it handles incremental events and finalization.

TL;DR

The main code causing this regression is in codex-rs/core/src/client.rs, function process_sse. In 0.21.0, incremental SSE event handling causes CodexErr::Stream("stream closed before response.completed") to be surfaced more often if the stream ends without a proper completion event. This is likely due to intended changes for better streaming UX and correctness, but it exposes stream/network/backend flakiness that was previously hidden.

The same for me.

The temporary workaround is to install the previous release:

Run this if on Mac, and it should work fine until they fix it.

Uninstalls existing installs and installs working version through NPM.

brew uninstall codex
npm uninstall -g @openai/codex
npm install -g @openai/codex@0.20.0

My apologies, the issues should be resolved now, this was server side error so no version rollback is required.

The temporary workaround is to install the previous release

It was also happening to me in v0.19