Cutting Codex CLI Cost: A Field Manual for Engineering Teams

Where the credits go

Codex CLI is OpenAI's coding agent that runs in your terminal. It reads your files, runs commands, and writes code, and every one of those actions moves text to and from a large language model. You pay for that text in credits (on a ChatGPT plan) or in token dollars (on the direct API). The size and shape of that text, not the cleverness of any one prompt, is what sets your bill.

The cost lives in a handful of places: the model you pick and how hard you tell it to think, the standing background that gets re-sent on every turn (your rules, tool descriptions, and conversation so far), the files and command output you feed it, and the answers it writes back. This report walks each of those levers in order of impact, teaches every term the first time it appears, and ends each part with the specific thing to do. The techniques apply at any size; where a lever matters more for a small, medium, or large team, that is called out.

The three ideas that drive everything else

1. The three token buckets and the repeat discount

Models read and write text in small chunks called tokens (roughly three-quarters of a word each). Codex bills tokens in three buckets, and the price gap between them is where a large share of your savings lives.

You never count tokens by hand. You only need the rule of thumb: more text means more tokens means more cost, and not all tokens cost the same. Here are the three buckets, with illustrative GPT-5.5-class rates used for planning. Treat the exact numbers as placeholders to refresh against the live pricing page; the ratios are the durable part.

Three facts fall out of that table. First, output is roughly six times the price of fresh input, so a chatty assistant is expensive in two ways: the answer itself, and the fact that the answer becomes part of the history that gets re-read on every later turn. Second, cached input is roughly ten times cheaper than fresh input, so anything you can keep identical from turn to turn is nearly free to repeat. Third, because the model has no memory between turns, your standing background gets re-sent on every reply, which is exactly why the cached discount matters so much.

Where this points the rest of the report

Every later section is an application of these three facts. Routing and effort control the expensive output bucket. Caching, context, and AGENTS.md control how much input repeats and whether it qualifies for the discount. Tool and verbosity controls keep both input and output from ballooning. If you internalize the buckets, the rest is just tactics.

2. Model tiering: the menu and how to route Highest leverage

After tool-output reduction and cache discipline, choosing the right model for each task is the single largest cost lever you control. Codex CLI exposes several model backends at very different prices, and the default temptation is to run the most capable one for everything.

A capable, expensive reasoning model and a fast, cheap one read the same files and write the same kind of answer; they differ in how deeply they reason and in price per token. As a planning reference, a mid-tier model is priced near half of the top model per token, and a lightweight "mini" model is cheaper still. The difference looks small per call and enormous per month, because it multiplies across every session.

The model menu

Confirm current names and prices against the live pricing page before you rely on them; model names change often. The shape of the menu is stable even when the labels move.

You set the model in three ways: as the org-wide default in ~/.codex/config.toml, per session with the -m / --model flag, or mid-session with the /model command to escalate when a cheap route is struggling. The goal is to make the cheap model the default and treat the expensive one as a deliberate escalation, not the other way around.

# ~/.codex/config.toml -- make the cheap model the default
model = "gpt-5.4-mini"
model_reasoning_effort = "low"

# Escalate for one session from the command line
codex -m gpt-5.5 --config model_reasoning_effort=high

# Or mid-session in the TUI, only when the cheap route stalls
/model gpt-5.5

Cloud carries a premium over local

Submitting a task to Codex Cloud (the hosted, autonomous execution service) costs materially more than running the same task in the local CLI, on the order of several times more for the container startup, isolation, and unattended-run safeguards. As an illustration, a job that costs a handful of credits locally can cost several times that in cloud. Default to local CLI for interactive development; reserve cloud for long unattended jobs, CI and pull-request integration, or work that genuinely needs cloud isolation, and scope those jobs tightly so they stop the moment the work is done.

A concrete routing policy

Good intentions do not scale; a written policy does. Map each class of work to a model, an effort level, an answer length, and a tool surface, then publish it. This table is the reference you adapt to your own task mix.

The aim is for the cheap model to handle 60 to 80 percent of sessions. When it does, mixed workloads commonly drop 30 to 50 percent in credit cost from routing alone.

Escalate without paying twice

When a cheap route fails, the expensive model does not start from scratch and re-read everything at full price. Hand it a compact escalation packet: which route failed, a short summary of what was tried, a pointer to the evidence already gathered, and the specific open question. That preserves the work and keeps the premium model's input small. If a route escalates often, the route is misconfigured, not the developer; fix the routing rule.

Route on quality-adjusted cost, not raw tokens

The metric that prevents false savings is not token count. It is the cost of an accepted change: credits plus review time plus any retry credits, divided by the number of changes that actually shipped. A cheap route that produces rework can cost more than a premium route that gets it right the first time. Measure accepted-change cost per route and promote a workflow to a richer route when its cheap-route version costs more in the end.