There are two common ways to pay for Codex: buy a ChatGPT plan that includes Codex usage, or use your own API key and pay per token. Many people ask directly which is cheaper, but there is no single answer, because a coding agent's consumption pattern is completely different from ordinary chat.

This article avoids unit prices that will soon be out of date. Instead, it gives you a method you can apply yourself: understand the two billing models, see where the tokens actually go, and then use budget caps to contain the risk.

Note: OpenAI, Codex, and ChatGPT are trademarks of OpenAI. This article is a technical explanation of billing models only and has no affiliation with or agency relationship to OpenAI. Plan quotas, model unit prices, and billing rules change; refer to official pages and the site's model pricing.

1. Distinguish the two billing models first

The subscription model is "monthly fee plus quota." Several ChatGPT plans include Codex usage, and higher tiers usually offer wider quotas, model ranges, and concurrency. When the quota runs out, you generally wait for a reset, buy credits, or upgrade. The advantage is predictable billing; the disadvantage is that quotas and rate-limit rules are set by the platform, which makes it hard for teams to allocate costs precisely to projects.

API pay-as-you-go is "pay for what you use." Input tokens, output tokens, and cache reads and writes are priced separately. Models can be switched per task, and a gateway can split projects across different keys. The advantage is flexibility and auditability; the disadvantage is that once an agent enters a loop or repeatedly reads large files, the bill can exceed expectations.

Dimension Subscription (ChatGPT plan) API key pay-as-you-go
Billing unit Monthly fee plus included quota or credits Per token
Bill predictability Relatively high Medium to low, depending on usage
Model choice Within the plan's coverage Depends on the models the key can access
Multi-project allocation Weaker Stronger, split by key or project
Best for Individuals with steady daily use Teams, automation, and highly variable usage

2. Why coding agents burn tokens quickly

Ordinary chat is one question and one answer. A coding agent runs a loop: read the repository, call tools, edit files, run tests, then correct again. For the same task, the token structure is very different:

  • System prompts, tool definitions, and project instructions re-enter the context on every turn.
  • File reads, code searches, and command output accumulate repeatedly as tool results.
  • Multiple rounds of tool calls make the history longer, and every later input turn pays for all the earlier content.
  • Failed retries, context compaction, and summaries add extra consumption.
  • Output token counts are usually lower than input, but their unit price is often higher.

So when evaluating Codex pricing, do not ask "how much does one question cost"; ask "how many turns does a complete task take, and how much context does each turn carry." This also explains why subscriptions and pay-as-you-go feel so different: light tasks are a good deal on a subscription, while heavy tasks may cost more through the API, or may cost less because you can switch models.

3. How to estimate pay-as-you-go costs

You can make a rough estimate with the formula below. Read the unit prices from the current pricing page; do not use old numbers beyond the illustrative structure here.

Cost per turn ≈
  input tokens × input unit price
+ cached read tokens × cache unit price
+ output tokens × output unit price
+ cache write cost (if the vendor prices it separately)

Monthly cost ≈
  cost per turn × average turns per day × working days
+ retries and failed requests
+ context compaction and summarization overhead

In practice, the most reliable method is to pick a representative task, look at how many input, output, and cached tokens it actually consumed in the gateway usage log, then multiply by the number of similar tasks per day. Do not guess from "how many characters fit on a chat page"; an agent's input volume is often several times to dozens of times that of chat.

4. How to choose for three typical scenarios

Steady individual use. If you change code, write tests, and read documentation every day at a stable volume, a subscription is usually simpler. Upgrade only when the quota is insufficient; there is no need to start with the highest tier.

Small teams with multiple projects. API plus a gateway is the better fit: issue keys per person and per project, split the bill, and tier models by task. The catch is that you must set budget caps; otherwise one agent loop can consume a month's budget.

Automation and bursty tasks. CI bots, batch refactors, and overnight scans are better suited to API pay-as-you-go, because each task has a clear start and end, and cost stays controllable with concurrency limits and retry caps.

