15 ways to cut token waste in Codex and Claude.

What is actually inside the request you just sent

You typed a sentence. The call that carries it can also contain the old conversation, every earlier answer, the tool results from twenty turns ago, the files and screenshots you attached, the descriptions of every tool your harness has loaded, your standing instructions, hidden setup, and the answer the model is about to write. If that answer fails a check, the next attempt can carry most of it again.

That is why "use a cheaper model" so often changes nothing. The pile moves; it does not shrink. Every model call gives you three places to cut — old material carried forward, new material loaded for this job, and the output, tool results, and retries added afterward — and a fourth lever, caching, that lowers the price of what is left without removing it.

The 15 moves below are sorted by which of those they attack. Some remove old context. Some reduce new input. Some shorten output. Some prevent an entire model call. One only changes the price.

The result this guide is anchored to

The same Codex job was run two ways, and both versions had to pass the same checklist of required facts and structure.

The normal worker made three model calls and reported 51,712 reused input tokens, 81,276 provider-reported input plus output, and 515 output tokens.

The clean worker was handed only the facts it needed. It made one call, reported zero reused input, 11,565 input plus output, and 131 output tokens — a reduction of 85.77% on the matched job.

Then the model came out entirely. A separate Python selector had already reduced a 1.1 MB source file to a 1,012-byte fact file. Starting from that file, ordinary code wrote the required result and ran the same check in about a tenth of a second, with zero model calls and zero model tokens.

How we know, and what it does not prove: the check confirmed the required facts and the shape of the answer. It did not prove that two pieces of writing were of identical quality. A single zero-reused-input record is also not proof about every hidden byte the product sent. This is one matched job, not a full day.

The 3.77 billion that started this

Build the tracker that produced this number ↓

The July 26 reading on a local Token Burn tracker attributed 3.77 billion tokens to one day of Codex work, of which 3,588,555,136 were reported as reused input — 95.73%. That day covered 143 Codex threads and 28,877 local usage updates.

Treat that as an alarm, not an invoice. It comes from a local event log that includes cumulative updates, so it is not an OpenAI bill and not a count of unique calls. It needs one fixed duplicate-removal rule before whole days can be compared. The matched job above is the cleaner evidence; the 3.77 billion is what made anyone go looking.

1. Edit or rewind a bad turn instead of stacking a correction on it

Do this. When a response goes wrong because your request was unclear, do not send "no, that is not what I meant." Edit the original request, or rewind to the point before the mistake, and run it again. In Claude Code, the /rewind command takes you back. In a chat product with editable messages, edit the message that caused the problem. Use this when the branch is simply wrong — if you learned something and the work genuinely moves forward, send the follow-up.

What it saves. The entire rejected branch: the unclear request, the wrong answer, your correction, and the extra turn that would otherwise be carried into every later call.

Why it works. A follow-up does not replace a mistake. It appends to it. The conversation formats these products use include earlier user and assistant messages in later requests, so the bad branch keeps arriving.

How we know: removing a branch makes the next request smaller by exactly the size of that branch, which varies. Check the next usage record rather than assuming a fixed percentage.

2. Put related questions in one message

Do this. If three questions need the same background, ask them together. Not "summarize this report," then "what are the three risks," then "give me a headline" — one request that asks for all three.

This is not an argument for giant prompts with forty unrelated jobs. Batch the questions that share a source. Bundling unrelated work just builds the pile you are trying to avoid.

What it saves. Repeated input and extra model calls. Three separate turns can make the model carry the same background three times, plus the answers in between.

Why it works. The saving comes entirely from loading shared background once. When the questions do not share background, there is nothing to save.

How we know: this is request arithmetic — count the calls and the total input across both versions. There is no universal percentage.

3. Start a clean task when the job changes

Do this. Keep a long conversation while you are still working on one problem. The moment you switch to a different job, start a clean Codex task or Claude chat.

A support case should not inherit a video research conversation. A spreadsheet fix should not inherit a long brand argument. A new customer should not inherit the last customer's account history. You are not throwing the old task away — you are declining to make the next job carry it.

What it saves. Old conversation, old tool results, old files, and instructions that belong to a different job.

Why it works. A clean task cannot reread a conversation that was never added to it. This is the bluntest instrument on the list and usually the most effective.

How we know: in the matched job, the normal worker reported 51,712 reused input tokens and the clean worker reported zero while passing the same checklist. That applies to that job. Codex and Claude still carry their own starting instructions, so do not expect every clean task to report zero.

4. Carry forward the answer you kept, not the argument that produced it

