Codex Pricing and Usage Limits: What Each Plan Delivers, Measured

Codex costs $0 on Free, $8 on Go, $20 on Plus, and $100, $200 or $500 a month on Pro. In the four complete weeks from Oct 12 to Nov 8, my $200 account recorded $2,409 of work at today’s API rates, roughly 12 times its monthly price. Roughly 97% to 98% of the input was cached: I was paying for a coding workflow that repeatedly reused context, rather than buying that much fresh text.

TL;DR — Buy a tier and use all of it: the allowance is prepaid, and whatever is left at the weekly reset is gone. Either start on Free, Go or Plus and run it to the limit in every window, or, budget permitting, take Pro 200 or Pro 500 and commit to filling it, which I think is the fastest and cheapest way to learn this kind of work. In between, buy Pro 100 when the five-hour window interrupts daily work. Fill the allowance with finished work on the smallest model that does the job, not with Astra at maximum reasoning. Choose Business for managed seats and one bill. For a small, occasional job, I would pay per token before taking on a monthly fee.

A script on this machine has read the account’s usage meter every few minutes since Oct 11, alongside readings saved by my coding sessions since Sep 5. I use those readings to answer the question I had before paying: what kind of working week does each price buy?

What Codex costs today#

I re-read these US dollar prices on Nov 14, 2026. OpenAI’s Codex pricing lists the individual plans and included features.

Pro 200 is open to new subscribers again. OpenAI says Pro 100 and Pro 500 now have twice their earlier allowance, while the lower Pro 200 allowance doubled to match the higher one. All three Pro tiers have no five-hour limit; Pro 500 adds Ultrafast. Current Pro tiers.

Business Standard is $25 per seat monthly, or $20 a month billed annually. Premium is $125 monthly, or $100 annually, with more usage and no five-hour limit. I would budget for at least two paid seats: two Standard seats start at $40 a month equivalent on annual billing, and mixed Standard/Premium seats are allowed. Enterprise and Edu are quoted separately. Business seats and billing.

Who each tier fits#

• Free and Go: I would start here for lightweight Luna sessions and occasional small edits; Go costs $8 a month. Move to Plus when available access or the amount of work gets in the way, and stay free when coding is an occasional experiment.
• Plus: I would buy the $20 plan for a few focused sessions a week. Move to Pro 100 if the five-hour reset repeatedly interrupts a working day; move down when a small API budget covers the month’s work.
• Pro 100: I would buy it for regular steering without a five-hour clock, at half the Pro 200 bill. Move to Pro 200 when the weekly allowance keeps running out; move to Plus when most weeks are short and interruptible.
• Pro 200: This is my reference for a busy week of pairing and unattended runs. I would move to Pro 500 when the weekly cap repeatedly stops useful work, and back to Pro 100 if I stop leaving workers running or regularly finish with plenty unused.
• Pro 500: I would pay for the largest Pro allowance when overnight work needs more room or Ultrafast saves enough of my time to justify it. I would move back to Pro 200 when I stop using that extra capacity or speed.
• Business: I would choose it for member management, workspace controls and one bill, then assign Premium seats to people who need more usage and no five-hour limit. If I only need a personal coding plan, I would keep the individual subscription instead of buying two seats.

Buy a tier, then use all of it#

A subscription is prepaid inference. The bill is the same at 30% used and at 100%, and the included allowance resets each week whether I used it or not. Whatever is left at the reset is money I spent on nothing. That leaves two sensible ways to buy, and I would pick one on purpose.

Buy low and run it out. Take Go or Plus and plan to reach the limit in every window. A small allowance makes me decide which work deserves a session, and the limit arrives soon enough that I learn where it is. If I run out early most weeks, I have my evidence for the next tier, collected for $8 or $20 instead of a month of a larger plan I half use.

