Avoiding Double Payment When Running Codex in the Cloud

Codex runs on two billing systems, and they never speak to each other. A team can pay for a ChatGPT subscription and an OpenAI API key at the same time, for the same underlying models, and watch both meters spin independently, with neither one offsetting the other.

Why Codex has two separate billing meters, not one

Authenticate with a ChatGPT login and usage draws against the plan's included allowance first, then against purchased credits once that allowance runs out. But if you authenticate with an OpenAI API key instead, every call bills at standard API token rates from the first token, with no included buffer and no connection back to whatever subscription might also be active on the same machine or the same team. Flowith's Codex pricing guide puts the core mistake in direct terms: "Do not treat a ChatGPT subscription, Codex credits, and OpenAI API billing as one interchangeable pool." The two systems share models, not ledgers. That distinction is the whole problem this piece exists to untangle, and it carries more weight now than it used to: eesel's pricing breakdown documents that on April 2, 2026, OpenAI switched from flat per-message billing to token-based credit billing across Plus, Pro, Business, and the newer Enterprise plans, which made subscription-side costs more variable and harder to forecast. Variable costs on one meter are manageable on their own. If variable costs run on one meter while uncapped costs run on a second, unconnected meter, teams can end up paying twice for work they thought was already covered.

Which workflows land on which meter

Which meter records a charge depends on the authentication method active at the moment the call runs, not on which feature a developer thinks they're using. The Codex web dashboard, the VS Code extension signed in with a ChatGPT account, the CLI through codex login, the iOS app, automatic GitHub PR code review, and the Slack integration all draw against subscription allowances. That is the subscription track, and most of a team's day-to-day, human-driven work lives there. The API key track serves a different purpose. OpenAI's own pricing documentation describes it as "great for automation in shared environments like CI," which makes clear that CI/CD pipelines, scripted runs, and shared agent environments are the intended use case for key authentication, not an alternate route into the same subscription-covered features. Some capabilities simply don't exist on that path at all: OpenAI's documentation states outright that the API key option comes with "no cloud-based features (GitHub code review, Slack, etc.)," meaning long-horizon background task execution and the cloud integrations that come bundled into Plus and above are off the table once a workflow moves to key authentication. The riskiest failure mode in this split is a silent one. If a machine has both an inherited OPENAI_API_KEY and an active ChatGPT login, Codex can route silently through the API key instead of the subscription, so a developer who believes a session is subscription-covered ends up generating API token charges with no signal that the routing changed. WorkOS's applied AI team has described how it manages this risk in practice: its morning routine batches tasks across codebases before any manual work starts, and keeping explicit clarity about which surface handles which tasks keeps the resulting bill legible.

The April 2026 credit system's effect on double-billing costs

The April 2026 pricing change didn't create the two-meter split, but it raised the stakes of ignoring it. Before the switch, subscription usage billed per message, a flat and predictable unit that made it straightforward to estimate monthly cost regardless of how complex any individual task turned out to be. eesel documents the transition precisely: OpenAI moved Plus, Pro, and Business from per-message billing to token-based credits on April 2, 2026, with Enterprise following on April 23, 2026. Token-based billing ties cost to the actual size and complexity of each task rather than to a flat per-interaction rate, so two tasks that each counted as "one message" under the old system can now cost wildly different amounts depending on how much the model actually had to read and generate. That shift alone would matter even for a team watching just one meter. It matters more for a team running two meters at once, because both the subscription side and the API side are now variable rather than fixed, and a team's exposure to overspend compounds when neither surface gives a flat number to budget against. Mode selection adds another layer of unpredictability: Fast mode draws down credits at a higher rate than Standard mode for the same underlying model, so a developer running Fast mode through a subscription while CI automation runs Standard mode through an API key will see two different credit burn patterns that don't map cleanly to either the work being done or the path that produced it. You can read a credit summary and still struggle to infer what any given workflow actually cost, because the per-unit cost is no longer fixed on either side of the split.

What the subscription plans cover, tier by tier