Do this. Save the latest approved draft, decision, plan, or file. For the next change, hand the model that result plus the new instruction: "Here is the version we kept. Change the second section so it includes the customer example. Leave the rest alone."

Do not also include the rejected first draft, the three rounds of criticism, the pages you discarded, the model's reasoning, and every correction that preceded the accepted version.

What it saves. The entire history of how the result was made — which is usually far larger than the result.

Why it works. Most revisions need the current state and the requested change. They do not need the path that produced the current state.

How we know: the Token Saver skill below includes a tested state tool that builds the next request from one accepted result plus one new change, and its tests exclude the prior conversation from that packet. How much you save depends on how large the omitted history was.

5. Search large sources before a model reads them

Do this. Use ordinary search first. Send the model only the passages that mention the customer, date, error, product, person, or decision. Do not hand a model a large transcript, repository, mailbox export, or dashboard file just to find one small fact.

If the selected passages turn out to be insufficient, pull one more bounded passage. Do not fall back to loading everything.

What it saves. New input from irrelevant source material — and it reduces the chance that the passage that mattered gets buried inside a giant request.

Why it works. Search is exact, fast, and free of model calls. The model then receives only the part where judgment is still useful.

How we know: in the matched job, ordinary code reduced a 1.1 MB source file to a 1,012-byte fact file while preserving every fact on the checklist.

6. Send the lightest useful form of a source

Do this. Send text as text when the page design does not matter. Extract the text from a large PDF once. Crop a screenshot to the region the model needs instead of sending the full page. Send the twelve changed rows instead of the whole spreadsheet. Send a diff instead of two near-identical files.

Keep the original available in case the smaller version is not enough. You are not destroying information — you are choosing the smallest useful form for this request.

What it saves. New input from page furniture, repeated headers, blank areas, duplicate rows, image detail, and unchanged material.

Why it works. Material that never enters the request cannot consume model tokens. This sounds obvious until you watch a browser agent carry full-page screenshots through thirty turns because it needed one account number.

How we know: measure the provider-reported input before and after. There is no honest universal percentage here — a dense chart and a blank PDF page tokenize very differently.

7. Turn work that has one right answer into code

Do this. Use a parser, a formula, a database query, a formatter, a test, or a short script for exact work. "Use only July 26" is a date filter. "Reduce this number by 90%" is a formula. "Include these four facts" is a check. "Stop if a fact is missing" is an error. "Return these fields in this order" is a formatter.

Do not pay a model to count, sort, find exact text, normalize dates, compare files, convert formats, or repeat the same search-filter-calculate-format sequence every day. Let the model handle the part that genuinely needs language or judgment.

What it saves. The input, output, reasoning, tool calls, and retries for that entire part of the job.

Why it works. A fixed rule does not need to be explained to a model and reinterpreted on every run. The computer can just run the rule. Software has worked this way forever; the new part is noticing how much work we keep sending back to a model after it has already become a repeatable rule.

How we know: starting from the prepared 1,012-byte fact file, the code path wrote the required result and passed the same checklist with zero model calls and zero model tokens.

8. Return an accepted answer instead of regenerating it

Do this. If the exact request and its source have not changed, return the answer a person already accepted. No model call, no new variation for a human to re-check.

Be strict about this, because a fuzzy text match is dangerous. The request, the relevant source, and the accepted result must all match, and a changed source must force a fresh run. Never treat an earlier result as accepted unless a person actually accepted it.

What it saves. One complete model call.

Why it works. The answer already exists. Asking a model to recreate it costs tokens and can make it worse.

How we know: Ringer's pre-call code stores only explicitly accepted results and can return an exact match with zero upstream model calls; its tests change the source and confirm the old answer is not reused. That is a tested local capability, not something every AI product does for you.

9. Load only the tools this job can use

Do this. A writing task does not need every browser, database, email, Slack, GitHub, and calendar tool you own. Keep a few common tools available and load the rest only when a request needs them. If your host supports tool search or deferred loading, use it for large catalogs. If a job needs no tools, give it none.

What it saves. Tool descriptions at the start of the request, and tool results on every later turn.

Why it works. Every tool ships a name, an explanation, and an argument schema. All of it is model input even when the model never calls that tool.

How we know: Anthropic reports that a typical multi-server setup can start with roughly 55,000 tokens of tool definitions, and that its tool-search tool generally cuts that definition load by more than 85% by loading only the three to five tools a request appears to need. Anthropic recommends it once you have about ten tools or more than 10,000 tokens of definitions. Source: https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool

10. Clean up old tool output during a genuinely long job

