Let Codex Audit Its Own Token Spending: A Token-Saving Trick

Recently I found a pretty practical trick: get Codex to review its recent run history and analyze where tokens are being wasted.

This article is also published on AI Coding Guide.

For Codex membership, I often buy from chong-zhen.com.

This might seem roundabout, but it's actually simple. You don't need to dig through logs yourself or calculate how much context each tool call eats. Just throw this prompt at it:

Review your past run records and analyze how to save tokens. Consider using certain skills, scripts, or switching models. Adjust settings based on the analysis, but don't sacrifice existing performance or capabilities.

I ran it myself and found it really surfaces waste points you'd normally never see.

A lot of the time we think tokens are spent on "writing code," but that's not the case. The truly expensive parts are often the tiny burns from searching for information, understanding context, processing tool results, and carrying a pile of history into subtasks.

What It Looks At

The core of this prompt isn't to get Codex to spit out generic money-saving advice, but to have it diagnose based on its own history.

It typically examines a few categories:

Observation Target	Focus
Recent sessions	Which tasks have the highest consumption, and does consumption match task difficulty?
Input/output ratio	Is a lot being fed in but very little actually produced?
Tool call results	Are search, file reads, and log outputs too long?
Screenshots and images	Is high-resolution material used unnecessarily?
Sub-agents	Is the full history from the main session being carried over?
Skills and rules	Are irrelevant rules being loaded for the current task?

A human could check these too, but it's tedious. Letting Codex check itself has the advantage that it's closer to the execution site and can be specific about "where exactly did I waste."

The Main Issues I Found This Time

My most obvious problem: the stuff I feed it is too messy and too much.

For example, a task might only need to look at a few dozen lines around a function, and it reads the whole file. A tool returns thousands of lines of logs, and only two paragraphs in the middle are useful, but the context is already stuffed with raw logs. Another sub-agent only needs to check a small issue but leaves carrying all the previous discussion from the main agent.

None of these are "the model isn't smart," they're just coarse working methods.

For an agent, context is not a free scratchpad. Every extra read, every extra stuff, every extra retention becomes a burden for later reasoning.

The Rules It Gave Me

After this diagnosis, Codex gave me several fairly concrete optimization directions.

First, when reading files, don't shove the whole thing in at once. Search to locate first, then read in batches, only reading the parts relevant to the current problem. If a tool returns too-long results, truncate, filter, or summarize first, then hand the key info to the model.

Second, don't default to highest resolution for screenshots and such. If you can judge layout, color, and structure at low resolution, there's no need to keep sending originals. Especially for preliminary judgment, high resolution often just adds cost.

Third, if the same operation fails, don't retry in place multiple times. Look at the error message, confirm the failure reason, then act. A lot of tokens are wasted on "ran it again without understanding the problem."

Fourth, when a sub-agent takes on a task, only give it the information necessary to complete that task. Don't pack up all the history the main agent accumulated and throw it at the sub-agent. The smaller the subtask, the cleaner the context should be.

Fifth, skills aren't always better. Load only what's needed. Don't throw a pile of irrelevant rules into context every time. A skill's value is making the model understand the current task, not making it carry a toolbox through the whole run.

But Don't Treat the Diagnosis as Gospel

There's an important premise here: Codex's analysis isn't always accurate.

It can see some execution traces and infer from logs, but that doesn't mean every suggestion fits your project. Some tasks genuinely need to read the whole file, some screenshots need to be high-res, and some complex refactors should use stronger models.

So the more robust approach isn't "change whatever it says," but compare a few tasks you run often:

Comparison Item	What to Look At
Token consumption	Does it drop significantly before and after optimization?
Output quality	Are there missed changes, misjudgments, or shallower understanding?
Tool call count	Are there fewer useless searches and repeated reads?
Task completion time	Does over-saving actually slow things down?
Manual intervention	Do you need to supply more context?

The goal of saving tokens isn't to make Codex do less work, but to make it do less unnecessary work.

This Command Can Be Extended

I think there's an even more interesting direction: extend it into project knowledge base distillation.

Because what it really relies on isn't some abstract theory, but your past conversation history, task records, failure cases, and project context. These things already have value, just scattered across sessions.

If you organize them further, you can distill several types of digital assets:

Distillable Content	Use
Common task workflows	Don't re-explore next time for similar tasks
Project structure descriptions	Reduce repeated code reading and background explanation
Failure cases	Avoid stepping on the same pit repeatedly
High-quality prompts	Become reusable commands or skills
Token optimization rules	Solidify into configs, memory, or project specs

In other words, saving tokens is just the first layer of benefit. The longer-term gain is turning conversations into reusable project experience.

Finally

If you use Codex frequently, try this prompt:

Review your past run records and analyze how to save tokens. Consider using certain skills, scripts, or switching models. Adjust settings based on the analysis, but don't sacrifice existing performance or capabilities.

After running it, don't rush to copy everything. Pick two or three high-frequency tasks and do A/B comparisons. As long as a rule reduces invalid reads, repeated calls, and overloaded context without sacrificing result quality, it's worth keeping.

The real way to save tokens is never to make the agent know less, but to make it know what it needs to know faster.

---

I also have some AI Coding (SDD Agent AI tools, etc.) and Node technical exchange groups. If interested, add WeChat ikoala520 to join, learn together, and progress together.

This article is also published on AI Coding Guide.