You type a two-line follow-up in Codex, yet the request may be much larger than those two lines. The continuing thread can also carry earlier exchanges, standing instructions, tool definitions, files, screenshots, browser results, command output, rejected approaches, and state from work already completed.

That is why making each new prompt shorter is not a serious token cost strategy. You have to control what the task carries forward, preserve the context that prevents mistakes, and measure the cost of reaching an accepted result rather than rewarding the smallest-looking request.

Measure the cost of an accepted outcome

Start by defining the unit of value. For a coding task, it might be a change that passes its verification checks and survives review. For an investigation, it might be an answer with enough evidence to support a decision. For a drafting task, it might be an approved document rather than the first generated version.

Then measure the whole route to that outcome: input, reused input when it is reported separately, output, retries, review time, and rework. A workflow that cuts input tokens but creates two extra debugging turns has not necessarily saved anything. A workflow that uses more context once and avoids a false fix may be the cheaper option.

Be equally careful about what your instrumentation means. One local Codex event log recorded 3.77 billion tokens across 143 threads and 28,877 records. Of 3.75 billion reported input tokens, 3.59 billion were labeled reused input, or 95.73%. But the log contained cumulative usage updates, so its total was a diagnostic signal, not a clean billable-token figure.

That distinction matters for your dashboard. A local event count, a provider-reported usage category, a plan limit, and an invoice are not interchangeable. If you are optimizing a bill, use the billing categories and rates that actually apply to your account. If you are trying to avoid hitting a plan limit, track the usage measure that governs that limit. Use local logs to find patterns, not to manufacture financial precision they do not contain.

Do not classify all reused input as waste. It may contain the decision that governs the implementation, the file already changed, the error that eliminated an attractive but wrong solution, or wording you explicitly approved. Repeated material may also be eligible for a provider cache discount, but cached input still contributes to cost. The useful question is not whether context is old. It is whether that context can still change the next action or prevent a costly mistake.

What you observe	Likely issue	What to change
Short follow-ups carry steadily rising input	The thread is accumulating history that the current step no longer needs	Create a checkpoint and continue the next work unit in a clean thread
The same procedure is explained in several sessions	Settled knowledge still lives only in conversation	Turn it into a reusable instruction, command, test, or script
A clean thread repeats discovery and reopens settled decisions	The handoff discarded consequential context	Add decisions, current state, relevant failures, and verification criteria
Reported tokens fall while retries or review rise	Context was removed too aggressively	Restore the evidence needed to resolve uncertainty on the first attempt

Keep only context that can still affect the result

A Codex thread should represent one coherent work unit, not an indefinitely growing relationship with a repository. The right boundary is usually the point where the objective, acceptance criteria, or body of relevant evidence changes.

Before continuing an old thread, ask three questions:

• Does the next task depend on unresolved reasoning from this thread, or only on artifacts and decisions already produced?
• Could one clear acceptance test define the next task without replaying the earlier conversation?
• Would a new thread need to rediscover important state, or can that state be expressed in a compact handoff?

If the next task needs only settled outputs, close the current work unit. If it still depends on an active investigation, keep the thread long enough to finish that investigation. Resetting in the middle of a multi-file change can be false economy when the next session must reconstruct which files changed, which hypothesis failed, and what remains unverified.

Use a checkpoint instead of carrying the transcript

A useful checkpoint is not a generic summary. It is a compact state transfer containing only information that should influence the next step:

• Objective: the outcome still being pursued, stated in one testable sentence.
• Current state: what now exists, including the relevant files or artifacts.
• Accepted decisions: choices that should not be reopened unless new evidence contradicts them.
• Live constraints: requirements, interfaces, safety boundaries, and compatibility conditions that still apply.
• Unresolved issue: the specific uncertainty or failure blocking completion.
• Relevant negative evidence: a failed approach only when it rules out a tempting next step.
• Verification: the command, test, review criterion, or observable result that will establish completion.

Leave out greetings, repeated explanations, abandoned drafts, successful command banners, fixed errors, and reasoning that no longer changes a decision. Preserve the result of an old debate, not every turn of the debate.

Select evidence before you expand context

Starting a clean thread will not help if the first instruction asks Codex to ingest an entire repository for a local change. Begin with the smallest evidence set that can support a correct decision, then expand when the work exposes a concrete uncertainty.

1. Name the desired outcome and its verification condition.
2. Point to the target files, symbols, configuration, or failing test rather than a broad directory when you already know the locus of the problem.
3. Include adjacent interfaces and dependencies only when they constrain the change.
4. Provide the live error and the command that produced it. Remove unrelated output from the same run.
5. Add logs, screenshots, browser results, or larger file ranges when they can change the interpretation, not merely because they are available.
6. Let Codex retrieve another artifact when it identifies a missing reference instead of front-loading every artifact that might conceivably matter.

