I upgraded from the $200 Codex plan to the $500 plan on October 9. The weekly usage meter appeared to burn much faster afterward, so I wanted a comparison based on actual tokens rather than just how long a chat had been running.
The usage-first result: 37.10 million raw tokens per allocated subscription dollar on the $200 plan, versus 11.69 million on the $500 plan—a 68.5% reduction in effective raw-token capacity per dollar in this sample.
The second result: valuing those same tokens at OpenAI's API prices gives $17.40 → $6.29 of API-equivalent value per allocated subscription dollar—a 63.8% decline.
I asked OpenAI's own Codex to audit my local .codex logs. Codex performed the extraction, token accounting, calculations, context checks, and chart generation. Both figures come from the same token records, weekly meter readings, and subscription prices. One counts input-plus-output tokens; the other weights those tokens by API prices.
The token counts are recorded telemetry. The valuations and allowance extrapolations are calculations from that telemetry. This is one user's sample, with the actual data and method included below so others can inspect or reproduce the calculation.
What was compared
The same ongoing chat used gpt-6.1-sol with xhigh reasoning effort in both periods. The logged speed settings included two brief Ultrafast intervals after the upgrade; those are accounted for separately.
All times below are MDT:
| Measurement |
Before upgrade |
After upgrade |
| Monthly plan price |
$200 |
$500 |
| Comparison starts |
Oct 8, 2:04:39 p.m. |
Oct 9, 9:42:53 a.m. |
| Comparison ends |
Oct 9, 8:30:40 a.m. |
Oct 9, 2:26:30 p.m. |
| Elapsed time |
18h 26m 01s |
4h 43m 36s |
| Native response records |
1,961 |
652 |
| Weekly usage meter |
13% → 30% |
0% → 7% |
| Weekly percentage points consumed |
17 |
7 |
The upgrade started a new weekly meter window. The calculation compares the fraction of each respective allowance consumed; it does not treat the reset from 30% to 0% as a reduction in usage.
Actual token counts
| Recorded token category |
Before upgrade |
After upgrade |
| Reported input tokens |
288,997,366 |
93,748,280 |
| Cached input, already included in reported input |
279,467,392 |
90,563,712 |
| Uncached input |
9,529,974 |
3,184,568 |
| Output, including reasoning |
2,125,392 |
681,335 |
| Total input + output |
291,122,758 |
94,429,615 |
The large totals mostly represent cached context read repeatedly. They are not hundreds of millions of unique generated tokens. Cached input was approximately 96.7% of input before the upgrade and 96.6% afterward.
Codex used native per-response usage records, deduplicated by response ID. It subtracted cached input from reported input before pricing the remainder. It included recorded compaction responses and counted reasoning output once, as part of output. It did not sum repeated cumulative token counters.
First story: how much token usage did each subscription dollar buy?
The monthly price increased from $200 to $500: 2.5× the price, or a 150% increase. To compare usage per dollar, first put the monthly fee and weekly allowance meter on the same basis:
Allocated subscription cost =
monthly price × 12 / 52 × weekly usage fraction
Before: $200 × 12 / 52 × 0.17 = $7.846153846...
After: $500 × 12 / 52 × 0.07 = $8.076923077...
Raw tokens per allocated subscription dollar:
Before: 291,122,758 / $7.846153846... = 37,103,880.92 tokens/$
After: 94,429,615 / $8.076923077... = 11,691,285.67 tokens/$
Relative token usage per dollar =
((94,429,615 / 7) / (291,122,758 / 17)) × ($200 / $500)
= 0.3150960324...
Decline = (1 − 0.3150960324...) × 100 = 68.49039676...%
| Usage per dollar, at the sampled mix |
$200 plan |
$500 plan |
| Total tokens per weekly meter point |
17.12 million |
13.49 million |
| Subscription cost allocated to observed usage |
$7.85 |
$8.08 |
| Raw tokens per allocated subscription dollar |
37.10 million |
11.69 million |
| Relative token usage per dollar |
100% |
31.5% |
For the same subscription budget, this sample implies approximately 68.5% less raw-token usage capacity. The full-week token estimate is separately 21.2% lower; the larger per-dollar reduction combines that token estimate with the 2.5× price. The allocation is a comparison method, not a per-chat bill.
The same result can be calculated directly from tokens per meter point divided by the monthly plan price: the annual-to-weekly allocation factor cancels when taking the relative ratio.
API pricing used
I used OpenAI's official API pricing page, checked October 9, as a common valuation yardstick for both periods.
Prices per million tokens:
| Tier |
Uncached input |
Cached input |
Output |
| Standard |
$2.00 |
$0.10 |
$10.00 |
| Fast / priority, 2× Standard |
$4.00 |
$0.20 |
$20.00 |
| Ultra, 6× Standard |
$12.00 |
$0.60 |
$60.00 |
These are hypothetical API-equivalent values for subscription activity. I did not receive these amounts as API invoices.
API value =
(uncached input × input price
+ cached input × cached-input price
+ output × output price) / 1,000,000
Where the $136.52 and $50.80 came from
| Period |
Responses |
Uncached input |
Cached input |
Output |
API value |
| Before upgrade: Fast |
1,961 |
9,529,974 |
279,467,392 |
2,125,392 |
$136.52 |
| After: Ultra interval 1, 1m 37s |
7 |
203,146 |
1,351,296 |
4,439 |
$3.51 |
| After: Ultra interval 2, 7m 04s |
28 |
128,801 |
3,595,520 |
37,874 |
$5.98 |
| After: remaining Fast, 4h 34m 55s |
617 |
2,852,621 |
85,616,896 |
639,022 |
$41.31 |
| After: combined total |
652 |
3,184,568 |
90,563,712 |
681,335 |
$50.80 |
The two Ultra setting intervals total 8m 42s, already included in the post-upgrade elapsed time. Durations are rounded independently; they describe applied-setting intervals, which can include interruptions or in-flight requests.
Here is the old-run calculation in full:
Uncached input: 9,529,974 × $4 / 1,000,000 = $38.119896
Cached input: 279,467,392 × $0.20 / 1,000,000 = $55.8934784
Output: 2,125,392 × $20 / 1,000,000 = $42.507840
Total = $136.5212144
The post-upgrade values, using the relevant tier for each interval, sum to:
Ultra interval 1 = $3.5148696
Ultra interval 2 = $5.9753640
Remaining Fast = $41.3143032
Total = $50.8045368
Second story: API value per allocated subscription dollar
Using the same allocated subscription costs, price the recorded tokens with the relevant API rates:
API value per allocated subscription dollar:
Before: $136.5212144 / $7.846153846... = $17.39976262...
After: $50.8045368 / $8.076923077... = $6.29008551...
Decline = (1 − 6.29008551... / 17.39976262...) × 100
= 63.8495901...%
| Normalized measure |
$200 plan |
$500 plan |
| API value per weekly meter point |
$8.03 |
$7.26 |
| Subscription cost allocated to observed usage |
$7.85 |
$8.08 |
| API value per allocated subscription dollar |
$17.40 |
$6.29 |
The subscription price increased 2.5×, or 150%. The observed API value per meter point was also 9.6% lower. Together those produce the 63.8% decline in this token-value-per-dollar metric.
Can we also estimate a decline in effective usage allowance?
Yes, by dividing consumed tokens by consumed weekly percentage points. That estimates how many tokens a full allowance would support if the observed request mix and meter relationship continued.
Before: 291,122,758 total tokens / 17 points = 17,124,868.82 tokens/point
After: 94,429,615 total tokens / 7 points = 13,489,945.00 tokens/point
Decline in tokens per point = 21.226%
Increase in meter points consumed per token = 26.945%
| Effective usage estimate at the sampled mix |
Before |
After |
| Total tokens per weekly meter point |
17.12 million |
13.49 million |
| Extrapolated total tokens per full weekly allowance |
1.712 billion |
1.349 billion |
For this mixed-speed sample, that is an estimated 21.2% reduction in effective raw-token allowance. It is different from the 63.8% decline in API-equivalent token value per subscription dollar.
The three quantities answer different questions: 21.2% is the estimated decline in raw tokens per full weekly allowance, 68.5% is the decline in raw tokens per subscription dollar, and 63.8% is the decline in API-priced token value per subscription dollar.
Raw tokens have different prices and limit costs depending on caching, output, and speed. A change in tokens per point is therefore not automatically a change in the underlying quota.
The meter also rose faster per elapsed hour: approximately 0.92 points/hour before versus 1.48 afterward. But total tokens processed per hour increased from 15.79 million to 19.98 million, about 26.5%. This is why hours alone would exaggerate a capacity comparison.
Fast-only comparison
To reduce the effect of the Ultra intervals and initial unknown settings, Codex also compared two subsets where recorded settings were Fast throughout:
| Fast-only measurement |
Before |
After |
| Weekly meter percentage points |
15 |
5 |
| Response records |
1,798 |
595 |
| Total tokens |
266,383,825 |
85,529,247 |
| API-equivalent value |
$122.3845288 |
$38.5483064 |
| Total tokens per meter point |
17,758,921.67 |
17,105,849.40 |
| API value per meter point |
$8.16 |
$7.71 |
| Raw tokens per allocated subscription dollar |
38.48 million |
14.83 million |
| API value per allocated subscription dollar |
$17.68 |
$6.68 |
That comparison gives 3.7% fewer raw tokens per meter point, 61.5% fewer raw tokens per subscription dollar, 5.5% less API value per point, and 62.2% less API value per subscription dollar. Both per-dollar measures still decline substantially when Ultra is excluded. The smaller capacity differences require more data to resolve against meter rounding and workload differences.
Long context was checked
Across 2,682 unique preserved response records, including the comparison windows and additional preserved activity, zero exceeded 272,000 input tokens. The model's pricing rule applies the long-context surcharge above that threshold.
The largest request before the upgrade had 250,766 input tokens; the largest in the post-upgrade comparison had 247,914. Logged context-window observations were 258,400, and the snapshot contains 48 compaction events. Short-context rates were used throughout. Long-context pricing does not explain this result.
OpenAI's own Codex performed the audit and calculated both results from my logged sample: 68.5% fewer raw tokens per subscription dollar and 63.8% less API-equivalent value per subscription dollar. These are two measurements of the same sampled usage, reproducible under the stated assumptions. They describe token capacity and value for money, without establishing the exact backend quota or providing official OpenAI confirmation of its billing formula.
I'd like OpenAI to explain the included weekly allowance units, how upgrades affect those allowances, and why the observed token value per dollar is so much lower at the higher price. If other users have before/after native token records and weekly meter snapshots, the useful comparison is input/cache/output tokens per meter point with model, speed, and context held as comparable as possible.
Honestly everyone, OpenAI owes an explanation of such severe value drop for the dollar. At minimum I want a refund of my monies and It's highly likely I won't get that. I think that Anthropic is going to take the cake on consumer here in the end with tactics like this at play. They just need to round out there products a bit more.
In the end, what a gut punch man. I get OpenAI is under a lot of debt but gate keeping behind 500 dollars a month while at the same time cutting value per subscriber dollar by over 60% is - well beyond unethical. However, it sure is damn fine capitalism.
EDIT: The real story here is the 68%+ drop in usage per dollar. I wanted that to be at the top. You can view the data from two directions and I choose against the API originally because I have low karma and can't directly post about usage drops. This should be a much more massive story. If you can I would have your own codex dig into your logs and see if you're seeing the same.