Nate builds the "Token Saver Skill" to cut reused token consumption by 90% in Codex and Claude Code

By Nate.

The author starts from a very concrete problem: you hit the limits of a plan you're already paying for without having done anything unreasonable, simply by asking a handful of questions, and somewhere around the tenth question consumption starts climbing far faster than expected.

Nate recounts that, after a long day working in Codex, he opened his own Token Burn tracker and found a total of 3.77 billion tokens. What unsettled him most wasn't the total but the breakdown: of the 3.75 billion input tokens recorded, 3.59 billion (95.73%) were marked as "reused input." He clarifies that this figure comes from his own local event log — not from an OpenAI invoice — and that it covers cumulative usage updates across 143 Codex threads and 28,877 local records. That's why he treats the number as a signal to investigate, not as a clean billable-token total.

A central point of the article is that "reused" does not mean "useless": complex work may depend on a decision made twenty minutes earlier, on a file already modified, on an error that ruled out the obvious solution, or on a paragraph approved after four failed versions. What's more, eligible repeated material can benefit from a cache discount from the provider. For Nate, that continuity is much of what makes these tools useful, but it comes at a cost: a later request may contain far more than the new sentence the user types, including previous exchanges, standing instructions, tool definitions, files, screenshots, browsing results, command output, discarded responses and any state the product needs in order to continue the work. His line sums up the idea: "the tenth message can be much bigger than the first, even if the visible prompt is shorter. You typed less. You paid more."

The author recalls that he had previously argued that a token count is a trace, not a scoreboard, and reiterates that he still believes it: a high-usage day may mean an agent did real work across files, browsers, drafts and checks, and cutting the number without asking what that work produced is a bad way to manage AI. Even so, the finding of 95.73% reused input leads him to pose a different question: how much of that material could still change the outcome of the work, and how much simply lingered because nothing in the system had reason to discard it.

With that question as a starting point, he sets an aggressive goal: cut reported reused input by 90%, without increasing errors, retries, review time or work that has to be redone.

The email, as a preview of paid content, lists what the full article (available to subscribers) includes: a measurement based on real work run two different ways, comparing the figures reported by the provider and explaining what that comparison does and does not prove; fifteen proposed changes, ordered by how well supported they are, each with the conditions under which it helps, the conditions under which it hurts, and whether it was measured or is still a guess; nine of those changes applicable today, habits for keeping material out of a request in the very products you already use, with nothing to install; the "Token Saver Skill" itself, explaining what it does for the user in Codex and in Claude Code, the four changes it imposes and the one limit it cannot cross; an explanation of what caching really costs, comparing the math of a five-minute cache versus an hour, and why cached input never disappears from the bill; and finally, what Nate himself admits he still cannot prove, the limits of having analyzed a single compared job and what the next necessary test would be.

The email closes by noting that paid subscribers get the full analysis and guide, plus access to the author's Slack community. The specific details of the fifteen changes, of exactly how the Token Saver Skill works, and of the figures from the real-work comparison fall outside this introductory email, so they are not included here as they do not appear in the body received.