Do this. Sometimes a clean task is the wrong answer. You are three hours into debugging one system and the model needs decisions it made forty minutes ago. That is where compaction and context editing belong: remove or compact the old browser pages, command output, screenshots, and reasoning the next step no longer needs, while keeping the state it does.

A browser page dumped 20,000 tokens into the conversation and the next step needs the account ID from it. Keep the ID. Drop the page.

Do not compact a five-message chat because the feature exists, and do not remove a fact the next step still needs.

What it saves. Reused input on every later step of the same long job.

Why it works. The next request carries a smaller representation of the earlier work instead of every raw intermediate result.

The tradeoff. Editing old material can break a prompt-cache match. That is fine when you remove far more waste than the cache discount was saving — but you have to compare the whole job, not the one call.

How we know: OpenAI supports compaction for long-running API work and says the compaction item preserves the state later turns need using fewer tokens (https://developers.openai.com/api/docs/guides/compaction). Anthropic supports context editing that can clear old tool results and thinking blocks (https://platform.claude.com/docs/en/build-with-claude/context-editing). The actual saving depends on what your host keeps, so verify the next request's input count.

11. Ask for only the answer you need

Do this. Ask for one file, one JSON object, five bullets, or one replacement paragraph. Set a short output limit when the interface supports it. Do not request a process diary unless you are going to read it.

This is not an argument for caveman prose. If the writing is the product, give it the space it deserves. Remove the words nobody will use.

What it saves. Output now, and input later — because the model's answer often becomes part of the next request.

Why it works. Every generated word is a token when it is written and may be a token again on every subsequent turn.

How we know: in the matched job the clean worker produced 131 output tokens and the normal three-call worker produced 515. Shorter output was not the whole win, but it helped twice: once immediately, and again by leaving less text for later calls to carry.

12. Use more than one model — but count the whole job

Do this. Give bounded extraction, classification, formatting, and short rewrites to a cheaper model when it can pass the same check. Keep difficult judgment, strategy, and final writing on the strongest model you have. You do not have to pick Codex or Claude as a religion — use Codex, Claude, GLM, a local model, or whatever earns the work.

Then apply the rule that stops model routing from becoming theater: count the whole job. If a small model burns 20,000 tokens, fails, and a large model has to reread the failure plus the original request to fix it, you did not save anything. You added a detour. If a small model handles a thousand routine classifications correctly and the strong model only sees the five uncertain cases, that is a large real win.

What it saves. Expensive-model capacity, and sometimes total tokens. Model choice alone guarantees neither.

Why it works. Different jobs need different levels of judgment. A lower price per call is only useful when the returned work passes without expensive repair.

How we know: compare the complete job — all input, reused input, output, calls, retries, and human repair. Keep the smaller model only when the accepted result costs less. Nothing here claims that any particular cheap model wins on your work.

13. Put a hard stop on oversized calls and retries

Do this. Set explicit limits before the call for fresh input, reused input, output length, number of model calls, and number of repair attempts.

If the answer is missing one required fact, one small repair with that fact may make sense. If the request itself is over the limit, do not send it again. Narrow the source, drop the tools this job cannot use, move the exact steps into code, and send a smaller request to a clean worker.

What it saves. Duplicate calls, retry loops, and runaway output.

Why it works. A second copy of an oversized request is still oversized. A token-limit failure cannot be repaired by repeating the same call.

How we know: an early Ringer path retried after a token-limit failure, and the second call could not make the first request smaller — it only repeated the waste. The pre-call code now has separate limits for fresh input, reused input, output, and calls, and its tests confirm a failed or over-limit call does not silently fall through to another model.

14. Cache only the background you genuinely cannot remove

Do this. When background truly must repeat, keep the reusable instructions and reference text unchanged at the very beginning of the request, and put the new assignment at the end. Do not rewrite or reorder the repeated part.

In plain English: if the beginning of a request exactly matches an earlier one, the provider may recognize it and charge a lower price for that repeated beginning.

What it saves. Money, and often latency, on repeated API input. It does not save tokens.

Why it works. Both major providers can reuse work already done on an exact matching prefix.

Why it is last. Cached does not mean gone. If you are carrying 100,000 tokens of background that could be cut to 5,000, cut it — do not keep it because the provider might discount it. Caching a huge request makes the huge request cheaper. It does not make it small.

How we know: OpenAI's API automatically checks eligible prompts of at least 1,024 tokens, requires an exact matching prefix, recommends putting changing material last, and reports cached_tokens in the response (https://developers.openai.com/api/docs/guides/prompt-caching). Anthropic lets you mark the repeated material, prices a cache read at one tenth of normal input, and its own example still counts 100,000 cached tokens plus 50 new tokens as 100,050 total processed input tokens (https://platform.claude.com/docs/en/build-with-claude/prompt-caching).

15. Put a gateway in front of the call when you need control before the model starts

Ringer setup, the ask command, and the manifest fields ↓

Do this. For a Codex CLI workflow that would otherwise send a large request before any skill can help, use Ringer's optional local gateway. You keep typing in Codex — there is no separate Ringer chat window. The gateway sits between Codex CLI and the model provider, and before forwarding a request it can return an exact accepted answer with no model call, run a fixed local recipe with no model call, select only the relevant source passages, forward a reduced request to a cheaper or stronger model under hard limits, or stop before spending tokens at all.

What it saves. Input the host would otherwise send before your selected skill even begins, plus entire calls that code or an accepted result can answer.

Why it works. A skill is loaded inside a model call. It can make everything after it smaller, but it cannot reach backward and erase the conversation, hidden setup, and tool descriptions that already started the turn. A gateway acts before the provider receives the call.

Where it stops. The verified gateway path today covers Codex CLI text-answer turns. The Anthropic request adapter passes its unit tests, but a live Claude Code 2.1.132 request retried after a gateway stop, so that path is not being called compatible yet — Claude Code users should use the standalone skill below. It also requires provider configuration and API credentials, those calls may bill against your API account rather than the subscription in the consumer app, and a complex tool-using job may still need the full normal environment.

How we know: the gateway and router are covered by tests for exact accepted answers, local code paths, selected-source forwarding, per-call token records, limits, and no-retry-after-failure. A real Codex CLI request returned the answer from Ringer's local calculator and reported zero model tokens.

Install it once in Codex and Claude Code

Download the Token Saver skill ↓

Download the zip and unpack it into wherever your harness loads skills from — ~/.claude/skills/token-saver/ for Claude Code, ~/.codex/skills/token-saver/ for Codex. The folder should end up with SKILL.md at its top level and the scripts and agents folders beside it. Nothing else needs configuring: the skill resolves its own script paths from wherever the harness loaded it.

After that, keep working normally. Ask for it by name when a job involves plan limits, token use, a long chat, or a large file: "Use the Token Saver skill for this job."

The zip contains the skill only. Copy it into your skills directory yourself rather than running an installer — that keeps you in control of which harness gets it.

What the agent does once the skill is loaded

It finds the likely source from attached paths, named files, and local search rather than asking you to pick. It selects the relevant passages and sends those instead of the whole file. It runs exact work as code before reaching for another model. It saves the version you accepted, and builds the next revision from that result plus your new change — so you never restate the work. It avoids loading tools the job cannot use, chooses a smaller model only when the whole job wins, keeps the answer to the length you asked for, and stops retrying token-limit failures.

If it cannot identify the source safely, it asks you. You do not have to summarize an old chat, choose files by hand, create a state file, learn script paths, or understand Ringer.

The honest limit

Token Saver in the Open Skills library ↓

Loading the skill adds a small amount of instruction to the call you are in. It earns that cost only when it prevents a larger file load, tool catalog, retry, over-long answer, or later context reload.

Most importantly, it cannot erase the current call. That call has already begun. The skill makes the work that follows smaller. If you need the request changed before the model sees it, that is the optional gateway in move 15.

Add the whole job, not the call you are proud of

Count fresh input, reused or cached input, cache writes, output, reasoning output where it is reported, every planning and checking and repair call, and the human repair time when you are comparing models. If a host does not report a number, write it down as unavailable rather than inventing it.

Three things that look like wins and are not: moving 50,000 tokens from Codex to Claude is not a token saving. Paying one tenth of the price for 50,000 cached tokens is a cost saving, not a 90% reduction in tokens. And a shorter answer that leaves out half the work is not a win at all.

Start with four tomorrow, not fifteen

When a turn goes wrong, edit or rewind instead of building on the mistake. When the job changes, open a clean task. When a file is large, search it before the model reads it. When a step has one right answer, make it code.

Then install the skill and let it handle the boring parts. Your job is not to use a weaker AI or do less useful work — it is to stop making the AI reread, reload, regenerate, and rediscover things the current result does not need.

What is still an open goal

The full-day target is a 90% reduction in reported reused input while keeping the same amount and quality of finished work. Against the July 26 baseline that would mean bringing 3,588,555,136 reused input tokens down to no more than 358,855,513 on a comparable day.

That full-day result has not been reached. What has been shown is that on one matched job, reported reused input fell to zero while the required facts and structure survived. One job is not a day, and this guide will say so until the day is done.