1. Problem Statement
Codex uses short-term and weekly usage limits to manage computational demand and ensure fair access.
While these restrictions serve legitimate operational purposes, they can be challenging for subscribers whose development workloads vary significantly throughout the month.
A user may have substantial unused allowance during one week but exhaust their weekly limit during another, interrupting active development until the next reset.
We propose an optional system that gives users more control over the timing of their included usage without introducing unlimited accumulation.
2. Proposed Solution: Codex Usage Banking
Introduce Codex Usage Banking, an account-level mechanism that allows eligible subscribers to convert a portion of their unused included allowance into a limited, temporary reserve.
The design prioritizes user choice, transparency, predictable resource consumption, and compatibility with existing usage limits.
A. User-Controlled Deposits
-
Manual deposits are the default behavior.
-
Users explicitly select how much eligible allowance they wish to deposit.
-
Optional automatic deposits may be enabled through account settings.
-
Users who do not participate experience no changes to their existing usage limits.
Every deposit should display the allowance deducted, resulting bank balance, conversion rate, and expiration date before confirmation.
B. Conversion and Accounting
As an initial implementation, deposits would draw from the user’s remaining weekly included allowance.
A proposed 2:1 conversion ratio would apply:
-
100 equivalent usage units deducted from the weekly allowance.
-
50 equivalent units credited to the Usage Bank.
The original allowance must be deducted immediately to prevent double spending.
Because short-term and weekly limits can apply simultaneously, unused five-hour capacity must not be treated as an independent balance that can be converted without additional safeguards.
Usage should be measured through normalized, model-weighted units rather than percentages transferred directly between different quota windows.
The proposed rate is adjustable and should be validated through controlled testing.
C. Banking Limits and Safeguards
For an initial pilot, consider:
-
Maximum new banked credits per weekly cycle: equivalent to 25% of the standard weekly allowance.
-
Maximum accumulated bank balance: equivalent to 50% of the standard weekly allowance.
-
Credit validity: 60 days from each successful deposit.
-
No transferability between accounts.
-
No cash value, refunds, or conversion into API credits.
-
Separate accounting for purchased credits, promotional resets, and banked usage.
-
No banking of already exhausted, expired, or previously redeemed allowance.
Existing short-term rate limits, fair-use restrictions, and applicable account or workspace policies remain in force.
All proposed percentages and expiration periods are configurable pilot parameters, not fixed requirements.
D. User-Controlled Withdrawals
Users can manually redeem saved capacity when additional usage is needed.
Recommended consumption priority:
-
Included plan allowance.
-
Redeemed banked usage.
-
Purchased usage credits, where available.
Banked usage supplements the applicable weekly allowance but does not independently remove short-term rate limits.
Withdrawals must be recorded transparently and must never cause the same deposited entitlement to be redeemed more than once.
E. Optional Future Extension: Five-Hour Allowance Conversion
After evaluating the initial banking system, OpenAI could explore an additional feature allowing users to convert eligible unused short-term capacity into limited bonus usage.
Unlike ordinary weekly allowance rollover, this mechanism may create additional usable entitlement.
It should therefore be treated as a separate, explicitly capped benefit with its own eligibility rules and issuance budget.
A 50% conversion rate, strict weekly bonus cap, and clear cost accounting could be evaluated during a limited pilot.
This extension should not be required for the initial implementation.
3. Example User Scenario
Assume a hypothetical weekly allowance of 1,000 normalized usage units.
A subscriber has 300 unused units remaining.
They voluntarily deposit 200 units:
-
Weekly allowance decreases by 200 units.
-
The Usage Bank receives 100 units.
-
The remaining weekly allowance becomes 100 units.
-
The 100 banked units remain available for eligible future use, subject to expiration and account limits.
At a later point, when the user’s included weekly allowance is exhausted, they can redeem the banked units while remaining subject to applicable short-term limits.
No usage is counted twice.
4. User Experience
The Usage dashboard could display:
-
Current included allowance.
-
Eligible capacity available for deposit.
-
Banked usage balance.
-
Deposit and withdrawal controls.
-
Conversion rates.
-
Expiration dates.
-
Transaction history.
Each operation should require clear user authorization.
Optional reminders could notify users before unused eligible allowance or stored banked usage expires.
The experience should remain consistent across Codex interfaces that share the relevant account allowance.
5. Expected Benefits
For subscribers:
-
Greater flexibility across uneven development workloads.
-
Reduced disruption during intensive project periods.
-
More transparent management of included subscription usage.
-
Voluntary participation without changes to the default experience.
For OpenAI:
-
Configurable limits on accumulated usage.
-
Better visibility into demand patterns.
-
Potential improvements in subscriber satisfaction and retention.
-
A measurable basis for testing flexible allowance management.
Although rollover does not inherently increase the total amount of allowance issued, shifting consumption between periods can affect actual utilization and peak infrastructure demand. These effects should be evaluated during the pilot.
6. Suggested Rollout
Phase 1: Limited pilot of manual weekly allowance banking.
Phase 2: Evaluate conversion rates, usage patterns, infrastructure impact, and user satisfaction.
Phase 3: Consider optional automatic deposits and capped five-hour allowance conversion if economically sustainable.
7. Closing Recommendation
This proposal is not a request for unlimited Codex usage.
It is a request for a transparent, optional system allowing subscribers to manage when eligible usage is consumed while preserving OpenAI’s ability to control infrastructure costs.
Existing purchased-credit and promotional-reset mechanisms demonstrate related concepts, although a new allowance-banking feature would require additional accounting and entitlement management.
The objective is simple: More control for users, predictable resource management for OpenAI, and fewer unnecessary interruptions to development workflows.
We would welcome feedback from the Codex community and OpenAI product team regarding feasibility, conversion ratios, appropriate caps, and potential pilot implementation.
Thank you for considering this proposal.