DEV Community

Cover image for Microsoft's TokenEconomizer cuts coding agent costs up to 30.9%, and it does it by editing your config files
Piekwerk
Piekwerk

Posted on

Microsoft's TokenEconomizer cuts coding agent costs up to 30.9%, and it does it by editing your config files

The short version

Microsoft Research, UC Berkeley and Microsoft Security published TokenEconomizer last week (v0.1.0, October 26, Apache 2.0). It is a plugin for Claude Code, Codex, the GitHub Copilot CLI and Pi that cuts what your agent costs to run, without touching model weights or agent code. On 277 SWE-Bench tasks across six repositories it lowered mean cost per task by 18.4 to 30.9 percent across five agent-model combinations, it came out cheaper in every one of the 30 repository-by-combination cells, and Pass@1 went up in four of the five combinations (paper).

I spend my days on agent config files, so the interesting part for me is not the percentage. It is how the thing works: it learns from your finished sessions, then edits your agent's own configuration so the next sessions start cheaper.

It treats the agent as a black box

The plugin does not fork the agent and does not patch the model. Every change it makes goes through surfaces the agent already reads:

  • Facts are injected as context at session start
  • Tools are removed through the agent's own settings files
  • A stuck turn gets a redirect note attached to a tool result

Cost is counted the way you are billed, with cache pricing, and the plugin's own model calls are included in its reports. Nothing it learns leaves your machine: state lives in ~/.tokeneconomizer.

Three mechanisms, two on by default

Micro-skills (off by default). Sessions keep rediscovering the same facts: a build step that must run first, python -m pytest because a bare pytest is missing, an environment variable some command needs. The plugin learns such facts from failures that repeat across sessions, plus a proposer model that reviews recent sessions every third session. A fact gets stated at session start once three sessions have confirmed it, and dropped when later sessions contradict it.

Tool pruning (on). Every loaded tool's definition rides along with every request, so an unused tool is a flat per-request tax. A tool that goes unused over 10 prompts spread across at least 2 sessions, or over 5 sessions of any length, gets left out of later sessions through the agent's settings. One command brings it back.

The loop guard (on). When a turn keeps hitting the same failures, a judge model checks whether it is stuck. At 0.7 confidence the agent gets a redirect, at most once per turn. If the turn is still stuck after that, the plugin tells you how to stop it. It never stops a turn itself. There is also a hard backstop: a churning turn that runs past 2.5 times its usual length gets redirected without waiting for the judge.

The part that got my attention: it writes to your settings files

This is the detail config people should know. The tool-pruning deny list is not plugin-internal state. It is written into the repository's own config files:

.claude/settings.local.json          (tools, Claude Code)
.codex/config.toml                   (capability packages, Codex)
.github/copilot/settings.local.json  (MCP servers, Copilot CLI)
Enter fullscreen mode Exit fullscreen mode

The write happens only after the repo's sessions have been idle longer than a prompt cache lives, so a resumed conversation does not get its cached prefix rewritten. It takes effect from the next session and is announced at the next session start. toolprune restore gives a tool back for good.

Practically: your settings files now have a second author. If you review config diffs, and you should, expect machine-written deny rules to show up in them. Tools a person relies on (asking you questions, plan mode, subagents, the web) are protected from pruning, and a deny rule written for a tool that has since become protected is rolled back at the next fold.

The numbers, and the one caveat

The best cell was Claude Code with Opus 4.8: 30.9 percent cheaper, rising to 33.2 percent combined with RTK. That same combination carries the one caveat, Pass@1 declined by 1.0 point there (independent coverage). For comparison, the paper reports RTK and RepoMap increased cost in 12 and 15 cells respectively, where TokenEconomizer was cheaper in all 30.

Savings are back-loaded: most repositories cost more at first, and all were cheaper by the sixth task. On Web-Bench it saved 16 to 21 percent, and on two security-auditing benchmarks where every task sits in a new repository, 6.4 to 19.6 percent. The discount scales with repetition. Same repo, recurring work, bigger saving.

Check the version window before you install

The supported-versions table is narrow:

  • Claude Code 2.1.300 to 2.1.310
  • Codex 0.153.1 to 0.164.0
  • Copilot CLI 1.0.83 to 1.0.102
  • Pi 1.2.0 to 1.3.0, opencode support experimental

Claude Code shipped 2.1.316 on October 31, so if you auto-update you are already outside the tested window. The plugin needs no API key of its own and never handles credentials. Its judge and proposer calls run through your existing agent login, on your plan, and are counted in its ledger.

What this means for your hand-written rules

Micro-skills are not a machine-written CLAUDE.md. The facts are session-start context, derived per repository, reversible, and never checked in. Your instruction file stays the contract you and your team actually review.

Two consequences are worth thinking through. First, learned facts are exactly the content that bloats rules files: build commands, command spellings, environment variables. If a plugin absorbs that layer, your file can stick to standards and constraints, which is what it is good at. Second, the paper's savings come from repositories where sessions kept rediscovering the same facts. If you already run a lean, accurate rules file, there is less waste left to remove and your savings will land below the headline. Cheap sessions and disciplined config overlap, and that is fine.

Trying it this week

git clone https://github.com/microsoft/TokenEconomizer.git
claude plugin marketplace add "$PWD/TokenEconomizer"
claude plugin install tokeneconomizer@tokeneconomizer
Enter fullscreen mode Exit fullscreen mode

Start claude in a repository you touch daily, run /tokeneconomizer:status, and let a few sessions finish. Once per machine, and again after Claude Code updates, run /tokeneconomizer:toolprune refresh-catalog. The everyday commands:

/tokeneconomizer:status       # what it learned here and what sessions cost
/tokeneconomizer:microskills  # the facts it injects, and candidates
/tokeneconomizer:toolprune    # tools it left out, with the evidence
/tokeneconomizer:config       # every setting in effect
Enter fullscreen mode Exit fullscreen mode

Inside the agent a command costs a model turn. From a terminal, ~/.tokeneconomizer/bin/te status in the repository is free. If you keep strict deny rules of your own, diff your settings files after the first few folds. Cost control and cache behavior are the same seam: we wrote about splitting agent context across cache TTLs here, and a plugin that manages what gets re-sent is working the same problem from the tool side.

Top comments (0)