When your Codex allowance runs out, use an API key instead of credits

The weekly ChatGPT Codex allowance runs out mid-sprint and the usage dashboard offers the obvious fix: another 1,000 credits for $40. We took that offer for a while. Then we benchmarked it, and the top-up turned out to be the same tokens at the same price, delivered on a measurably slower lane.

A credit is four cents

Credits sell in packs of 1,000 for $40, which fixes one credit at four cents. The Codex rate card charges GPT-5.6 Sol 125 credits per million input tokens, 12.50 cached, and 750 output. Multiply it out:

125 credits × $0.04 = $5.00 input, 12.5 × $0.04 = $0.50 cached, and 750 × $0.04 = $30.00 output.

Those are the API's published standard rates for gpt-5.6-sol, to the cent. The same arithmetic holds down the rate card:

Credit rates come from the Codex rate card; the dollar column is the API standard price list.

The parity is deliberate. OpenAI moved Codex off per-message pricing and onto API token usage on April 2, 2026, and its own pricing FAQ says so plainly: "All users may also run extra local tasks using an API key, with usage charged at standard API rates."

So the top-up isn't a discount or a premium. It's the API price list, prepaid.

The credit lane measured 1.5x slower

Price parity was the boring half. The interesting half is that the Codex subscription, included allowance and extra credits alike, reaches a different endpoint than the platform API. In pi, our open-source coding agent, that shows up as two providers for the same nominal model: openai at api.openai.com against an API key, and openai-codex at chatgpt.com/backend-api against the subscription.

We ran a blinded A/B between them on a long agentic TypeScript task: 10 runs per arm, same prompt, same tools, isolated checkouts, interleaved in two simultaneous waves so time-of-day hit both arms equally. Two grader models from a different model family scored every run blind against a precommitted rubric, with provider-identifying strings redacted from their inputs.

Quality came out a tie. Blind consensus medians were 86.0 for the API arm and 85.5 for Codex, a difference of half a point, with permutation p = 0.9752 on means and 0.8297 on medians and blocker rates of 0/10 on both arms. Stated honestly, that's a bounded null rather than proof of equivalence: the design had 90% power to catch a real 5-point effect, so any actual quality difference is almost certainly smaller than 5 points on a 100-point rubric.

Speed was a different story. Median wall-clock was 1296 seconds on the API arm against 1971 on Codex, a ratio of 1.52x at n=10 per arm. Reasoning budgets were matched, at median output and reasoning tokens of 59,149 and 33,119 against 61,201 and 34,253, so this isn't an effort confound. A weekday probe reproduced it at 1544 against 2230 seconds, 1.44x at n=4 per arm, with effective throughput over whole runs of 39.2 output tokens per second against 28.1.

Two details point at the serving path rather than the request format. An exploratory arm routing to the platform API through Cloudflare AI Gateway ran at API speed, a median 1376 seconds over 6 runs. And in the weekday probe, all 20 in-run API errors landed on Codex arms, with zero across the 8 API-arm runs.

Fast mode buys back speed you already had

Codex sells a fix for the latency and documents the price. Fast mode increases supported model speed by 1.5x and consumes credits at 2.5x the standard rate for GPT-5.6 and GPT-5.5, 2x for GPT-5.4.

It works. We injected service_tier: "priority", the same wire field the official Codex CLI sends, where ServiceTier::Fast serializes to "priority". Logging every request, we measured a 1.42x speedup, or 1.53x excluding one outlier run that burned 4293 seconds on 11 API errors. That brackets the documented 1.5x. Worth being precise: we verified the injection from per-request logs, while whether the backend honored the field is inferred from the resulting speed.

The problem is where 2.5x credits lands you. Codex fast mode came out at plain API-standard speed, a median ratio of 1.02x against the API standard arm, or 0.94x excluding the outlier. Meanwhile the API's own priority tier measured 1.47x faster than API standard, medians of 1052 against 1544 seconds at n=4 per arm.

Four lanes, one fixture, medians across 4 runs each:

The dollar column is derived: published rate cards applied to measured token counts, not invoices. The API priority figure additionally assumes the 2x multiplier applies uniformly across input, cached, and output components, which we did not verify against a bill.

Read as a purchasing decision, Codex fast mode is dominated once the allowance is gone. On those derived figures it costs roughly 2.8x API standard for the same measured speed, or about 1.5x API priority while running 1.5x slower.

What credits still get you

Two things, and they're worth naming before you rip the subscription out.

The rate card has one genuine advantage: Codex doesn't bill cache writes, where the API charges $6.25 per million tokens for Sol in short context. An agent loop that rebuilds a large prompt cache repeatedly pays that on the API side and not on the credit side.

The API key path also gives up product surface. It runs Codex in the CLI, SDK, and IDE extension, but not the cloud features (no GitHub code review, no Slack integration), and model availability follows whatever your key can reach.

Everything else in the fine print runs the other way. Credits are valid for 12 months from purchase and don't roll over, they're non-refundable except where required by law, non-transferable, and can't be resold or gifted, and a balance can go negative if a task starts while it's positive and finishes after concurrent usage drains it.

The rule we run now

Burn the included allowance first. It's prepaid and effectively free at the margin, and Codex spends plan usage before touching credits anyway. Past that point, overflow to the API instead of buying extra credits, and reach for API priority when latency actually matters.

Our read on why the lanes differ is interpretation, not measurement: it looks like product segmentation, one set of weights served from differently provisioned pools, with fast mode as the paid bridge. We have no internal knowledge of OpenAI's infrastructure, and nothing here points to degraded weights or bad faith. The quality null is our own best evidence against that reading, and OpenAI's own documentation advertises the 1.5x-for-2.5x trade we measured.

Scope, plainly: one model at max reasoning effort, one task family, one account, one plan, one region, measured over five days in August 2026. Serving behavior and pricing can both change tomorrow.

Which is the real recommendation. Before the next top-up prompt appears in your dashboard, run the comparison on your own tasks: identical model and settings, wall-clock to completion, and a grader who can't see which endpoint produced which answer. If your numbers look like ours, the $40 pack is list-price tokens with a slower delivery and a 12-month shelf life, and the same money spent through a key you already control finishes the work sooner.