The limits went from 77% to 0 in one minute

Was about to post the same, everything still seems to be working but everything is showing 0% or

<img width="591" height="89" alt="Image" src="https://github.com/user-attachments/assets/3ba82c22-d706-4472-9926-422fbe1c8aee" />

Estaba a punto de publicar lo mismo, todo parece seguir funcionando pero todo muestra 0% o <img alt="Imagen" width="591" height="89" src="https://private-user-images.githubusercontent.com/153689082/602496378-3ba82c22-d706-4472-9926-422fbe1c8aee.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODA1MjI5NDYsIm5iZiI6MTc4MDUyMjY0NiwicGF0aCI6Ii8xNTM2ODkwODIvNjAyNDk2Mzc4LTNiYTgyYzIyLWQ3MDYtNDQ3Mi05OTI2LTQyMmZiZTFjOGFlZS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwNjAzJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDYwM1QyMTM3MjZaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1iNGY4OTcwNDQ4MjA0ZTg4NTBmZTY0MDdjNDUxNWYyODJjMWU2NTExNGRkMmQzNDYzNjhjYzRjYTY2N2I4NGFhJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.lDkr3XLpZyi1Cj0BElxg6O0SRWitZmooU_Pm3lbcDjQ">

si me ha pasado igual que tu veo el mensaje pero veo el sistema funcionando

One triage detail that may be useful: the screenshots/comments suggest this might be a display/accounting-state problem rather than actual exhaustion, because at least one user reports the app still works while the UI shows 0%.

If that is accurate, the main thing I would check is whether the rate-limit UI collapses an unavailable/failed/partial usage response into a real zero value. A safer behavior would be to distinguish these states explicitly:

• known remaining usage = 0% only when the backend returns a valid exhausted quota snapshot;
• unknown/unavailable usage = show Unavailable, Refreshing, or similar, and keep the last known value visually marked stale;
• stale cached value = include the last successful fetch timestamp if available;
• bonus/promotion entitlement = show the source and expiry separately from the weekly remaining percentage.

That would make this much easier to debug from user reports: “0% because exhausted” is a very different state from “usage snapshot failed or bonus entitlement could not be resolved.”

One triage detail that may be useful: the screenshots/comments suggest this might be a display/accounting-state problem rather than actual exhaustion, because at least one user reports the app still works while the UI shows 0%. If that is accurate, the main thing I would check is whether the rate-limit UI collapses an unavailable/failed/partial usage response into a real zero value. A safer behavior would be to distinguish these states explicitly: known remaining usage = 0% only when the backend returns a valid exhausted quota snapshot; unknown/unavailable usage = show Unavailable, Refreshing, or similar, and keep the last known value visually marked stale; stale cached value = include the last successful fetch timestamp if available; bonus/promotion entitlement = show the source and expiry separately from the weekly remaining percentage. That would make this much easier to debug from user reports: “0% because exhausted” is a very different state from “usage snapshot failed or bonus entitlement could not be resolved.”

Yes, that matches what I’m seeing as well. Several users have now reported the same behavior, so this does not appear to be an isolated account-level issue.

In my case, the percentage dropped from around 77% to 0% within about a minute, even though I had an active 10X bonus that should remain valid until June 5. Other users are also reporting similar sudden drops, and some say the app still works while the UI shows 0%.

That makes me think this may be a usage display/accounting-state bug rather than true quota exhaustion.

I agree that the key thing to investigate is whether the rate-limit UI is treating an unavailable, failed, partial, or stale usage response as a real zero value. The system should only show 0% when the backend confirms a valid exhausted quota snapshot. Otherwise, it should show something like Unavailable, Refreshing, or keep the last known value marked as stale.

It would also help if bonus/promotion entitlement were displayed separately from the weekly usage percentage, including the source, status, and expiry date. Right now, it is very hard for users to know whether 0% means actual exhaustion or simply that the usage snapshot or bonus entitlement failed to resolve.

Now nothing is working at all and it's saying I'm out of usage. Had something like 51% of the week left

<img width="757" height="93" alt="Image" src="https://github.com/user-attachments/assets/dca584aa-5f2f-414a-a46e-af82e19d8210" />

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #26150
• #24887
• #25132
• #24942

Powered by Codex Action

Aaaand we're back? Okay then. Thanks

Ya resuelto el problema

English translation:

What version of the Codex App are you using (From “About Codex” dialog)?

26.601.21317

What subscription do you have?

plus (with a 10x bonus until June 5)

What platform is your computer?

windows

What issue are you seeing?

CRITICAL / URGENT BUG

The system showed an abnormal change in performance/percentage: it went from 77% to 0% in approximately 1 minute.

Context:

• Before the error, the system showed 77%.
• In less than a minute, it dropped to 0%.
• I had earned a 10X bonus.
• That bonus expires on June 5.
• I do not understand why the change occurred; it appears to be a calculation, synchronization, cache, state, or incorrect data update error.

Objective:
Investigate and fix the exact cause of the percentage suddenly dropping from 77% to 0%.

Codex must do the following:

1. Review all logic where the percentage/performance is calculated.
2. Check whether the value 0 is assigned by default when:

• a backend response is missing,
• an API fails,
• state is cleared,
• the component restarts,
• data is incomplete,
• a temporary calculation expires,
• there is a parsing error,
• null/undefined/NaN is received.

1. Check whether an automatic update, cron job, polling, refresh, or listener overwrote the 77% with 0%.
2. Review the 10X bonus logic and its June 5 expiration date.
3. Verify whether the bonus was incorrectly marked as expired, invalid, used, or reset.
4. Review frontend and backend logs around the exact minute when the change occurred.
5. Add protection so the system never changes from 77% to 0% without a validated real cause.
6. If data is temporarily missing, it should show “calculating,” “offline,” or “data pending,” but it must NOT show 0%.
7. Create logs/auditing to record:

• previous value,
• new value,
• timestamp,
• source of the change,
• function that performed the update,
• affected user,
• bonus status.

1. Fix the bug without breaking the rest of the system.

Important rule:
Do not assume that 0% is correct. It must be treated as a possible bug until proven otherwise with real data.

Expected result:

• Identify exactly which function or process changed the value from 77% to 0%.
• Fix the cause.
• Restore or correctly recalculate the percentage.
• Confirm that the 10X bonus remains valid until June 5 if it has not actually expired.
• Add validations to prevent it from happening again.

What steps can reproduce the bug?

Feedback ID: no-active-thread-019e8f62-afd7-7231-8bf1-c642ba8a0cab

What is the expected behavior?

I should still have had 77% of my weekly usage remaining

Additional information

_No response_

<!-- codex-issue-translator -->