Knowing what a subscription tier actually includes is the only way to judge whether a workflow belongs on that tier or should be pushed to the API instead, and getting that judgment wrong in either direction wastes money. The following reflects Axon's reading of OpenAI's Codex and general pricing documentation. The Free tier costs nothing and offers limited trial access with no cloud integrations at all, no GitHub review, no Slack, and no published numeric usage ceiling. It functions as a basic sanity check on whether Codex understands a given codebase before a team commits to paying for it. Go costs $8 a month and covers lightweight local coding tasks without cloud task delegation; eesel notes that the per-feature documentation on Go is sparse, and that most developers evaluating Codex seriously are better served testing Plus instead, since the $12 monthly difference buys the entire cloud feature set that Go lacks. Plus, at $20 a month, functions as the practical baseline for a working developer: it includes every Codex surface (web, CLI, VS Code extension, iOS), cloud task delegation with GitHub repo access, automatic PR code review, and Slack integration, with usage limits that operate on a rolling five-hour window. Pro splits into two separate tiers. Pro 20x costs $200 a month and includes more usage than the lower tier (OpenAI no longer publishes a specific usage multiple for new subscribers); it is the original Pro plan repositioned after a $100 entry tier launched beneath it, so Axon flags that any source describing Pro as a single $100 plan is quoting only the entry point of what is structurally a two-step tier. OpenAI's pricing documentation lists Pro plans at $100, $200, or $500 a month, with the $500 tier adding Astra Ultrafast access. Business runs $20 per user per month billed annually, or $25 per user per month billed monthly, with a two-user minimum; its base usage limits match Plus, but it adds larger VMs for cloud tasks, SAML SSO, MFA, a dedicated workspace, and data excluded from training by default. Axon notes that any source describing Business as pay-as-you-go is wrong: both billing bases, annual and monthly, are published directly on OpenAI's pricing page. Enterprise and Edu require contacting sales directly, carry no fixed rate limits, draw from a shared credit pool, and add SCIM, EKM, RBAC, audit logging, data residency controls, and usage monitoring through a Compliance API. One structural change sits above all of these tiers and affects planning regardless of which one a team is on: OpenAI's documentation states that GPT-5.5 retires from ChatGPT, ChatGPT Work, and Codex on all plans on October 14, 2026, while the OpenAI API is not affected by that retirement, so teams relying on GPT-5.5 through a subscription will need to migrate to a different model while API-key users continue uninterrupted. OpenAI's own documentation states that ChatGPT Work usage shares the same pricing, credits, and usage limits as Codex, so teams active on both surfaces draw from a single combined pool, and allowance can disappear faster than either surface alone would suggest.

What the key-authenticated path costs

The API path carries no subscription fee and no included allowance of any kind. Every token consumed bills at standard API rates from the very first call, which makes this the meter without a built-in buffer, and the one most likely to produce an unpleasant surprise for a team that hasn't set an explicit limit before its first unattended run. The asymmetry that causes the most confusion involves prompt caching. On the API path, cache writes bill as their own separate line item. On the subscription credit path, they do not. An agent loop that rebuilds a large prompt cache on each iteration accrues that cost specifically on API billing, and a team trying to estimate its API spend by looking at credit summaries from the subscription side will undercount, because that cost simply isn't visible there. The practical discipline that WorkOS engineers apply addresses this directly: burn the included subscription allowance first, since it's prepaid and effectively free at the margin, and once that allowance is exhausted, overflow to the API. Extra purchased credits now price at API-equivalent rates, so buying them directly through the API saves you nothing in dollar terms, but it does help you avoid the confusion that comes from mixing the two paths for the same workload. Rates on the API side change over time, so check them against OpenAI's current documentation. The structural point that holds regardless of the specific numbers in effect at any moment is that the API path has no ceiling by default, so a spending limit set in the OpenAI console before the first unattended CI run is the one safeguard standing between a team and an open-ended bill.

The four most common paths to paying both meters at once

Double payment is the predictable outcome of specific engineering habits that put subscription-authenticated and API-key-authenticated work on the same project without anyone tracking which workflow hits which meter. The most common path starts with the environment-variable trap described earlier: a developer's machine carries an inherited OPENAI_API_KEY alongside an active ChatGPT login, Codex routes silently through the key instead of the subscription, and every session that developer assumed was covered by the monthly plan instead generates a separate API bill running in parallel. A second path runs through CI and automation. OpenAI's own documentation recommends the API key specifically for shared environments like CI, so teams that wire Codex into their pipelines correctly land those jobs on the API meter; problems appear when a developer also manually triggers overlapping work through the subscription-authenticated web dashboard or CLI for the same task, paying for the same unit of work twice across two unconnected systems. A third path comes from the shared pool between ChatGPT Work and Codex: because both surfaces draw on the same credits, limits, and pricing, a team that treats them as separate budgets can exhaust its allowance faster than expected and then overflow into purchased credits or API calls without realizing the two surfaces were never separate accounts to begin with. The fourth path is the mode mismatch described in the section on the April 2026 pricing change: a developer running Fast mode through the subscription while automated jobs run Standard mode through the API key produces two different credit and token burn rates for work that, from a planning standpoint, looks identical on paper, and reconciling the resulting bill after the fact is far harder than preventing the overlap by assigning each workflow to one meter from the start.