Trying To Reduce Codex Token Burn Without Adding More Noise

In Short

• Problem: my Codex sessions were burning through quota faster than felt reasonable, especially when a repo had noisy logs, large diffs, repeated discovery, and long instruction files.
• What I tested: a local Token Frugal workflow, installed into copied versions of two real repos, with Codex session JSONL used to measure input, cached input, output, reasoning, total tokens, and estimated API-equivalent cost.
• Result: the principle still makes sense, but the lab did not prove a clean token reduction in my setup. On a smaller repo, the direct prompt became cheaper. On a bigger, process-heavy repo, the extra layer often made the session more expensive.
• Lesson: before adding hooks, wrappers, agents, or more AGENTS.md rules, I probably need a V2 that harmonizes and simplifies the instruction stack I already have.

The Starting Point

The trigger was a very ordinary ChatGPT note. I was trying to turn a vague frustration, “Codex is burning through tokens too fast”, into something I could actually test. That note became a local repo I called Token Frugal.

I had the same reflex many people have when an agent feels too expensive: tell it to be more careful, ask it to be concise, add a rule, add a helper, add a hook.

The idea was reasonable. Instead of letting Codex read raw logs, full JSON files, broad trees, huge diffs, and repeated repo instructions, I wanted a small set of habits:

• compact reads instead of full dumps;
• bounded command output;
• short handoff files;
• raw logs saved locally instead of pasted into the conversation;
• a small AGENTS.md section rather than a second manual;
• hooks that warn before noisy commands;
• real measurement from Codex session JSONL instead of a rough character count.

In principle, I still think this is the right direction. If the model sees less useless context, it should spend fewer tokens and make fewer decisions from noise.

But my lab made the conclusion less clean.

What I Measured

I used two copied local repos.

CodexTodo is the smaller and more direct one. The tasks were targeted: inspect a few known files, run a specific Web UI test, summarize the doctor check, and report the result.

BannerGenerator is heavier. It already has more process around it: orchestrator rules, agents, runbooks, validation policy, repo-specific conventions, and safety instructions. The task was still bounded, but the repo itself already carried a lot of operating context.

The measurement came from Codex session JSONL. For each run, I extracted the model, input tokens, cached input tokens, output tokens, reasoning output tokens, and total tokens. I also computed an API-equivalent price estimate from the parsed model. That estimate is useful for comparison, but I do not treat it as proof of how a ChatGPT or Codex subscription quota is billed.

I also separated two costs that are easy to mix together:

• startup: installing Token Frugal into a repo;
• recurring use: the prompts run after the repo has already been bootstrapped.

That distinction matters. A bootstrap can be a one-time investment. It should be measured because it is real work, but it should not be counted as if it happens on every task.

The detailed trace is not inside this article. I kept the command matrix, session IDs, raw stdout paths, and token tables in the lab’s RESULTATS.md. If I later publish a public lab repo, that is the artifact that needs to move with it. Here I only keep the numbers needed to explain the lesson.

The Numbers Were Mixed

The final run made that split visible.

Measure	Total tokens	Estimated cost
Token Frugal startup	1,455,983	$0.444158
Four recurring prompts after startup	939,012	$0.229363
Previous four-run reference	872,385	$0.237918

The recurring run was slightly cheaper by estimated cost, but it used more total tokens. That alone is already a warning against an easy headline.

The repo-by-repo behavior was more useful than the aggregate.

On CodexTodo, the direct prompt on the bootstrapped repo was better than the earlier baseline:

CodexTodo run	Total tokens	Estimated cost
Earlier baseline	181,956	$0.047421
Bootstrapped repo, direct prompt	138,461	$0.033401

That is the version of the experiment where Token Frugal looked like it helped. The repo was small enough, the task was narrow enough, and the guidance probably reduced unnecessary discovery.

On BannerGenerator, the effect went the other way:

BannerGenerator run	Total tokens	Estimated cost
Earlier baseline	190,528	$0.038538
Bootstrapped repo, treatment-style prompt	270,349	$0.057467

That repo already had too many layers. Token Frugal did not replace them. It sat on top of them.

The Big Repo Problem

The lesson from BannerGenerator is not that compact context is bad. It is that context discipline can become another source of context.

