Codex usage
How to Check Codex Token Usage: Input, Cached Input, and Output
A remaining-usage percentage is not a task-level token invoice. Separate the context you send, the prefix that may be cached, the model output, and the tool logs before deciding what to optimize.
- Observed
- The same short request can feel much more expensive late in a long, mixed-purpose session than in a focused new one.
- Verified
- OpenAI pricing separates input, cached input, and output, while plan documentation notes that task complexity affects included usage.
- Limit
- Codex interfaces and plan displays can change. This article does not treat a button location or quota number as permanent.
Key takeaways
- Plan usage indicators are not exact per-task token bills.
- Long context and noisy tool output often matter more than one short prompt.
- Fix the model, reasoning effort, repository state, and acceptance criteria before comparing tasks.
A task-level usage ledger
- 01Input
- 02Cached input
- 03Model output
- 04Tool logs
Identify the meter first
Codex may expose session status, plan usage, or remaining allowance. Those signals are useful for trends, but they are not always an exact token breakdown for one task. API billing, ChatGPT plan allowance, and a local CLI session are different measurement contexts.
Write down the product surface, model, date, and task before comparing. Do not convert a plan percentage directly into API cost or treat one unusual jump as a permanent model characteristic.
What the categories mean
Input covers your prompt, repository instructions, files the agent reads, and conversation content still carried forward. Cached input is an identical prefix the service can reuse. Stable instructions first and changing task details later make that reuse more plausible. Output is the model-generated reasoning, explanation, and patch.
Command logs are not model output, but they become new input when the model reads them. Full build logs, repeated passing test lines, and one-time large files are often the easiest context noise to control.
- Record which files and logs entered the session.
- Measure tool-output volume, not only prompt length.
- Note compaction, new sessions, and broad repository rereads.
Keep a comparable task ledger
Track a small stable set: task, starting commit, model and reasoning effort, starting and ending usage signal, tool calls, test runs, elapsed time, failures, and rework. A series of similar tasks is more useful than one attractive number.
When usage rises, inspect scope growth, uncontrolled reads, duplicate logs, and mixed topics before changing models. That turns optimization into an engineering decision instead of guesswork.
My rule for usage tracking
I prefer learning how a class of tasks behaves over watching one remaining-usage percentage all day. Trends guide decisions; isolated numbers often create noise.