Or buy high and commit. If the budget allows, take Pro 200 or Pro 500 and treat the allowance as a quota to fill. That is more work than one person can steer by hand. Filling it means learning to write a task an agent can finish alone, to run several at once, to leave work going overnight, and to check results I did not watch being made. I think this is the fastest and cheapest way to learn agentic coding: each mistake costs a few percent of a week I had already paid for. The four weeks in my records would have cost $2,409 at API rates.

I do not always manage it. The Nov 4 to Nov 11 window, the one complete week in the reset table below that ran its full seven days, peaked at 82%. I paid for the other 18% and did not use it.

Fill it with work, not tokens. There is a way to cheat: run Astra at the highest reasoning setting for everything, and the meter reaches 100% with little effort from me. On Plus, OpenAI estimates 5–45 local messages per five hours on GPT-6 Astra, 15–160 on GPT-6.1 Sol, 35–285 on GPT-6.1 Terra and 350–3,000 on GPT-6 Luna. Current usage limits. An allowance emptied on Astra holds a fraction of the tasks the same allowance holds on Terra. The target is finished work, so I choose the smallest model that completes the task and spend the rest of the allowance on more tasks.

I would argue that choice costs little. Today’s smaller models are better than the frontier models of the previous generation, and the least they can do is approaching, if it has not already passed, the hardest thing most coding projects ask of them. That is my judgment from using them; this page does not measure it. The price list points the same way: the API still lists the previous generation’s GPT-5.5 at $5 input and $30 output per million tokens, against $2 and $10 for Sol and $1 and $5 for Terra. OpenAI’s API pricing.

Put your week into the picker#

I enter the hours I actively steer, the workers I leave running all week, and the most I want to spend each month. One worker means a process alive for the week, including its idle time; I turn it down when runs are only occasional.

The picker chooses a plan within my budget and tells me when I need to pace the work.

How the five-hour and weekly limits behave#

The five-hour window limits work within a short period; it is not five hours of keyboard time. The weekly balance has its own reset. On Plus and Standard Business, OpenAI currently estimates 15–160 local GPT-6.1 Sol messages per five hours. Pro removes that short window, which is the first reason I would move up from Plus. Current usage limits.

My Pro account reported a weekly limit and no five-hour limit. The complete Nov 4 to Nov 11 window peaked at 82%; the current window is at 42% through Nov 14. Here are the last twelve reset windows.

10 of the twelve windows ended early. The account held banked reset credits, and I still had 3 unused on Nov 14. My saved credit counts cover Nov 13 and Nov 14 and stay at three; they do not identify which earlier restarts used a banked credit and which came from OpenAI.

I read the next reset time on the account rather than assuming Monday morning or exactly seven days after the last session. When the date changes, the spending plan for the rest of my week changes with it.

What a week of work consumed#

In Nov 2 to Nov 8, I started 412 sessions and recorded 2.11B input tokens and 7.7M output tokens, worth $370 at today’s Sol API rates. The usage meter consumed 0.99 weekly allowances across two reset windows. In the table, 1.83 means 1.83 allowances, or 183%: that week’s window was reset early, so I could spend more than one allowance in seven calendar days.

Those weeks make the $200 plan easy to justify for the way I work: I repeatedly use an agent in a large codebase, then let other runs continue unattended. A person making a handful of small edits has a different bill and may get better value from Plus or the API.

The Codex vs Claude Code comparison looks at the work the agents delivered. For the other subscription ladder, the $200 Claude tier is Ultra (formerly Max 20x); my measured Claude plans guide follows its usage windows. The inference plan comparison puts these choices beside other plans and API prices.

How I check Codex usage#

In an active CLI session I enter /status. In the app I open Settings → Usage, or the Codex usage dashboard. I write down the allowance, percentage, reset time and credit balance. I check the label: 20% remaining is 80% used. The context-window percentage is conversation space, a separate meter. OpenAI’s usage instructions.

Before buying a larger tier, I take readings before and after representative sessions over several days. I keep the model and speed fixed and include anything that ran overnight. If both windows appear, I record both; a short-window reset does not refill the weekly one. I compare readings within the same reset window, then start a new row when it resets.