That repo already had orchestrator instructions, agent definitions, runbooks, validation rules, process conventions, and project-specific safety rails. When Token Frugal entered that environment, Codex had one more system to understand before doing the actual task.

In the treatment run, Codex still spent tokens learning wrapper syntax:

• tfctx --help;
• tfctx read --help;
• tfctx test --help.

This is exactly the kind of cost I was trying to avoid. I had added a tool to reduce unnecessary exploration, and the model explored the tool.

On a large repo, the fixed cost of “how am I supposed to work here?” can dominate the small savings from bounded reads. If the existing rules are already dense, a new rule layer can make the agent more cautious, more verbose, and more likely to explain the process instead of moving through the task.

The Small Repo Lesson

CodexTodo was different.

The direct prompt on the bootstrapped repo stayed focused. It read the requested slices, ran the targeted Web UI test, summarized the doctor check, and preserved the useful validation signal:

tests/test_web_ui.py: 60 passed

That is closer to the original goal. The Token Frugal surface gave Codex enough guidance to avoid broad exploration without making the repo feel like a maze.

But even there, the wrapper still had a quality problem.

When the same kind of task went through tfctx test, the Web UI test failed:

56 failed, 4 passed

The failure was tied to local socket binding. The direct command passed, the wrapped command failed. That means the wrapper was not neutral for this class of validation.

For me, that matters more than the token count. A tool that saves tokens but changes the meaning of a test is not ready to be trusted as a default path.

What I Think Happened

The lab points to three causes.

First, Token Frugal helps most when the repo has a simple instruction surface. On CodexTodo, the guidance could reduce discovery. On BannerGenerator, it joined an already crowded instruction system.

Second, wrappers have to be boring. If Codex needs to learn the wrapper, or if the wrapper changes command behavior, it can spend more tokens and reduce confidence at the same time.

Third, bootstrap and recurring use are different questions. The bootstrap is an investment. It can be worth paying once if it makes every later session cheaper and cleaner. But the recurring tasks are the real proof. In my final run, recurring estimated cost went down a little, but total tokens did not.

That is not a strong enough result to say: “Token Frugal reduces Codex token usage.”

It is strong enough to say: “Measuring this properly changed what I think the next version should be.”

What V2 Should Probably Be

My first instinct was to add controls. V2 should probably remove and merge controls.

I would start with an instruction audit:

• what belongs in root AGENTS.md;
• what belongs in a runbook;
• what belongs in a hook;
• what belongs in a tool;
• what belongs nowhere anymore.

Then I would make Token Frugal less like another layer and more like a simplification pass.

The goal should be one small canonical way to work in a repo, not five overlapping versions of “be careful”. On a repo that already has orchestrators, agents, runbooks, and validation policy, Token Frugal should probably start by harmonizing those rules before installing anything new.

I would also make tfctx test conservative:

• preserve command behavior as closely as possible;
• detect tests that bind local sockets;
• recommend a raw or bypass path when wrapping could change the result;
• keep the output bounded without changing how the subprocess runs.

The boring version is the useful version.

What I Would Keep Today

I would still keep several parts of the experiment.

I would keep bounded reads. I do not need Codex to ingest a whole JSON file when a summary or a few keys answer the question.

I would keep raw logs out of the conversation by default. Saving a full log locally and showing a short tail is a good habit.

I would keep a short handoff. It reduces rediscovery when a session resumes.

I would keep JSONL usage measurement. It gives a much better discussion than guessing from prompt length or complaining that the quota feels high.

And I would keep the one-time versus recurring split. Without it, the numbers become too easy to misuse.

What I would not do is install hooks and wrappers blindly on every repo. The more process-heavy the repo is, the more I would first ask: which existing rules can be deleted, merged, or shortened?

The Useful Failure

This was not the article I expected to write.

I started with a fairly optimistic idea: reduce raw context, guide Codex toward compact surfaces, and watch token usage drop. The lab did show parts of that. But it also showed that my own repos already have a lot of accumulated agent process.

In that environment, another layer does not automatically help.

The more useful rule is simpler:

Reduce the context, then simplify the rules, then add tooling.

Token Frugal V1 helped me see the problem. V2 should be less about making Codex obey one more instruction and more about making the existing instructions easier to obey.