Aident AI
How to Diagnose Codex Usage Spikes Before You Hit the Limit
If Codex usage suddenly climbs, do not start by guessing how many prompts you have left. First separate account usage from the current chat's context, then compare one controlled task at a time. In the Codex CLI, /usage shows account token activity and rate-limit resets, while /status shows the active model, context use, and session configuration. Those are different meters.
The fastest useful diagnostic is:
Record
/usage,/status, and/diffbefore the next task.Run one small, precisely scoped task with no subagents.
Record the same three views afterward.
Repeat after changing only one variable: reasoning effort, model, fast mode, context, or connected tools.
This guide gives you a reproducible way to find the expensive part without exposing credentials or disabling the tools your workflow actually needs.
Prerequisites
You need:
a current Codex CLI session;
a repository where
git statusandgit diffare safe to run;permission to inspect your local Codex configuration;
a small representative task, such as changing one test or reviewing one file.
Before testing, capture the CLI version and working-tree state:
Do not paste API keys, OAuth tokens, .env contents, or full private tool responses into a diagnostic transcript.
Step 1: Identify which limit is moving
Open the slash-command menu in the Codex CLI and run:
Use /usage for daily, weekly, or cumulative account token activity and reset information. Use /status for the current session's model, configuration, context capacity, and token use. A chat that is close to its context window is not automatically the same thing as an account that is close to a usage limit.
Write down the time, active model, reasoning effort, remaining context, and the usage window that concerns you. If several developers share an organization, confirm whether the meter is individual or shared before attributing the change to one local session.
Expected result
You should be able to state the problem precisely, for example:
Weekly account usage moved faster during a review task, while this chat still had ample context.
or:
Account usage looks normal, but this long chat is repeatedly compacting and rereading project files.
That distinction determines the next test.
Step 2: Establish a one-task baseline
Choose a task with a narrow input and an observable finish line:
Immediately before and after the task, run /usage and /status. Then run /diff or git diff --stat to confirm whether the task unexpectedly expanded into edits.
Keep the repository, prompt, model, and connected tools unchanged during the baseline. If you change three variables at once, the result cannot tell you which one mattered.
Step 3: Test the common multipliers one at a time
Model and reasoning effort
OpenAI's Codex documentation says higher reasoning effort can improve complex work but uses more tokens. Test the lowest reasoning level that reliably completes your representative task. If your surface exposes /model and /reasoning, record both selections before each run.
Fast mode is a service tier, not a free efficiency switch. If /fast is enabled, turn it off for one controlled run and compare the account meter. Do not compare different tasks and call the difference a mode effect.
For clear, repeatable, high-volume work, consider whether a lighter model such as Luna is appropriate. Keep stronger models and higher reasoning for tasks that actually need them.
Long context and repeated compaction
Long chats accumulate instructions, file excerpts, command output, tool results, and earlier decisions. When the session approaches its context limit, compaction summarizes the transcript so work can continue. If the summary omits a crucial detail, the agent may reread files or repeat discovery.
Run /status before and after a task. If context use grows sharply, start a fresh chat for an independent task or compact deliberately after recording the state. Give the new chat a short handoff containing:
the objective;
decisions already made;
files that matter;
commands already run and their results;
the exact next step.
Do not paste the entire old transcript. That recreates the same context problem.
Subagents and parallel work
Subagents are useful when independent work can proceed in parallel, but each agent has its own reasoning and context. OpenAI's documentation explicitly notes that subagents consume more tokens. A request such as “research everything in parallel” can multiply discovery, file reads, and result summaries.
Compare one run with no subagents against one run with a single, bounded subagent. Delegate only an independent task with a compact return contract, such as “return the three relevant file paths and one-sentence rationale for each.”
Skills, MCP servers, and large tool results
Skills use progressive disclosure: Codex initially sees a bounded catalog and loads the full instructions for a selected skill. MCP servers add tool descriptions, calls, and returned data when they are used. The expensive part is often not merely having a connection configured, but repeatedly loading large instructions or returning oversized search results.
Inspect configured tools without printing secrets:
Then rerun the baseline with one nonessential server or skill excluded from the task. Prefer narrow queries, small result limits, summaries instead of raw logs, and file paths instead of whole repositories. Never disable a security or audit integration merely to make a benchmark look cheaper.
Step 4: Keep a compact comparison table
Use a table like this for three to five runs:
Run | Model and reasoning | Context before | Subagents | Tools used | Task result | Usage change |
|---|---|---|---|---|---|---|
A | Current settings | Record from | 0 | Normal set | Pass or fail | Record from |
B | Lower reasoning | Same range | 0 | Normal set | Pass or fail | Record from |
C | Same as A | Fresh chat | 0 | Narrow set | Pass or fail | Record from |
The winning configuration is not automatically the run with the smallest meter change. It is the least expensive run that still produces the correct, reviewable result.
Common failure modes
/usage or /status is unavailable
Confirm the installed version with codex --version and open / to see commands supported by that surface. The CLI and IDE expose overlapping but not identical commands. Update through your approved installation method rather than copying a binary from an untrusted source.
A run looks expensive but the task also changed
Discard the comparison. Use the same repository state and prompt, and change only one setting. Even a larger diff or a failing test can cause extra diagnosis and retries.
Compaction causes repeated file reads
Stop adding more history. Save a concise handoff and continue in a fresh chat. Include exact file paths and verified decisions so the next session does not rediscover them.
Tool output dominates the transcript
Reduce query windows, row limits, log fields, and returned documents. Ask tools for aggregates before raw records. For recurring external workflows, use a governed capability layer that can discover a precise action, inspect its schema, and execute it without flooding the chat with an entire provider catalog.
Why this diagnostic works
Codex usage is workload-dependent. Task complexity, context length, model choice, reasoning effort, delegation, and tool results can all change the amount of work performed. A controlled comparison turns a vague limit complaint into a specific cause you can act on.
The same structure that makes technical troubleshooting useful also makes it measurable: capture the initial state, change one variable, define the expected result, and preserve a short audit trail.
If external tool discovery or oversized integration output is the multiplier, set up Aident Loadout and run one bounded capability search, schema inspection, and execution. Measure the before-and-after usage for that exact task.
