I made a Claude Code plugin called Token Beggar, and today I released version 0.3.0 of it.
I kept running the biggest model at high effort for every step, even when the step was just reading a repo I had never seen. The bill made me curious, so I built something that checks whether a cheaper model can do the job first.
It uses the Claude Code you already have. No extra API, no extra account. It is still in development, and I would love feedback.
What 0.3.0 does
Before the big model starts, the plugin sizes the task.
- Small tasks stay in the chat.
- A large task, like fixing a bug in a repository you have not read yet, goes to one cheaper worker. The worker reproduces, explores, fixes and runs the tests.
- Then the chat reads the whole diff, runs the tests again, and sends the worker back if something is missing.
Design, root causes and the final answer stay with the model you picked. Your chat model and effort are a ceiling, so nothing goes above them.
The result, in plain terms
There are two setups, and only two. Without Token Beggar is the chat model working alone. With Token Beggar is the card shipped in 0.3.0. The chat model is Opus 5.5 at high effort, and cost is list price for the chat and every worker, cache included.
The hard tasks are 18 merged pull requests from 12 open source Python projects (Django, Sphinx, pylint, sympy, click and others). The chat starts from the commit before the fix with only the issue text, and it is scored by the tests the maintainers added, which it never sees. 3 runs per task, 54 runs per setup.
| Setup | Cost per task | Multiple | Issues resolved |
|---|---|---|---|
| Without Token Beggar | $0.69 | 1.00x | 70% |
| With Token Beggar | $0.49 | 1.42x less (1.33 to 1.51) | 69% |
The first chart shows how many times less each of the 18 tasks cost with Token Beggar. 17 bars are past the 1.0x line.
The second chart shows the share of issues resolved, 70% without and 69% with.
Cost per task went down about 29 percent. The share of issues resolved is level, and 69% against 70% is a tie within the spread. Time is level too (168 seconds against 187), so it is not faster. The one task that cost more cost about 10% more.
Why this is not the 1.24x from my first article
My earlier article reported 1.24x cheaper overall. That came from a mix of 21 mostly small tasks, and the routing was different then. Small tasks save very little. Under about 1.15x I cannot tell a saving from run to run noise, so 0.3.0 keeps small tasks in the chat and only hands large ones to a worker.
That change is why the hard task number is bigger. It is also why I do not claim 1.42x for everything. Small tasks were measured only with the earlier card, and they saved little there (1.11x).
Install
You need Claude Code and Python 3.10 or newer. It uses the standard library only.
/plugin marketplace add Arthur031221/Token-Beggar
/plugin install token-beggar@token-beggar
Restart the agent or run /reload-plugins. To check that the hooks run, use token-beggar doctor. To turn it off, set TOKEN_BEGGAR=off for a shell, or uninstall the plugin.
It runs on your machine, writes only to its own folder, and sends nothing about you anywhere. The only network call is one weekly download of the vendor's public models page, to keep prices current.
The limits
I would rather you read these before you try it.
- The hard benchmark covers one chat model and effort (Opus 5.5, high) and Python projects. Sonnet, Haiku and Fable on large tasks are not measured.
- 69% against 70% resolved is a tie within the spread. A blind review by a small model rated the 0.3.0 diffs lower than working alone (0.94 against 1.33 on a 0 to 2 scale). It agrees only weakly with the tests, so I cannot say the code is as good.
- 0.3.0 was not re-run on the small tasks, so expect close to no change on small one-file edits.
- The footer estimate comes from a measured ratio, not from your own task.
- On Haiku, the cheapest model, it does nothing.
The raw runs and the task list are in the repo, so you can check every number.
Repo: https://github.com/Arthur031221/Token-Beggar
Release: https://github.com/Arthur031221/Token-Beggar/releases/tag/v0.3.0
Assisted by Claude/Codex.
Top comments (4)
The blind review score drop from 1.33 down to 0.94 explains why the pass rate held while the diff quality drifted. When a cheaper worker explores the repo and drafts the patch, the parent model reviewing the diff tends to anchor on whatever edit already exists instead of rethinking the file structure. Having the parent model re-run tests against the diff keeps the blast radius contained without paying top-tier token prices for initial grep and file traversal.
Fair, anchoring is plausible but I haven't tested it. All I measured is that the blind review scored the diffs lower and agrees only weakly with the tests. So I wouldn't say the code is as good, only that the hidden tests pass at the same rate.
nice
Thanks!