I also check the speed setting. Fast spends included usage at 2.5 times Standard; Ultrafast at 8 times for the same model. A change there can explain why a familiar week starts hitting the cap sooner. Speed and usage.

What happens at the cap, and what a banked reset buys#

I have seen both outcomes at the cap. In my August to October records, 826 requests were refused at the usage limit, mostly before any work began. After I added paid usage credits, two later windows stayed at 100% while work continued and the credit balance fell.

Under today’s rules, an active turn can finish after the included allowance runs out, subject to fair use. For the next turn I check the notice: I can wait, buy extra credits, use an available reset, or change plans. Support does not reset the limit on request. A banked full reset refreshes both the five-hour and weekly windows and moves the weekly reset date. Limit and reset rules.

The 3 banked resets I still held on Nov 14 expire on Nov 30, Dec 1, Dec 12. I check both the expiry and the next natural reset before spending one: if the natural reset arrives first, the saved reset may add little useful time.

Paid credits and banked resets solve different problems: credits pay for more work after included usage, while a reset refills the allowance. I check which one the account is offering before spending money or using a saved reset.

When I would pay per token#

For a small, irregular job or a CI run with a dollar ceiling, I would price the API first. For daily work like the four weeks above, I would buy the subscription. My Sol Standard calculation is:

API dollars = uncached input millions × $2 + cached input millions × $0.10 + output millions × $10.

I subtract cached input from total input before applying the first rate. OpenAI’s API pricing is separate from subscription credits.

A small run with 100,000 input tokens, 90,000 cached, and 10,000 output costs $0.129 under that formula; ten cost $1.29. If I were buying a subscription only for those runs, $20 would pay for about 155 of them through the API, $100 about 775, and $200 about 1,550. Below that volume I would pay per token; above it I would check whether the subscription’s allowance holds the work.

If I already have unused Plus capacity, a small job adds no subscription fee. I then compare the API with the cost of extra credits or upgrading, rather than charging the whole subscription to that job again. When I only want one small run, the API avoids the monthly minimum.

How I measured this#

I used 316,401 usage readings covering 18 reset windows from Sep 5 to Nov 14, and 22,227 saved sessions. The meter covers the whole account, so I cannot separate steering from workers. For the picker I apply the busiest measured three-hour pace, 6.939 percentage points an hour, to steering, and the account-wide average of 0.297 points per worker-hour to workers; the two overlap, making this a conservative planning model. A worker means 168 hours alive per week, including idle time. I measured Pro 200; for the other tiers I scale recommendations along OpenAI’s published ordering, which gives no numeric quota ratios.

I counted tokens by the week in which they were recorded and left out sessions spawned or copied from other sessions to reduce repeated history. Session starts and tool calls are activity, not completed tasks. Some older sessions have disappeared since my earlier measurement, so I retain its cap findings separately and never add overlapping totals. Nov 14 and the last week are partial. I group reset times within twenty minutes and fill sample gaps only up to six hours; the Nov 2 week has 94.11% coverage. Allowances used are lower bounds on the meter changes I observed.

The API comparison prices my recorded token mix at GPT-6.1 Sol Standard, short-context rates; it is not an invoice or a claim that Sol would finish the same tasks identically. I exclude explicit cache writes, long context and tool charges, and do not add reasoning tokens again because they are already in output. I calculate totals before rounding the displayed weekly dollars. The account’s allowance changed during the measurement period, and paid credits and early resets also affected what it could finish. I did not redeem a reset as part of this study.

Tested with#

I checked this with Codex CLI 0.169.0 and Claude Code 2.1.325 installed. The usage readings run from Sep 5 to Nov 14, 2026, with cap history from my earlier August to October measurement. I re-opened every cited OpenAI pricing and limits page on Nov 14 and confirmed the listed prices and rules.

A weekly check compares the installed clients with the versions here and flags a refresh when either moves a minor version or the data passes ninety days. I also refresh when pricing or limits change. If you want the full readings behind the tables, ask me through the contact page.

— Jed