Subscription/reset pricing may incentivize multiple accounts and increase concurrent compute demand

Summary

The current Codex subscription and reset structure appears to create an unintended economic incentive for heavy users to maintain multiple paid personal accounts rather than purchasing additional usage through the intended reset or API mechanisms.

This matters for two reasons:

1. Multiple accounts can be cheaper than purchasing equivalent additional subscription resets.
2. If those accounts are used concurrently, the behavior may increase simultaneous compute demand rather than simply shifting where the same amount of usage is billed.

Reports from users describing the operation of multiple accounts simultaneously suggest this is not merely a theoretical pricing edge case.

How I reached this conclusion

Start with a heavy Codex user on a $200/month Pro subscription.

If that user exhausts the included usage and purchases four additional resets during the month:

• Base subscription: $200
• Four resets at $80 each: $320
• Total monthly cost: $520

Now compare that with purchasing two separate Pro accounts:

• Account 1: $200
• Account 2: $200
• Total monthly cost: $400

The multi-account approach is therefore:

$520 - $400 = $120 cheaper per month

for a user who would otherwise purchase four resets.

That creates a straightforward financial incentive to open another account instead of purchasing the additional usage through the existing reset mechanism.

The API does not create the same incentive because API usage is directly metered and billed according to consumption.

Capacity impact

The issue becomes more significant if multiple accounts can operate Codex workloads concurrently.

A user purchasing additional metered usage increases consumption through one billing identity.

A user operating two or more independent subscription accounts may instead obtain multiple independent usage allocations and potentially run them at the same time.

That means the pricing loophole may have two effects at once:

Revenue leakage + increased concurrent compute pressure.

For example, if only 1,000 heavy users chose two $200 accounts instead of spending $520 through one account:

• Expected spend through subscription + resets: $520,000/month
• Spend through two-account strategy: $400,000/month
• Difference: $120,000/month

At 10,000 users, the same behavior would represent a $1.2 million monthly difference under those assumptions.

The more important infrastructure concern is that those users may also be capable of running workloads from both accounts concurrently, multiplying peak demand during periods when Codex capacity is constrained.

Why this appears structural

The system currently separates identity, subscription allowance, and additional compute purchasing in a way that makes obtaining another subscription potentially cheaper than purchasing more usage on the original subscription.

Economically, the example becomes:

• Additional usage through the intended mechanism: $320
• Another complete subscription allocation: $200

When the substitute is cheaper than the intended expansion mechanism, users are financially encouraged to choose the substitute.

Potential fix

A cleaner structure would tie paid usage expansion to a single user identity.

One possible model:

• One individual user identity
• Separate Personal, Work, and Business environments under that identity
• Additional Codex capacity purchased as resets, credits, or metered usage
• API usage remains consumption-based
• Multiple environments would not require users to create additional personal accounts

Alternatively, Codex usage beyond the subscription allowance could move entirely to a metered API-style billing model.

The important design principle is that purchasing additional legitimate capacity should not cost more than circumventing that mechanism by creating another subscription.

Conclusion

The suspected bug is not simply that users can possess multiple accounts.

The issue is that the pricing structure may make multiple subscriptions the economically rational choice for heavy Codex users.

If those subscriptions also provide independent concurrent compute allocations, the structure simultaneously:

• reduces revenue relative to the intended reset path,
• encourages account multiplication,
• increases potential concurrent compute demand,
• and adds capacity pressure at exactly the point where additional capacity is most expensive.

This should be investigated as both a billing/incentive-design issue and a capacity-management issue.

Existing evidence of multi-account behavior

There are already multiple issues in this repository showing that users maintain, create, or switch between multiple ChatGPT/Codex accounts in practice:

• #44411 — the reporter states they registered a new Pro 20x account after encountering repeated capacity errors, then compared the new account with the older one.
• #35484 — the reporter explicitly describes switching Codex to another authorized account when one user's Codex usage is exhausted, and requests separate ChatGPT/Codex account sessions to make that workflow easier.
• #46133 — the reporter states, "I have three ChatGPT Plus accounts," and compares behavior across all three in the same environment.
• #40259 — the reporter states, "I use two separate Codex accounts," and compares their weekly usage behavior.
• #44443 — the reporter identifies their setup as "ChatGPT Pro (20x) — 2 separate accounts."
• #38157 — the reporter says the same quota behavior was observed across multiple separately subscribed Pro accounts.
• #43337 — the reporter compares one Pro 20x account with a second account with the same subscription under comparable conditions.

These reports do not by themselves prove that all multi-account users are doing so to avoid reset pricing. They do show that maintaining and switching among multiple paid accounts is an existing, observable workflow. In several cases, the motivation is directly tied to capacity or exhausted usage, which makes the pricing incentive described above materially relevant rather than purely hypothetical.

Start by reviewing the subscription and reset pricing assumptions in this issue, then compare the linked reports about multiple-account usage. No repository files, entry points, or tests are identified, so the first step is to locate the billing, identity, and capacity-management systems involved. Done would require an agreed design that addresses the pricing incentive and its concurrent-capacity implications.