False “high demand” warning with Azure GPT‑5
What version of Codex is running?
0.21.0
Which model were you using?
gpt-5 (azure endpoint)
What platform is your computer?
Linux 5.10.238-231.953.amzn2.x86_64 x86_64 x86_64 (sagemaker studio terminal)
What steps can reproduce the bug?
previously my codex 0.21.0 was working with my azure gpt-5 endpoint. Today it just doesn't reply at all, always saying
:raised_hand_with_fingers_splayed: We're currently experiencing high demand, which may cause temporary errors.
What is the expected behavior?
It should be able to reply normally
NB: upgrading to 0.22.0 fixes the issue, and it works for me again
What do you see instead?
It just replies with this
:raised_hand_with_fingers_splayed: We're currently experiencing high demand, which may cause temporary errors.
Azure metrics is showing that the requests are giving 500 status codes
But I was able to call the azure gpt-5 api with curl successfully, so there was no actual issue with the api
Additional information
Is this related to this in 0.22.0? If it's a breaking change perhaps worth mentioning in the release notes?
https://github.com/openai/codex/pull/2294 moves the login server from Python to Rust, which should help with both https://github.com/openai/codex/issues/2000 and https://github.com/openai/codex/issues/2044.
4 Comments
actually, initially when I upgraded to 0.22.0, it seemed to fix it.
However, a few hours later, I am seeing this issue again even with 0.22.0.
But calling the endpoint with curl is still working
@laphang were you able to resolve this issue? I saw it a lot this weekend and a ton yesterday.
I upgraded to 0.23.0, and then started seeing different messages instead (about token limits, instead of high demand), and then increased the TPM on my azure deployment. It seems to be working ok now, haven't had those issues again in the last week.
Also, moving from the old TS version of codex cli (0.1.2505172129) to 0.21.0 initially for gpt-5, I noticed that the rust versions now use a lot more tokens. So also added some params to my config.toml to manage that a bit, not sure if that had an impact too
Same problem here bizarrely enough!! And this is version 0.55.0 on a Sunday afternoon!!