Back to Blog
GuidesEngineering

Codex Usage: Where the Tokens Actually Go

Shiplight AI Team

Shiplight AI Team

Updated on July 31, 2026

View as Markdown
Illustrated Shiplight blog cover: a token budget meter with the largest slice consumed by retries and oversized tool responses rather than the task.

The first month of running a coding agent across a team produces a bill that surprises someone. Not because any single task was expensive, but because the cheap-looking ones were not, and nobody was watching the parts that add up.

This covers where agent spend actually goes, what reduces it, and the number worth optimizing instead of the obvious one.

Where the tokens go

Context, on every turn. The entire conversation is resent with each step. A long session sends everything again and again, so cost grows faster than the work does. A twenty-step task does not cost twenty times a one-step task; it costs more.

Tool definitions. Every connected MCP server advertises its tools, and those advertisements sit in context on every turn whether used or not. Connect a dozen servers and a slice of your budget is a catalog the agent mostly ignores. See Claude MCP for why this also degrades quality.

Tool responses. The big one, and the least visible. A tool returning a full API payload spends context on every subsequent turn, not just the one that called it. One chatty tool can dominate a session.

Retries. A failed action, a bad edit, a misread file. Each attempt is billed. Retries are usually the largest avoidable slice, and they do not appear as a line item anywhere.

Exploration that stopped mattering. Files read twenty steps ago that turned out to be irrelevant. Still in context, still billed on every turn since.

What reduces it

Be specific up front. The single largest saving. An agent that has to discover which files matter reads many that do not, and carries all of them for the rest of the session. Naming the modules in the instruction is worth more than any configuration change.

Plan before wide changes. Approving an approach before edits begin costs a plan. Discovering the misunderstanding in a finished twelve-file diff costs the diff, the revert and the retry. See Claude Code plan mode for the general version.

Connect fewer servers. Per project, not everything you have installed.

Prefer tools that return little. If you write your own, return what is needed for the next decision rather than everything available. Build an MCP server covers the design rules.

Delegate high-read, low-output work. "Find every call site of this function" reads a lot to produce a short answer. A subagent does that in an isolated context and returns the answer without the forty files it read.

Start fresh sessions. When a task is done, the context that got you there is pure cost on the next one.

The number that actually matters

Comparisons between agents usually cite tokens per task, and on that measure Codex consistently completes comparable work on fewer tokens than the main alternatives.

That is a real advantage and it is the wrong optimization target on its own. Cost per accepted change is the number that matters. A task completed for a third of the tokens that needs two more human passes is not cheaper.

Only your own team on your own codebase can measure this. Two weeks of real tickets, counting how often output ships without rework, tells you more than any published benchmark. See Codex vs Claude Code for the wider comparison.

There is a second-order version worth naming. The cheapest possible run is one where the agent does the work, reports success, and nobody checks. That looks excellent on a usage dashboard right until the bug reaches production, at which point the incident costs more than a year of tokens.

The verification line item

Verification does add tokens. Opening a browser, walking a flow and asserting on the result costs something on top of writing the code.

Worth being precise about how much, because the assumption that it is expensive is usually wrong. Browser tooling built on structured accessibility snapshots costs roughly a quarter of what screenshot-and-vision approaches consume for the same work, which is why the design matters. See Playwright MCP.

And it is a one-time cost that produces a durable asset. Shiplight writes the successful check into your repository as an intent-based test, so it runs on every future change without an agent involved. You pay tokens once and get a regression check forever, rather than paying an agent to re-verify the same flow every week. Web applications; native mobile is not in it.

That framing is the useful one for budget conversations: verification is not an ongoing token cost, it is a one-off conversion of tokens into a permanent test.

Frequently Asked Questions

1

Why is my agent usage higher than expected?

Usually retries and oversized tool responses rather than the tasks themselves. Both are billed on every subsequent turn and neither appears as a line item.

2

Does Codex use fewer tokens than other agents?

On comparable tasks, consistently. The number that decides value is cost per accepted change, which depends on how often output needs rework in your codebase.

3

How do I reduce token usage most effectively?

Be specific about which files matter, so the agent does not discover them by reading everything. That saves more than any configuration change.

4

Do MCP servers cost tokens even when unused?

Yes. Every connected server's tool list sits in context on each turn, which is why connecting fewer per project is both cheaper and better for tool selection.

5

Is browser verification expensive?

Less than assumed, if the tooling returns structured accessibility snapshots rather than screenshots. It is also a one-time cost that produces a permanent test.

Related Reading