I’d like to suggest a different way to structure Codex usage limits: allow unused weekly quota to roll over, while keeping the overall monthly allocation fixed.

My Codex usage is highly bursty. Some weeks I may finish with a significant amount of quota unused, while during a heavy development week I can hit the weekly cap relatively quickly.

With the current hard weekly reset, unused quota simply disappears. This creates a somewhat counterproductive “use it or lose it” incentive near the end of the reset period, even when I don’t actually need that compute at the time.

A possible model could be:

• Keep a fixed monthly total allocation.
• Give users a normal weekly allowance.
• Allow unused weekly quota to roll over into later weeks within the same monthly period.
• Optionally cap the rollover, for example at one additional week of quota.

For example, if the monthly allocation were equivalent to four weekly quotas, a user who only used 80% of their quota this week could carry the remaining 20% forward and use it during a busier week later in the month.

This wouldn’t require increasing the total monthly compute allocation. It would simply give users more flexibility in how they consume it.

I think this would fit real development workloads much better, since coding workloads are rarely distributed evenly from week to week.

It would also remove the incentive to deliberately consume remaining quota shortly before a weekly reset.

Even a limited rollover mechanism would be a meaningful improvement.

Rollover is relatively uncommon for this kind of SaaS usage limit.

The current limits are presumably designed around individual users having peaky usage that doesn’t all coincide. That allows the service to offer everyone more generous limits overall.

If unused quota could accumulate, even with the same total monthly allowance, users could potentially concentrate much more of their usage into the same period. That makes capacity considerably harder to manage and would lead to current quotas being reduced to balance out that risk.

Fair point — rollover definitely complicates capacity planning.

The real issue for me is occasional spikes, not hitting the limit consistently. My current plan covers ~70% of my baseline, but heavy refactors, debugging sessions, or migrations create short-term compute surges.

I’m basically looking for a way to leverage unused idle quota as a safety net for those surges, without having to permanently upgrade to a higher tier. I get that unrestricted rollover isn’t ideal for predictability, but maybe there’s a middle ground like a temporary burst allowance