Codex workflow
Codex Token Usage Too High? How I Test a “Verify at the End” Workflow
I noticed that asking Codex to finish one coherent batch of edits before running the full suite can make some coding tasks feel faster and produce less repeated output. That is a workflow hypothesis, not a universal token-saving trick.
- Observed
- On bounded, related edits, one final full-suite run appeared to reduce back-and-forth and repeated logs.
- Verified
- OpenAI documents compaction as a way to reduce context size while preserving relevant state, and engineering guidance consistently recommends trimming noisy tool output.
- Limit
- I have not established a universal saving rate. Model, reasoning effort, repository size, failures, and log volume all affect usage.
Key takeaways
- Delaying repeated full-suite runs does not mean skipping verification.
- A useful comparison tracks tool calls, log volume, rework, elapsed time, and usage under the same task conditions.
- High-risk logic still deserves early targeted tests; one full verification pass can follow the completed batch.
Two testing rhythms
- 01Related edits
- 02Targeted checks
- 03Full suite
- 04Record result
Why test order became a variable
Every full test run gives the coding agent more output to read, classify, and carry into later turns. If a change spans three related files and the suite runs after every partial edit, the session can process the same successful output and unrelated warnings several times.
When the acceptance boundary is already clear, finishing the coherent edit before the full run often feels more direct. Fewer tool round trips, less duplicate output, and fewer diagnoses of an intentionally incomplete state are all plausible explanations.
A comparison you can reproduce
Do not compare two unrelated projects and call the difference evidence. Use two similar tasks or two worktrees created from the same commit. Keep the model, reasoning effort, repository instructions, dependencies, and acceptance commands fixed.
Workflow A runs the full suite after each local change. Workflow B permits static checks and targeted tests for risky behavior, then runs the same full suite once the related implementation is complete. Both workflows must finish with identical acceptance evidence.
- Record start and finish time plus total tool calls.
- Count full-suite runs and the lines or bytes they emit.
- Record input, cached-input, and output usage where the product exposes it.
- Count failures and rework; fewer tests with more repair is not an improvement.
The rule I use now
I do not defer every test. Data migrations, authentication, payments, concurrency, shared APIs, and hard-to-reverse changes need early, targeted feedback. Copy, adjacent components, type completion, and coherent changes inside one feature are better candidates for a final full-suite pass.
The instruction I actually use is more precise: finish all related edits in this scope; during implementation run only targeted checks that expose high-risk mistakes quickly; when the implementation is complete, run the named full tests and build, then fix them to green.
How to tell whether it saved anything
A faster feeling does not prove lower token usage. Cache hits, model scheduling, and output truncation change the experience. A credible result reports usage, time, test count, and rework together instead of selecting one flattering metric.
If Workflow B produces fewer repeated logs but discovers a defect so late that it needs a long debugging exchange, the benefit may disappear. My current conclusion is narrower: test frequency is a design variable, and it is worth measuring in your own repository.
Where I stand now
The valuable part of this prompt is not the promise of saving tokens. It forces the agent to understand the delivery boundary before it starts generating evidence. Vague tasks turn tests into repeated exploration; bounded tasks let tests become proof.
I will keep recording comparable tasks with the same model. Until the sample is strong enough, I will describe this as an observation rather than manufacture a percentage.