usage spiking beacuse of the restore of conversation
What version of the Codex App are you using (From “About Codex” dialog)?
26.519.81530
What subscription do you have?
plus
What platform is your computer?
Microsoft Windows NT 10.0.19045.0 x64
What issue are you seeing?
i want codex to fix the "reconecting" trouble,after follow its restruction and reboot it all my conversation was gone,so i ask codex to restored them,then i noticed my usage is nearly out
i ask codex to check why my token is burnt out 019e72e7-8be3-7e20-beeb-611de514999b
my other project that runs during the spiking 019e3a94-8706-7973-97aa-6f36ce9b7bad
019e3a5c-77fc-7ce0-9709-f51915a4c383
What steps can reproduce the bug?
accidently lose the conversation and restored them
What is the expected behavior?
dont cost my so much tokens,and give me back the wrong caculated tokens
Additional information
I found that this afternoon’s sudden quota spike was probably not caused by a single request actually using hundreds of millions of tokens. It looks more like Codex restored/rebuilt local conversation state, then rewrote several old threads’ accumulated tokens_used values into the local database, making the usage appear to jump all at once.
High-usage threads updated this afternoon:
Mixer project: updated at 16:16, cumulative display around 110,321,392 tokens
reconnecting: updated at 16:22, cumulative display around 5,208,815 tokens
conversation disappeared after restart / recovery: 16:28-16:41, cumulative display around 3,610,166 tokens
this current query thread: after 16:43, cumulative display around 143,758 tokens
But the actual per-turn request logs were much smaller:
Mixer turn at 16:13-16:16 peaked around 240,619 tokens
reconnecting turn at 16:20-16:22 peaked around 153,026 tokens
recovery thread at 16:39-16:41 peaked around 174,412 tokens
this current query thread peaked around 36,682 tokens
So the likely cause is: while handling the earlier reconnecting / conversations disappeared after restart issue, Codex restored old session indexes and local state. Those old conversations already had large cumulative usage values, and after recovery they were counted or displayed as being updated this afternoon. It does not look like a real single-session burn of 110 million tokens this afternoon.
I also checked the public OpenAI status page: on May 29, 2026 there were incidents related to conversations/login/subscription checkout, and historically there was an “Issues with Increased Codex Usage Rate” incident on March 7, 2026, but I did not find a new matching Codex usage-rate incident for today. See OpenAI Status History.