The Longer You Use Codex, The More You Need To Save Tokens

I recently analyzed a very long Codex session in full. The result was a little surprising: the expensive part was not the final answers. It was the context repeatedly carried through every loop while Codex worked.

That session lasted almost a whole day and included typical engineering work: reading docs, inspecting logs, editing code, resolving conflicts, opening PRs, deploying, and debugging CI. The main session consumed 119,743,174 tokens, about 15% of my weekly Codex usage at that time. Estimated at GPT-5.5 public API prices, the raw cost would be about $79.28. Output was only 219,381 tokens, less than 0.2% of the total. The bulk was input, especially cached input reused in a long session.

Important clarification: these dollar numbers are raw public API cost estimates, not my actual marginal cost as a Codex subscriber. Subscription limits, platform scheduling, caching, and product pricing are separate. The point is not “Codex is expensive.” The point is to understand where tokens go.

The Short Version

First, long sessions are not free memory. Prompt caching lowers cost but cached input is still counted.

Second, the most expensive turns are often not the wordiest answers. They are cross-repository, cross-system, multi-tool tasks such as deployment migration, PR conflict resolution, production debugging, and issue triage.

Third, saving tokens is less about making answers shorter and more about clarifying task boundaries: split sessions when the topic changes, pass handoff summaries between sessions, put large logs in files, and move stable rules into AGENTS.md, skills, or config.

Fourth, do not make the workflow awkward just to save tokens. Optimize obvious waste: huge pasted logs, irrelevant history, repeatedly pasted fixed rules, and unrelated tasks in one session.

How I Estimated Cost

The data came from local Codex session logs containing token_count records. I used GPT-5.5 public API pricing:

Type	Price
Uncached input	$5.00 / 1M tokens
Cached input	$0.50 / 1M tokens
Output	$30.00 / 1M tokens

Formula:

uncached_input = input_tokens - cached_input_tokens

cost =
  uncached_input / 1,000,000 * 5.00
  + cached_input / 1,000,000 * 0.50
  + output_tokens / 1,000,000 * 30.00

Two mistakes are easy to make:

• reasoning_output_tokens is already included in output_tokens.
• API raw cost is not the same as subscription marginal cost.

For personal usage, the more useful number may be share of weekly usage. That one long session used about 15% of my weekly quota; writing the original article itself used about 1%.

Why A Short Question Can Be Expensive

With an agent, a short user message is not sent alone. A single turn may include:

• System and developer instructions
• Repository context summary
• Conversation history
• Recent tool results
• Available tool definitions
• User request
• Opened file snippets, error logs, test output

So a question that looks like a dozen words may be packaged with hundreds of thousands of tokens. And one task is often a sequence of model calls: analyze, read files, edit, run tests, handle failure, summarize.

That is why shortening the final answer only saves a little output cost. The bigger savings come from reducing repeated context and unnecessary material.

Which Conversations Cost The Most?

The top expensive interactions all had a familiar shape: cross-system, cross-repository, and verification-heavy.

Typical expensive categories:

Deployment and configuration migration. These tasks read docs, Kubernetes or CI config, online environments, workflows, and deployment results. The cost is in confirming that existing services are not broken.

Batch issue triage. One issue may be cheap. Ten issues require reading context, code, PR history, and sometimes running tests.

Multi-repository PR and release work. Code changes in one repository, dependency updates in another, deployment config in a third. Each repository adds context and tool loops.

Long-log debugging. Hundreds or thousands of pasted log lines are fully counted, though only a few lines may matter.

Document generation. Reading source documents, code, and producing a polished document involves reading, summarizing, rewriting, formatting, and correction loops.

By rough task category, most cost fell into code/PR/release and Q&A/debugging. Data statistics were cheap.

The lesson: agentic coding cost is mostly input-driven. It depends on how many steps the agent takes, how much material it reads, and how much it retries.

Prompt Caching Helps, But It Is Not Free

Prompt caching is crucial for long sessions. Without caching, repeatedly processing huge contexts would be slower and more expensive.

But caching is a discount on repeated prefixes, not free memory.

Engineering implications:

Practice	Effect
Put stable rules early	Easier prefix cache hits
Put dynamic input later	Avoid breaking the prefix
Avoid changing system-level rules frequently	Fewer cache misses
Do not paste huge logs directly	Lower uncached input
Split long tasks by deliverable	Less history in each turn

AGENTS.md, skills, tool descriptions, and stable workflows are good cacheable context. One-off logs, temporary PR diffs, and ad hoc SQL should be read from files or commands as needed.

My Token-Saving Workflow

One Session Per Topic

The easiest way to lose control is to use one conversation for unrelated work: fix CI in the morning, inspect a database in the afternoon, write a blog at night, review PRs in between.

Better split by deliverable:

• One PR, one session.
• One production incident, one session.
• One document, one session.
• One data analysis, one session.

If continuity is needed, ask Codex to generate a handoff summary and start a new session with it. A summary of a few hundred or a few thousand tokens is cheaper than carrying a massive history.

Do not over-split tiny questions. The real split point is topic change.

One Deliverable Can Span Multiple Repositories

“One repository per session” sounds clean, but real work often spans backend, frontend, and deployment config. Splitting too hard can lose context.

Better rule: one deliverable per session. If multiple repositories are involved, clearly state the current phase:

• Which repository is active now?
• Which files may be edited?
• What validation comes next?

Start New Sessions For One-Off Research

Temporary research, unfamiliar libraries, unrelated documents, and different article topics should get their own sessions. Bring back only the conclusion summary, not the whole exploration.

Put Stable Content In Files

Do not repeatedly paste branch rules, test commands, release steps, or writing guidelines. Put them in:

• AGENTS.md
• skills
• README files
• local config

Then ask Codex to read the relevant source when needed.

Put Large Logs In Files

Instead of pasting thousands of lines into chat, save logs to a file and ask Codex to search or inspect targeted sections:

The full log is in tmp/ci.log. First search for ERROR, traceback, failed, and exception. Then inspect the 80 lines around the most likely failure.

This turns “always include everything” into “read what matters.”

Use Side Conversations For Side Questions

Small unrelated questions should use a side channel when available or a fresh lightweight session. Do not pollute a long engineering thread with unrelated research.

What Not To Optimize Too Much

Do not reduce context so aggressively that Codex can no longer work safely. For engineering tasks, context is not waste by default. It is how the agent avoids blind edits.

The goal is not minimum tokens. The goal is minimum waste while preserving enough context for correct work.

Closing

The more you use Codex, the more important token hygiene becomes. Not because every token is scary, but because agent workflows naturally carry context through many loops.

The most effective habits are simple:

• Split by deliverable.
• Summarize when handing off.
• Keep stable rules in files.
• Read logs from files instead of pasting them.
• Use skills for repeated workflows.
• Avoid mixing unrelated tasks in one long session.

Codex is valuable precisely because it can work with rich context. Good token management is not about starving it. It is about feeding it the right context at the right time.

WeChat

Follow ZiCode on WeChat

If this post was useful, you can follow later updates on WeChat as well.

X / Twitter

Follow @ax2_zicode

Faster technical notes, short thoughts, and new-post alerts are posted on X.

X Open X Profile @ax2_zicode