Independent AI intelligence Two editions daily · ET
Fervor AI
Menu

Analysis · October 30, 2026 · repo

Microsoft TokenEconomizerClaude CodeCodexclaude-codecodexagent-harnessai-skills

Microsoft's TokenEconomizer Cuts AI Coding Agent Costs by Pruning Tools You Never Use

Every tool your agent could use is billed on every request. This plugin drops the unused ones, with some fine print.

Your coding agent pays rent on tools it never touches.

Every time Claude Code, Codex or a similar agent sends a request to its model, it packs in a description of every tool it has loaded: file editing, search, the browser, each MCP server (a plug-in that hands your agent extra tools, like a database or a browser) you connected three weeks ago and forgot about. The model needs those descriptions to know what it can call. You pay for them whether it calls them or not, on every single turn.

TokenEconomizer, a new open-source plugin from Microsoft, goes after that bill. Its README says it plainly: "Every loaded tool's definition is sent with every request." The plugin watches which tools your agent actually uses in a given repo, and after enough evidence, it switches off the rest. It also adds a guard for agents stuck in loops and an optional memory for small repo facts.

Microsoft's own benchmark puts the savings at 18 to 31% of mean cost. That is a real number worth testing. It is also Microsoft grading its own homework, on agent versions that are already a step behind. Here is what the plugin does, how to try it in ten minutes, and what to watch while it runs.

What TokenEconomizer is

TokenEconomizer is a plugin that sits inside your coding agent rather than beside it. It supports Claude Code, Codex, GitHub Copilot CLI and Pi, with opencode marked experimental. It needs Python 3.10 or later and no API key of its own: when it needs a model, it uses your agent's existing login and plan, and its reports include that cost.

It is Apache-2.0 licensed. The first release, v0.1.0, landed on October 26, 2026, and the repo was close to 1,000 GitHub stars by October 30. Everything it learns stays on your machine, in ~/.tokeneconomizer.

The plugin does three things. Two are on by default.

Mechanism 1: tool pruning (on by default)

Think of it as a hotel minibar audit. If nobody has opened the minibar in five stays, the hotel stops restocking it.

