OpenAI’s Codex Credits Page Is the Budget Policy Engineering Teams Actually Need
The most important Codex feature this week is not a new editor trick, a bigger context window, or another agent surface. It is a billing control. That sounds like accountant bait until you remember what coding agents have become: long-running, tool-using, sometimes-parallel workers that can burn real money while producing either a useful patch or a beautifully reasoned pile of waste.
OpenAI’s new Help Center guidance for ChatGPT Business explains how workspaces buy credits, enable automatic reload, and set monthly usage limits for Codex activity by seat type or by user. Paired with the newer Codex token-based rate card, this is the kind of operational plumbing engineering teams actually need before “let everyone try the agent” becomes “why did one migration experiment eat the budget?”
The basic model is straightforward. Starting April 2, 2026, ChatGPT Business supports two seat types: standard ChatGPT seats with a fixed monthly cost and Codex seats with usage-based billing. A workspace can mix both. Codex seats require credits for activity, and if the workspace does not have enough credits for a usage-based feature, that feature may be unavailable until credits are added. Credits can be added from Workspace settings → Billing, are valid for 12 months, and may be prompted when the first Codex user is added to a workspace that previously had only standard ChatGPT seats.
That is the administrative version. The engineering version is sharper: Codex is being priced like infrastructure because it is starting to behave like infrastructure.
The default is no limit, which is not a rollout plan
The quiet sentence that should make every platform lead pause is this one: by default, all seats and users have no limits specified. That is a reasonable product default for adoption. It is not a sane operating model for a team rolling Codex out across engineering.
Agent usage is bursty by design. One developer might ask Codex to explain a small test failure. Another might launch several cloud tasks, attach a large repository context, use GPT-5.5, turn on fast mode, generate images, run code review, and keep multiple sessions alive while iterating on a migration. Those are not the same cost profile. “Please be responsible” is not a budget control. It is an apology drafted before the invoice arrives.
OpenAI’s spend controls let admins set monthly credit limits by seat type or by specific user. Per-user overrides supersede seat-specific limits. That is the right primitive because engineering work is not evenly distributed. A senior platform engineer doing a planned repo modernization may need a high or temporary uncapped limit. A new user experimenting with agents probably should not. A standard ChatGPT seat using occasional Codex-like activity should not have the same envelope as a dedicated Codex seat. The control exists; the policy still has to be written by adults.
A practical policy should include bands, not vibes. For example: default Codex seats get a moderate monthly cap, new users get a lower first-month cap, planned migrations get temporary overrides with expiry dates, and automation accounts get separate limits plus owner review. Every override should have a reason, owner, and end date. If that sounds bureaucratic, compare it with explaining unlimited auto-reload after a flaky CI workflow discovered agent labor.
Auto-reload is autoscaling for spend
Automatic reload is useful and dangerous in the same way cloud autoscaling is useful and dangerous. OpenAI lets workspaces define a Minimum balance, a Target balance, and an optional Monthly recharge limit. If the credit balance drops below the minimum, ChatGPT can charge the payment method on file and top up to the target. If the workspace is already below the minimum when auto-reload is enabled, it may charge immediately. Leaving the monthly recharge limit blank allows unlimited automatic reload purchases each month.
That last sentence is the whole risk model. Unlimited auto-reload is fine only if another control plane is watching. Otherwise, the reload system is doing exactly what it was asked to do: preventing interruption, including during waste. A noisy workflow, bad prompt template, runaway automation, or enthusiastic migration batch can keep spending because the product is helpfully keeping the credits flowing.
Teams should set the monthly recharge limit before enabling reload. They should also alert on reload events, not just exhausted balances. Running out of credits is one signal; needing multiple top-ups is a better early-warning signal. If Codex is used for CI repair, scheduled issue triage, code review, Slack-triggered tasks, or cloud tasks, reload events should be visible to the people who own those workflows. Spend without ownership is just distributed denial of budget.
The rate card makes the tuning problem concrete. OpenAI now prices Codex by token type: credits per million input tokens, cached input tokens, and output tokens. GPT-5.5 is listed at 125 credits per 1M input tokens, 12.50 per 1M cached input tokens, and 750 per 1M output tokens. GPT-5.3-Codex is 43.75 input, 4.375 cached input, and 350 output credits per 1M tokens. OpenAI says a typical Codex task using GPT-5.5 may consume 5–45 credits, and that average Codex cost is roughly $100–$200 per developer per month, with large variance depending on model, number of instances, automations, and fast mode.
Those numbers are not trivia. They tell engineers how to design cheaper workflows. Cached input being much cheaper should push teams toward stable instructions, reusable context, and fewer giant one-off prompts. Expensive output should push teams away from rambling transcripts and toward targeted plans, diffs, and concise explanations. The difference between GPT-5.5 and GPT-5.3-Codex should push model routing out of personal preference and into workflow policy: stronger general model when judgment warrants it, coding-specialized model for implementation loops and code review, smaller models for routine local work when quality holds.
Measure accepted work, not agent activity
The worst possible version of agent cost governance is a dashboard that celebrates usage. Credits consumed is not productivity. Agent tasks started is not productivity. Output tokens are definitely not productivity. The metric that matters is useful engineering work per unit of spend: accepted diffs per credit, merged PRs per credit, review time saved, regressions avoided, flaky-test fixes that stayed fixed, and rejected or reverted agent work.
That requires connecting billing controls to engineering telemetry. If a developer hits a limit because they are successfully landing a high-value migration, raise the limit. If a workflow burns credits producing rejected changes, do not raise the limit; fix the workflow. Improve the prompt template, reduce context, choose a better model, add tests, narrow the task, or stop using an agent for that class of work. Budget controls should be feedback loops, not punishment.
Before adding Codex seats broadly, write the rollout policy. Define monthly credit bands by role and workflow. Enable auto-reload only with a monthly recharge cap. Create a documented override path for planned high-value work. Review usage weekly for the first month. Track model mix, fast-mode use, tasks abandoned, credits per accepted diff, and users repeatedly hitting limits. Keep privacy separate from spend: OpenAI notes that spend controls are operational tools and do not replace workspace privacy and chat-visibility rules. That distinction matters. Billing visibility is not permission to read someone’s private chat history.
My take: this is the unglamorous page that decides whether Codex becomes normal engineering infrastructure or another tool that gets throttled after one scary bill. Agent cost governance is not anti-productivity. It is how productivity survives contact with finance, compliance, and the fact that agents can now do work while nobody is looking directly at the meter.
Sources: OpenAI Help Center, OpenAI Codex rate card, OpenAI Developers Codex pricing, OpenAI flexible usage guidance