Codex CLI token usage: reading it, then lowering it

Codex CLI sessions have the same shape as any agent session: a small question wrapped in a large amount of context. What differs is that a meaningful part of that context is ambient. It is there before you type anything.

Ambient input: the part you did not ask for

Before a request, Codex has its instructions and information about the tools available to it. As of September 2026, Codex can defer discoverable MCP tools behind tool search, so not every detailed schema must be loaded at the start. A server you do not use can still contribute discovery metadata; the amount depends on enabled tools and the CLI version.

This is measurable without spending quota, which is unusual and worth knowing about:

$codex debug prompt-input

Run it on your own machine and read the total. The result depends on your enabled plugins, skills, MCP servers and CLI version, so measure your setup rather than relying on a generic ambient-input figure.

Session input: the part you can control

On top of ambient input sits the same thing every agent accumulates: files read, commands run, and the transcript so far. The levers are the ones that work everywhere.

• →Name the file rather than letting the agent find it.
• →One session per task, closed when the task is done.
• →Filter noisy command output before it reaches the transcript.
• →Put a ceiling on context and keep it there.

Running Codex under a budget

capsul drives the Codex CLI you are already signed into, so your existing ChatGPT plan is what answers. Continuation, usage and reasoning effort are reported back where you can see them.

$npm i -g @penra/capsul

$capsul ask 'add pagination to the search endpoint' --budget 3000

Reading the numbers honestly

Two cautions that apply to every token benchmark, including ours. First, weighted input and raw input are different measurements: cached input is billed at a fraction of fresh input, so a comparison that ignores caching flatters whichever arm caches better. Second, a saving on one task is not a saving on the next. Our own table has a row where capsul uses more weighted input, and it is published rather than dropped.