Watch a coding agent chase down a failing test and you will see the pattern immediately. It reads the whole file to find one function. It greps the same directory three different ways because the first two queries came back too broad. It pastes a full stack trace into its own next prompt, tries something, fails, and pastes the same trace back in again on the retry. None of this is a bug in the agent. It is what an agent does by default when nothing in its instructions tells it to be economical.
At one run, that is a rounding error. Run it across a fleet of agents, all day, on every ticket and every PR, and it is a bill — and a reliability problem too, since long, undifferentiated context makes the model worse at the task, not just more expensive, a point we have made before when talking about why bigger context windows don't fix agent memory. Token cost and context quality are the same lever. This post is about the other side of that lever: not how an agent remembers across sessions, but how it behaves within one, and what a skill written to be economical actually looks like.
Tokens are a variable you control, not a bill you absorb
Three things make token and context cost a genuine engineering problem rather than a finance footnote.
Re-reading is not free, and agents over-read by default. Given a repository and a vague instruction, an agent tends to read more than it needs — whole files instead of the relevant function, whole directories instead of the two files that matter — because reading broadly feels safe when you're not sure what you'll need. Multiply that by every step of a multi-step task and input tokens compound fast.
Retries are the silent multiplier. An agent stuck on a failing approach does not know it is stuck. It tries, fails, and retries with a context window that just grew by the size of the failed attempt. Nothing structurally stops ten passes at the same dead end, and each pass re-pays for everything before it.
Padded output costs on the way out, too. A task that specifies "a five-bullet summary" or "valid JSON matching this shape," with no way to check the output against that contract, will drift — extra caveats, restated context, an apology paragraph — and every extra token bills the same as the ones that mattered.
None of these are exotic failure modes. They are the default behavior of an agent that has not been told to economize, and they are exactly the surface a well-written skill can address.
What a token-saving skill actually does
A skill that saves tokens is not a skill that tells the agent to "be concise." That is an instruction, not a mechanism, and instructions are the first thing an agent forgets under pressure. The skills worth building enforce economy structurally, at the specific points above.
Bounded retrieval. Instead of "read the file," the skill gives the agent a way to search narrowly — by filename or symbol — and get back the passage that matters, not the whole document. Retrieval that also knows to skip binaries, generated directories, and gitignored or secret-looking paths saves tokens and avoids leaking things that should not be in a prompt in the first place.
Compaction, not deletion. When context needs to shrink — before a handoff to a fresh session, or mid-task once a lot of exploration has piled up — the naive move is to summarize everything uniformly, which is how you lose the one exact number or decision that mattered. A better move is to classify what's in context first: constraints, decisions, and exact content are protected; draft reasoning, rejected approaches, and superseded critique are candidates to drop or reference instead of repeat.
Retry control. A loop that has failed the same way twice is not obviously going to succeed on the third try. A skill that tracks retries and returns a hard stop past some threshold — rather than a suggestion to "consider stopping" — is the difference between bounded cost and an agent quietly burning tokens on a dead end until something else intervenes.
Advisory model routing. Not every subtask needs the most capable, most expensive model. A bounded, deterministic transformation — reformat this, extract this field — can go to a cheaper model; an ambiguous architectural decision should not. A skill can recommend the tier without needing to actually control model selection, which stays the caller's decision.
Output contracts. If a task specifies an exact shape — word count, bullet count, a JSON schema — checking the output against that contract mechanically, and failing loudly when it doesn't match, is cheaper than trusting the model to self-regulate on instruction alone.
Those five patterns are mechanism, not prose. That distinction is exactly what makes eavakyan/token-saver-skill worth looking at as a concrete example, because it is one place all five actually show up in working code.
A concrete example: token-saver-skill
token-saver-skill is a small, very new, MIT-licensed open-source project by Gene Avakyan (GitHub handle eavakyan) — full disclosure, the same person writing this post, and the repo's own wiki names it as one part of a toolchain alongside AgentPrizm. It bundles two things: a SKILL.md-based Agent Skill installable into both Claude Code and the OpenAI Codex CLI, and a standalone Python CLI (token-saver, packaged as agent-token-saver) that the skill's instructions call out to.
The design choice that stands out first is that the skill is explicit-invocation only. Its policy file sets allow_implicit_invocation: false, and the README is direct about why: "Implicit invocation is disabled so ordinary tasks do not pay to load the full workflow." A skill that saves tokens has to not spend tokens announcing itself on every unrelated task — the same discipline it argues for elsewhere, applied to itself.
Under the hood, the CLI maps closely onto the patterns above: retrieve for bounded, ignore-aware source search instead of whole-file reads; compact to classify context into protected material (constraints, decisions, accepted artifacts, exact content) versus material safe to drop or reference, producing what the project calls a "safe handoff"; retry-check and retry-reset to stop a failing loop with a real exit code rather than a suggestion; route for advisory model-tier recommendations; and validate-output to enforce word-count, bullet-count, or JSON-shape contracts. State — artifacts, retry counters, handoffs — lives in a small SQLite database scoped per repository and branch, and every invocation gets its own request ID via metrics begin so concurrent agent runs on the same branch don't mix up their numbers.
Installing it, per the README, looks like this:
python3 -m venv ~/.local/share/token-saver/venv
~/.local/share/token-saver/venv/bin/python -m pip install --no-deps .
ln -s ~/.local/share/token-saver/venv/bin/token-saver ~/.local/bin/token-saver
python3 scripts/install.py --platform claude --scope global
token-saver doctor
The scripts/install.py step is worth noting on its own: it creates a symlink back to the repo's skill/ directory rather than copying it, so a git pull in the repo keeps the installed skill current without a reinstall.
What's verified, and what isn't
In the spirit of not overselling a tool because it's a good idea: as of this writing, token-saver-skill has one star, zero forks, fourteen commits, and no tagged releases — created today. There is no adoption data and nothing to compare it against. Treat the description above as "here is a real, inspectable mechanism," not "here is a proven result."
More importantly, the project does not claim savings numbers, and neither should this post. Its own README says plainly that its token counts are "estimates, not billing measurements," and goes further: "It does not intercept model requests, force model changes, erase hidden platform context, or guarantee billing savings." That is the right level of honesty for a tool like this. It changes what gets sent to the model — narrower retrieval, classified compaction, output contracts — but it cannot see or control what your billing dashboard actually reports, and it does not pretend to.
One more thing worth being precise about: token-saver-skill is not an MCP server. There is nothing in its README, SKILL.md, or file tree that references MCP — it is a CLI and a symlinked skill file, invoked locally by whichever agent has it installed. That is a reasonable design for a single-repo, single-developer tool. It is also exactly the kind of thing that gets harder to keep track of the moment more than one person, repo, or team wants to use the same skill.
Finding and governing skills like this one
That last point is the connection worth drawing out. A token-saving skill is genuinely useful the moment you have it installed correctly on the right machine — but "installed correctly on the right machine" is doing a lot of work in that sentence once you have more than one agent, more than one repo, or more than one teammate who wants the same discipline. We've written before about why skill files sprawl into drifting copies without a shared registry, and about why finding the right skill among many needs semantic discovery, not a filename search. A token-saving skill is not exempt from either problem just because its job is to save tokens — it is a SKILL.md file like any other, and it drifts, gets copy-pasted, and becomes hard to find at scale the same way.
That is the gap AgentPrizm's own AgentSkills registry is built to close — not by replacing what a tool like token-saver-skill does inside a single task, but by giving skills like it a governed home once more than one agent needs to find, install, or version them:
skill_search query="reduce context tokens without losing task-critical detail"
skill_install id="<the matching skill>"
That is a small, honest connection, not a pitch for this specific project — token-saver-skill doesn't need a registry to work today. But the pattern generalizes: any skill worth writing once is worth being able to find, trust, and update without re-copying it by hand, and that holds as much for skills that save tokens as for any other kind.
The takeaway
Token and context cost is not something you fix by hoping the model behaves; it is something you fix by giving the agent structural reasons to be economical — bounded retrieval, classified compaction, retry limits, advisory routing, and enforced output contracts. eavakyan/token-saver-skill is a real, inspectable example of that pattern, not a proven savings number, and it is honest about the difference. If you want to see the mechanism yourself, read the repo directly. If you want to see how skills like it get found and governed at scale, browse /skills, read about AgentSkills, or check the docs for the MCP tools and REST endpoints.