Many teams end up with a hybrid: subscriptions for people, API for automation and shared tools. The two models are not mutually exclusive. The key is not to let the same person use both quotas without recording it.

5. Caching and context: the two most underestimated variables

Caching saves money, but only under conditions. It usually requires a stable request prefix: the same system prompt, the same tool definitions, the same file fragments. Insert a changing section in the middle and the cache behind it may stop matching. Put stable content such as project instructions and coding standards first, and temporary questions last; hit rates are usually better that way.

Context size has a more direct effect. The larger the repository, the more files are read, and the longer the retained conversation, the higher the input tokens on every turn. Controls include excluding build artifacts and dependency directories, reading only relevant modules, starting new sessions promptly, and having the agent search before reading files. A model with a larger context window is not automatically cheaper; it only lets you put in more content, and you still pay for actual tokens.

6. Budget caps and a control checklist

  1. Create separate keys per person, per project, and per environment; never share one key across the whole team.
  2. Set quota caps and balance alerts in the gateway console. Start low, run for a week, then adjust.
  3. Limit concurrency and automatic retries so failed requests are not billed repeatedly.
  4. Exclude build directories, dependency directories, logs, and secret files in project configuration.
  5. Tier your models: use strong models for hard tasks and cheaper models for renames, comments, and boilerplate.
  6. Review a usage report weekly, split by project and model, and disable a key immediately if something looks abnormal.
  7. Give automation its own budget instead of mixing it with human usage.

These measures are more effective than hunting for a cheaper unit price everywhere. Most overspending is not caused by a high unit price but by runaway context, runaway retries, or runaway keys.

7. Decide with two weeks of data

Do not migrate everything at once. In the first week, keep your current subscription and run a representative set of tasks through an API key, recording turns, input tokens, output tokens, and cache hit rates for each task type. In the second week, run the same tasks at a different model tier and compare quality and cost.

After two weeks you will have three numbers: average cost per task, tasks per person per month, and the share of failed retries. Multiply the first two and add the extra cost implied by the third, and you have a realistic pay-as-you-go baseline. Compare that baseline with the monthly fee and quota of a subscription plan; the conclusion is usually more reliable than any universal answer. If you need a unified endpoint and usage reports, start by signing up for the ZSQH AI Gateway; specific models and billing follow the model pricing page.

FAQ

Can I use a Codex subscription and an API key at the same time?

Yes. Codex CLI supports both account login and a custom API key or compatible gateway. A common team pattern is subscriptions for people and API for automation, but record it internally to avoid double payment and mixed quotas.

Why is my API bill much higher than expected?

Check three things first: whether the context is too large, whether retries are frequent, and whether there are unnecessary concurrent tasks. Input tokens often dominate the cost of a coding agent, and reading irrelevant files plus unnecessarily long conversations are the most common causes.

Does caching always save money?

Not necessarily. Caching requires a stable request prefix to hit, and some vendors price cache writes separately. If prompts change often or models switch frequently, the benefit drops noticeably. Use usage logs to confirm the hit rate first.

Should the team issue one key per person?

Sharing one key is not recommended, and neither is giving each person multiple keys without records. Issue keys per person and set sub-quotas per project; this lets you locate anomalies and revoke access when someone leaves. Keep keys in environment variables or a secrets manager, and never commit them to a repository.

Will these prices change later?

Yes. Plan quotas, model unit prices, cache rules, and credit mechanisms can all change. This article explains only the calculation method and promises no fixed price. When budgeting, use the current information on official pages and the site's model pricing, and recalculate periodically.

Next steps

The key to judging whether Codex pricing is worthwhile is not memorizing a unit price but understanding your own task structure: how many turns per task, how much context per turn, and what share of failed retries. Once you quantify those three, the choice between subscription and API becomes clear. If you need unified key management, budget caps, and per-project billing, sign up for the ZSQH AI Gateway; model scope and billing are described on the model pricing page.

Related reading: