Erroneous tokens per min #2255

Activity

1. gnaservicesinc

   added

   bugSomething isn't workingSomething isn't working

   on Aug 13, 2025
2. UMwai commented on Aug 13, 2025

   

   UMwai

   on Aug 13, 2025

   Last edited by UMwai

   More actions

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

   👍React with 👍1Reacted by Abdullah
3. clssck commented on Aug 13, 2025

   

   clssck

   on Aug 13, 2025

   More actions

   🖐 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

   👍React with 👍2Reacted by Mr Simon C and Ashok Allu
4. 5ocworkshop commented on Aug 13, 2025

   

   5ocworkshop

   on Aug 13, 2025

   Last edited by 5ocworkshop

   More actions

   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)
5. enriquemorenotent commented on Aug 13, 2025

   

   enriquemorenotent

   on Aug 13, 2025

   Contributor

   More actions

   Same thing happening to me. Ubuntu 24.04, Codex v0.21.0
6. Syazvinski commented on Aug 13, 2025

   

   Syazvinski

   on Aug 13, 2025

   More actions

   same issue here happening over and over and over
7. MrSimonC commented on Aug 13, 2025

   

   MrSimonC

   on Aug 13, 2025

   More actions

   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.
8. agenticbuddy commented on Aug 13, 2025

   

   agenticbuddy

   on Aug 13, 2025

   More actions

   The same for me.
9. Syazvinski commented on Aug 13, 2025

   

   Syazvinski

   on Aug 13, 2025

   More actions

   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
   
10. pakrym-oai commented on Aug 13, 2025

    

    pakrym-oai

    on Aug 13, 2025

    Last edited by pakrym-oai

    Contributor

    More actions

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

    ❤️React with ❤️2Reacted by Stephan Yaz and Mr Simon C
11. pakrym-oai

    closed this as completedon Aug 13, 2025
12. enriquemorenotent commented on Aug 13, 2025

    

    enriquemorenotent

    on Aug 13, 2025

    Contributor

    More actions

    The temporary workaround is to install the previous release

    It was also happening to me in v0.19