TokenEconomizer counts how often each tool goes unused in a repo. By default, a tool is a candidate for removal after it sits idle across 10 prompts spread over at least 2 sessions, or across 5 sessions of any length. Once it decides, it waits until your sessions in that repo have been idle for 60 minutes and then writes a deny list (the agent's own "never load these" setting). (The current README adds a fallback: a day after the list formed, whichever comes first.)

It writes that list through each agent's own settings, which is the detail I like most, because you can open the file and read it:

  • Claude Code: single tools, in .claude/settings.local.json
  • Codex: capability packages, in .codex/config.toml
  • Copilot CLI: whole MCP servers, in .github/copilot/settings.local.json
  • Pi and opencode: nothing yet

Undoing it is one command, toolprune restore. That removes only the plugin's own entries, and the README says it never touches deny rules you wrote yourself. Tools you restore are not pruned again.

Mechanism 2: the loop guard (on by default)

Every developer who has used a coding agent has watched one try the same fix five times against the same failing test. Each try costs a full request, with the whole conversation and every tool attached.

The loop guard first learns what a normal turn looks like in your repo. It waits for 5 turns that ended well, with no failing check after the last edit. After that, when a turn keeps hitting the same failures, a judge model checks whether the agent is stuck. If the judge is at least 70% confident, the agent gets "a short note, added to its context, to try another approach." It does this at most once per turn by default.

There is also a backstop that skips the judge: a turn running past 2.5 times the usual length while churning the same edits through the same failures gets the redirect anyway. If the agent still looks stuck after the note, you see a message saying so. The plugin never stops a turn itself. That stays your call.

Mechanism 3: micro-skills (off by default)

Micro-skills are small, learned repo facts: use python -m pytest because bare pytest is missing here, or run npx tsc because tsc isn't on the path. The plugin gathers them from failures that repeat across sessions and from a model that reviews recent sessions every 3 sessions. A fact gets stated at the start of each session once three sessions have confirmed it, and it gets dropped if later sessions contradict it.

It is off by default because the review step adds model calls. A cheaper mode, microskills=envfacts, learns only from repeated failures and makes no model calls at all.

The numbers, and whose they are

Microsoft ran 277 tasks from SWE-Bench, a standard set of real GitHub bug fixes, across six repositories and five agent and model combinations. Each task ran as its own session, in order per repo, starting with nothing learned, and the plugin's own model calls count toward cost.

Mean cost fell between 18.4% and 30.9%, and every one of the 30 pairings of repo and agent setup got cheaper. Success rate on the first try rose in four of five combinations. The odd one out: Claude Code with Opus 4.8 saved the most (30.9%) but lost a point of first-try success. Other test sets showed smaller cuts: 16 to 21% on Web-Bench and 6 to 20% on two security-audit benchmarks.

These are the authors' measurements, and they were taken on older agent builds: the experiments README installs Claude Code 2.1.170, Codex 0.153.1 and Copilot CLI 1.0.84-7. The experiments/ folder has rerun instructions for SWE-Bench and Web-Bench, which is more than most projects offer, though you need Linux, Docker and about 200 GB of disk. The security task sets ship with the code, but that harness "does not run or grade them." I found no outside replication.

Put this into practice

Here is the shortest path for Claude Code. Keep the marketplace path absolute, which $PWD handles for you. The --branch v0.1.0 flag pins the release reviewed here instead of the moving main branch.

git clone --branch v0.1.0 https://github.com/microsoft/TokenEconomizer.git
claude plugin marketplace add "$PWD/TokenEconomizer"
claude plugin install tokeneconomizer@tokeneconomizer

Start claude in a repo you work in often, trust the folder, and run:

/tokeneconomizer:status
/tokeneconomizer:toolprune refresh-catalog

The first command shows what the plugin sees. The second records every tool a session loads, without a model call, so pruning can consider all of them. Run it once per machine and again after Claude Code updates.

Codex and Copilot CLI follow the same three steps with codex plugin marketplace add / codex plugin add and copilot plugin marketplace add / copilot plugin install. On Pi it is a single line: pi install git:github.com/microsoft/TokenEconomizer.

Then work normally for a few days. What to expect:

  • Nothing visible at first. Pruning needs 5 sessions or 10 idle prompts across 2 sessions before it acts, then an idle hour.
  • A change in your settings file. In Claude Code, check .claude/settings.local.json after a few days and read the deny entries. If a tool you use monthly got pruned, run toolprune restore.
  • Loop-guard notes in the transcript, not the main view. In Claude Code, plugin messages appear only in the detailed transcript (Ctrl+O).

Three settings worth knowing:

/tokeneconomizer:config set toolprune_evidence=20   # wait for 20 idle prompts, not 10
/tokeneconomizer:config set microskills=envfacts    # learn repo facts with no model calls
TE_DISABLE=1 claude                                 # turn the plugin off for one session

Add --global to a config set to apply it to every repo.

Who should try it first, and who should wait

The best fit is the developer with one or two repos they open every day and a pile of MCP servers they connected while experimenting. That person has the most dead weight on every request, and enough repeat sessions for the plugin to learn from. Long agent sessions help too, since the tool list rides along on every turn of a long conversation.

Teams that pin their agent version are another good fit. If your company holds Claude Code or Codex at a fixed release for a few weeks, you can stay inside the tested window on purpose.

Wait if you upgrade your agent the day a release lands, or if most of your work is one-off repos you open once and never again. The plugin learns per repo, so a repo you touch twice gives it nothing to work with. And if your agent mostly runs unattended in CI, remember that the loop guard can only nudge, and nobody is there to read the nudge.

Honest limitations

The tested version window is narrow and already behind. The README lists Claude Code 2.1.300 to 2.1.310 as supported and says newer versions are untested. Claude Code 2.1.314 reached npm on October 30. Codex support covers 0.153.1 to 0.164.0. If you track the latest agent release, you are outside the tested range today.

The savings are self-reported. Good methodology, published rerun instructions, still one team measuring its own plugin. Run it on your own repo and compare a week of spend before and after.

Pruning guesses from your past. A tool you use rarely but need badly, like a deploy MCP server you touch once a month, looks exactly like a tool you never use. The restore command is quick, but you have to notice first.

Headless runs get no rescue. In headless runs, where the agent works unattended in a script or CI job and nobody is watching, the README says a flagged turn runs until it ends or hits the agent's own limits. The loop guard nudges; it doesn't pull the plug.

Coverage is uneven. Pi loads only four tools, so pruning doesn't apply there. On opencode, pruning removes nothing yet. The loop guard and micro-skills both spend model calls on your plan, which the benchmark counts but your budget also feels.

Where this leaves you

The useful idea here is bigger than one plugin. Your agent's bill covers more than the code it writes. A good share of it is luggage carried on every request: tool definitions, idle MCP servers, a conversation that keeps growing. TokenEconomizer makes that luggage visible and trims it with an undo button.

Try it on the one repo where you run your agent most. Give it a week. Then open .claude/settings.local.json and see what it decided you didn't need. Whether you keep the plugin or not, that list will tell you something about how you actually work.

Sources: microsoft/TokenEconomizer README (main branch, read October 30, 2026; release v0.1.0); TokenEconomizer releases; experiments README at v0.1.0; Claude Code changelog; @anthropic-ai/claude-code on npm.