Today's Codex Quota Value

The estimate expresses a full weekly Codex quota in terms of the public API cost of comparable model usage.

It is a common unit for comparing observed quota consumption over time. It is not your subscription price, an API credit balance, a refund amount, or a guarantee of how much work your account can complete.

For example, if a workload costs $3.40 at the chosen API rates and consumes 0.5 percentage points of weekly quota, scaling that observation to 100% gives $680. That extrapolation assumes the same workload and consumption pattern. A different model, context size or cached-token mix can produce a different estimate.

First, calculate the difference in weekly quota used in percentage points. A move from 40.0% used to 40.5% used consumes 0.5 percentage points, or 0.005 of a complete weekly quota. Do not treat it as 0.5 of the weekly quota or as a percentage increase relative to 40.0%.

Next, multiply each recorded token category by its applicable price per million tokens and add the costs. Uncached input, cached input and output must be kept distinct where the pricing model distinguishes them. If the reported input total already includes cached tokens, subtract those cached tokens before pricing uncached input; otherwise the same usage is counted twice.

Finally, divide the API-equivalent cost by the consumed fraction. Any separately priced tools need their own stated treatment. When there is no comparable public API price for a model or usage category, the dollar estimate should remain unavailable rather than silently using a different model's price.

A plan comparison should hold the model, reasoning level, task, repository revision, starting context, enabled tools and execution mode constant. A model comparison changes the model while keeping the plan, task and other applicable settings fixed. These are different experiments and should have separate records.

The proposed collection process would repeat runs and preserve the individual observations, including failed or excluded runs and the reason for exclusion. Cached and uncached runs should be identified, not silently pooled. A displayed multiplier needs an explicit reference plan measured under matching conditions; an advertised plan name alone cannot establish a measured multiplier.

The chart uses the selected plan's own history. “7 days ago” is the observation exactly seven calendar days before the latest observation; “30 days ago” uses thirty days. Including both endpoints gives 8 daily observations for a complete 7-day series and 31 for a complete 30-day series. The dollar change is today's value minus that earlier value. Percentage change divides that difference by the earlier value and multiplies by 100.

These endpoint comparisons are not a rolling average. The Hero uses Pro 20x and the same 30-day endpoints as the chart's default view. Switching the chart's plan or range updates its curve and the three figures below it; it does not change the Hero. The plan table compares each available plan with its own value 7 days ago.

The line is green when the selected period ends above its starting value, red when it ends below it, and neutral when the two are equal. Smooth connections pass through the observations; the connecting line does not add measured samples. The vertical scale adapts to the selected data with padding and a minimum span, so compare the axis labels and dollar amounts as well as the apparent slope.

Task length, context growth, model choice, reasoning settings and the amount of cached input can affect the observed relationship between tokens and quota. A rounded quota reading also limits precision: if the displayed change is very small, a small reading error can have a large effect on the extrapolated weekly value.

We only compare valid readings from the same weekly quota period.

If the quota resets, calculations for the new period start from the readings taken after the reset. We do not compare readings across that boundary.

If a day has no reliable measurement, the chart leaves a gap instead of filling it with an estimate.

When public API prices change, new measurements use the prices in effect at that time. Historical results keep their original pricing. If we also provide history recalculated at newer prices, it will be clearly labeled:

Recalculated at current API prices

To understand a change in dollar value, look at both quota consumption and API prices: a change in the estimate does not necessarily mean the Codex weekly quota itself has changed.

The update time reflects the most recently completed measurement.

To check a result, you should be able to see:

• When it was measured and which plan was tested;
• The model, reasoning level and standard task used;
• Weekly quota used before and after the task;
• The number of tokens the task actually used;
• The API prices used for the calculation;
• How those inputs were turned into the weekly quota estimate.