Codex pricing on your own key: a per-token cost calculation

The question "codex pricing" has no single answer: when you pay per token, the bill depends on how many calls the agent makes, how long its context is and which model is chosen. But it can be estimated in advance. Below are a formula, three workload profiles with arithmetic, a table by model and a way to compare pay-per-token with a subscription without invented numbers.

What the bill consists of

Codex works as an agent: on every step it sends the accumulated context (the task, files, command results) to the model and receives an answer. So input is much larger than output, and the repeated part of the context lands in the cache.

For GPT models the formula from our documentation is this (cache writes are not billed separately):

cost = fresh input × input price + cache read × read price + output × output price

Here "fresh input" is prompt_tokens minus cached_tokens. Both values come in the usage field of the response, so the calculation can be checked against reality.

We take gpt-6.1-sol, prices as of 18 October 2026, dollars per 1M tokens: input 0.27, cache read 0.013, output 1.32.

Three workload profiles

The volumes below are assumptions for illustration, not measurements. Measure your own on the "Usage" page after the first days of work.

Light: an edit in one file, 20 calls

• total input 300,000 tokens, of which 200,000 from cache and 100,000 fresh;
• output 15,000.

100,000 × 0.27 / 1,000,000 = $0.027 200,000 × 0.013 / 1,000,000 = $0.0026 15,000 × 1.32 / 1,000,000 = $0.0198 Total $0.0494, about $0.05 per session.

Medium: a feature across several files, 60 calls

• input 1,500,000, of which 1,200,000 from cache and 300,000 fresh;
• output 60,000.

300,000 × 0.27 / 1,000,000 = $0.081 1,200,000 × 0.013 / 1,000,000 = $0.0156 60,000 × 1.32 / 1,000,000 = $0.0792 Total $0.1758, about $0.18.

Heavy: a refactor across the project, 150 calls

• input 6,000,000, of which 5,000,000 from cache and 1,000,000 fresh;
• output 200,000.

1,000,000 × 0.27 / 1,000,000 = $0.27 5,000,000 × 0.013 / 1,000,000 = $0.065 200,000 × 1.32 / 1,000,000 = $0.264 Total $0.599, about $0.60.

What that makes per month

Suppose 20 working sessions a month of one profile:

In the heavy profile output (44%) and fresh input (45%) cost the most, although there are five times more cached tokens. The cache makes the repeated part cheaper but does not cancel the cost of what the model writes itself: 0.264 / 0.599 ≈ 0.44, 0.27 / 0.599 ≈ 0.45.

The same heavy profile on other models

We take the same volumes: 1M fresh, 5M cache, 0.2M output. For Claude through Codex (OpenAI format) all input is counted at the input price, the cache discount does not work in this format, so we count 6M at the input price.

Strength index: gpt-6.1-sol 52, gpt-6-sol 49, claude-sonnet-5-5 48, deepseek-v4.1-flash 39. Cheap does not mean suitable: a weaker model takes more steps and retries, and those cost tokens too. Run the same task on two models and compare the final sum on the "Usage" page.

If you specifically want the cache discount for Claude, use tools on the Anthropic format, for example Claude Code (see the post on cache reads and writes↗). For Codex, GPT and other models whose cache is visible in the OpenAI format are more convenient.

Subscription or tokens: how to compare fairly

The terms of official subscriptions change and we do not quote their prices or limits. Compare yourself in three steps:

1. Open the current plan on the service's website and write down the monthly price S and the usage limits.
2. Estimate your workload: how many sessions of which profile per month. Compute the monthly spend T from the table above.
3. Tokens are cheaper while T < S. The boundary in sessions: n = S / session price.

A rule of thumb not tied to anyone's plan: every $10 of balance gives about 202 light sessions (10 / 0.0494), about 56 medium ones (10 / 0.1758) or about 16 heavy ones (10 / 0.599) on gpt-6.1-sol.

With tokens, spending grows strictly with work. A subscription usually has a fixed price and its own limits. Which is better depends on your workload.

How not to exceed the budget

• Set a daily and monthly dollar limit on the key and a list of allowed models. This is described in the key limits docs↗. When a limit runs out you get 429 (key_daily_limit_reached or key_monthly_limit_reached), and further requests with that key are rejected, so spending stops growing.
• Choose a model by task: a cheaper model is enough for routine edits, keep the expensive one for the hard parts.
• Do not let the agent read the whole repository without need. An AGENTS.md file with a short project map cuts unnecessary reads.
• Watch for loops: if the agent repeats the same thing, stop it yourself.

Connecting Codex to the gateway is described in the integration docs↗. A general comparison of subscription and tokens is in the post subscription or tokens↗. Create a key in the dashboard↗.

Payment

The balance is in dollars, top-up from $1. SBP is in rubles at the market rate, and the payment page adds 8.5% on top: for a $12 balance that is 12 × 1.085 = $13.02 in equivalent. Cryptocurrency and MasterCard cards are also available (a fee of about 13%, amounts $2-$594). Current model prices: GET https://api.zukko.pro/v1/models.

FAQ

How much does Codex cost per month?

It depends on the workload. By our assumptions on gpt-6.1-sol, 20 sessions cost roughly $1 (light), $3.5 (medium) or $12 (heavy). Measure your own volumes from the usage field.

Does Codex have a fixed subscription price?

Subscriptions exist at the service itself, their prices and limits change, so look at the current plan on the service's website. On your own key you pay only for tokens.

Why is input so much larger than output?

Because on every step the agent sends the accumulated context again. That is why input price and cache matter, not just the price of the answer.

Can I know the cost of a request in advance?

Approximately, yes: the number of input tokens can be estimated beforehand. For the Anthropic format there is a separate counting method, POST /v1/messages/count_tokens. The exact sum is visible on the "Usage" page after the request.