This is evidence selection, not context starvation. If an interface is defined elsewhere, include or retrieve that definition. If a visual defect depends on layout, the screenshot is material evidence. If a security rule governs the implementation, keep it visible even when it adds tokens. The goal is to remove inert context, not consequential constraints.

Apply the same test to standing instructions. Stable safety rules, repository conventions, and the definition of done belong in reusable instructions. A long explanation written for one past task does not. Every permanent instruction is a recurring input expense, so it should earn its place across many tasks.

Move settled knowledge out of the conversation

Conversation is useful for exploration because it preserves the path from uncertainty to a decision. It is inefficient as the permanent home for a decision that has already been accepted.

Move stable knowledge into the artifact best suited to enforce or retrieve it:

• An accepted answer becomes a decision record. Keep the decision, its governing constraint, and the condition that would justify revisiting it.
• A settled procedure becomes executable. Put repeatable steps into a command, script, test, or automation where execution can replace repeated explanation.
• A recurring quality expectation becomes a check. Encode it in tests, validation, or a concise review checklist rather than restating it in every prompt.
• A durable repository fact stays near the repository. Store it in the appropriate project documentation or instructions and point Codex to that location.
• A failed approach becomes a narrow warning. Preserve the relevant failure condition and evidence, not the entire unsuccessful exchange.

Code and tests are especially valuable forms of compressed context. A passing check can express a settled requirement without carrying the conversation that produced it. A script can embody an approved sequence instead of asking the model to regenerate that sequence on every run. If the procedure can modify data or infrastructure, keep review gates, explicit targets, and a safe validation path; token savings do not justify making a destructive action easier to trigger accidentally.

Do not compress away causality. A checkpoint that says use option B is weak if a non-obvious compatibility constraint made option A invalid. Keep the constraint with the decision. Otherwise a later session may rationally reopen the question, spend tokens rediscovering the same evidence, or make the same mistake.

This creates a healthier division of labor. Use the thread for live reasoning. Use files, tests, decision records, and automation for settled state. The next Codex session can retrieve the durable result without replaying how you reached it.

Prove savings with a matched workflow experiment

A lower token count on an easier task proves little. To decide whether a new practice belongs in your team’s operating model, compare workflows on comparable work from the same starting state and apply the same acceptance criteria.

1. Choose a repeatable task type. Use work with a clear completion condition, such as resolving a defined failing test or making a bounded change with known review criteria.
2. Capture the baseline. Run the workflow normally and record the usage categories available to you, the number of retries, whether verification passed, and the review or rework required.
3. Change one behavior. Test a clean task boundary, evidence selection, a checkpoint handoff, or a codified procedure. Changing everything at once prevents you from learning which intervention helped.
4. Hold quality constant. Apply the same tests and review standard to both runs. Do not count an incomplete or weakly reviewed result as a saving.
5. Calculate the relevant reduction. Compare like-for-like provider usage, and apply the actual billing treatment when your goal is financial cost. Keep cached or reused input separate when it is priced or limited differently.
6. Check the downstream work. Reject a variant that lowers reported usage but increases retries, manual explanation, review time, defects, or later rediscovery.
7. Repeat across different task shapes. A single matched job can expose a promising mechanism, but it cannot establish that the same practice works equally well for implementation, debugging, research, and drafting.

Your decision rule should be strict: adopt the change only when it reduces the usage or cost you actually care about without degrading accepted outcomes. A target such as cutting reported reused input by 90% can motivate an experiment, but the percentage alone cannot establish success. It says nothing about whether necessary context disappeared or whether the saved tokens returned as retries and rework.

For leaders, this also changes the governance conversation. Do not rank people by raw token totals. Different tasks legitimately require different amounts of context, tool use, and verification. Standardize the controllable practices instead: coherent work units, explicit acceptance criteria, evidence-first retrieval, compact handoffs, durable decision records, and outcome-based evaluation.

Key takeaways

• A short visible prompt can still carry a large accumulated request, so prompt brevity alone is not token optimization.
• Optimize for the cost of an accepted, verified outcome, including retries, review, and rework.
• Start a clean thread when the objective changes and the next task needs settled artifacts rather than unresolved conversation.
• Preserve decisions, constraints, live failures, and verification criteria; discard history that can no longer affect the result.
• Turn repeated explanations into durable instructions, tests, commands, scripts, or decision records.
• Validate each optimization on matched work and distinguish local event counts, provider usage, plan limits, and billed cost.

For your next recurring Codex workflow, capture a baseline and change only the task boundary. End the first work unit with a compact checkpoint, start the next one clean, and compare the accepted result. If that holds up, optimize evidence selection next. Codify repeated procedures only after you know which context is truly settled.

References

• Nate Jones’s Substack – Your tenth message costs far more than your first

---