So I wrote Butcher, a skill for coding agents designed around a fairly simple idea: cut the token fat without cutting any of the engineering meat. That distinction is important because the goal is not to make an AI respond with the fewest possible words. I don't want code golf, half-finished implementations, skipped tests, missing validation, or some horrifying compressed shorthand that looks like two cavemen arguing over a stack trace. I want the same quality engineering work with less garbage wrapped around it.
The basic formula behind Butcher is useful engineering work / total tokens. Everything in the skill is built around improving that ratio while keeping correctness firmly at the top of the food chain.
Tokens Are Cheap Until You Use Enough of Them
A single bloated response isn't particularly interesting. The problem becomes more obvious when you're working inside a large repository for several hours and the agent keeps carrying unnecessary information forward. It reads a file, then reads the same file again. It searches for something it already found. It pulls an entire directory when it needed one class. It dumps thousands of lines of successful test output into context and repeats your requirements back to you before every major action, presumably in case you forgot what you asked while waiting twelve seconds for dotnet test.
None of those things are individually catastrophic, but together they chew through context, increase cost, slow down the session, and eventually push useful information out of the working window. The irritating part is that none of that waste makes the code any better.
A lot of token optimization advice tries to solve this by simply making the model say less or think less. That wasn't what I wanted, because saving tokens is not particularly impressive if the result is bad software. Butcher explicitly protects correctness, requirements, security, testing, maintainability, compatibility, documentation, validation, authorization, data integrity, concurrency correctness, and the other things I'd rather not discover were removed because the AI was trying to save a few tokens.
If a task legitimately requires 500 lines of code, it should write 500 lines of code. Code is the product. Code is not the fat.
Stop Telling Me What You're About to Do
One of the biggest things Butcher attacks is narration. Coding assistants have developed a strange habit of turning ordinary development work into live sports commentary where every tool call apparently needs an introduction.
"I'm going to inspect the repository. Now I'm going to locate the relevant service. Next I'll update the implementation. After that I'll run the tests."
Fantastic. I assumed some programming might eventually occur.
Butcher tells the agent to act instead of narrating when tools are available. If it needs to search for AuthenticationService.cs, it should search for it. If it needs to edit a method, it should edit it. If it needs to run the tests, it should run them. I don't need a paragraph announcing each of those events because the actual work already tells me what is happening.
There are legitimate reasons for an assistant to stop and talk during execution. It might need information that cannot be discovered from the repository, it might be about to perform something destructive, it might hit a blocker, or it might find a real security concern. Those are useful interruptions. Telling me that it successfully opened a file is not.
Context Is a Budget
One of the more important ideas in Butcher is that context should be treated like a finite resource instead of an all-you-can-eat buffet. Just because the agent can read the entire repository does not mean it should.
The preferred approach is to search first, locate the relevant symbol or range, inspect the callers and contracts that actually matter, check the related tests, and only expand outward when the evidence says more context is needed. That is considerably more useful than dumping twenty files into the model and hoping enlightenment occurs somewhere around line 14,000.
Butcher also tells the agent not to knowingly reread unchanged files, repeat equivalent searches, regenerate plans it already understands, or rediscover facts that were established five minutes ago. Once something is known, it should remain known until there is a reason to believe it has changed. This sounds obvious when written down, which is usually a good indication that an AI assistant will occasionally do the exact opposite.
The rule is simple: load context because it can change an engineering decision, not because the context exists.
Tool Output Is Still Context
The same logic applies to tool output. A shell command may be cheap to run, but the thousands of lines it spits back into the model are still tokens that now have to be carried around.
Butcher prefers targeted searches, narrow line ranges, focused diffs, filtered logs, failing test names, and the specific error text needed to diagnose a problem. If a test suite passes, I generally need to know that it passed. I don't need the complete life story of every test case that behaved exactly as expected.
Failures are different. If something breaks, the agent should retain enough exact information to understand why. Butcher is very explicit about not hiding errors or trimming away evidence just because the output is ugly. The goal is efficient context, not blissful ignorance.
Don't Solve Token Waste by Writing Worse Software
This was probably the most important rule to get right because it would have been very easy to make Butcher overly aggressive. I didn't want a skill that rewarded fewer files, fewer abstractions, fewer tests, or shorter implementations just because those things happen to consume fewer tokens.
Butcher tells the agent to prefer the smallest correct change, which is very different from the smallest change. Before adding new machinery, the agent should check whether the requirement can already be satisfied using existing project code, established patterns, the standard library, or a dependency that is already installed. That helps reduce unnecessary work, but it cannot remove necessary architecture simply because fewer lines would be cheaper.
The skill also explicitly protects validation, error handling, authorization, sanitization, transaction safety, resource cleanup, accessibility, observability, regression protection, and maintainability. Those aren't optional decorations to be removed when the token meter starts looking uncomfortable. If they are necessary for the task, they stay.
Verification Still Matters
Another easy way to create the illusion of efficiency is to stop testing things. Technically, skipping verification does save tokens, right up until the implementation is wrong and you spend three times as many tokens fixing it.
Butcher uses the smallest sufficient verification that can actually prove the work. That might be a targeted unit test, a relevant integration test, a build, type checking, linting, a focused reproduction of the bug, or a security check when the task warrants one. It starts narrow and expands when the risk or the failures justify it.
What it does not do is run every possible test purely for ceremony when a focused check proves the same thing. It also does not skip broader validation when broader validation is actually necessary. The decision is based on confidence and risk, not on whether the command produces an annoyingly large amount of text.
The Output Should Tell Me What Matters
Once the work is done, Butcher becomes especially aggressive about cutting the fat. A successful coding task should usually tell me what materially changed and whether the verification passed. It should not give me a guided tour through every method it touched, paste code that was already written to disk, reproduce the entire diff, explain what a unit test is, and finish with a motivational paragraph about how the implementation is now "robust and maintainable."
If I ask for an explanation, documentation, architecture discussion, tutorial, report, or walkthrough, then that prose is part of the work product and Butcher allows it. The point isn't to make the assistant mute. The point is to stop it from producing information nobody asked for and nobody needs.
Code review follows the same philosophy. If there are problems, give me the findings, order them by severity, tell me where they are and how to fix them. If there aren't any problems, say there aren't any problems. We don't need to commemorate the occasion with an essay.
Compression Without Losing Meaning
Butcher also deals with user input, because I'm perfectly capable of being part of the token problem. Sometimes a prompt needs a lot of detail, especially when describing architecture, constraints, edge cases, compatibility requirements, or acceptance criteria. Other times I may explain the same thing three different ways because I'm thinking through the problem while I type.
The skill lets the agent compress that into a smaller internal working representation, but only when the meaning can be preserved. Exact paths, identifiers, versions, numbers, error messages, negations, exceptions, security requirements, and acceptance criteria are protected. Words like "not," "never," and "except" have an unfortunate tendency to become extremely important when somebody deletes them.
Butcher isn't supposed to turn a normal request into fake shorthand just so the prompt looks smaller. Semantic density matters more than appearance. If shortening something creates ambiguity, it stays.
The 50 Percent Goal
The development target for Butcher is at least a 50 percent median reduction in total token usage compared with an equivalent baseline, with no measurable loss in quality. That includes input tokens, cached context, output tokens, reasoning tokens, repository retrieval, tool output, repeated turns, duplicate code, and unnecessary implementation.
The important part is the second half of that target. Fifty percent fewer tokens is meaningless if the tests start failing or the implementation becomes worse. Butcher is supposed to remove waste, not intelligence.
There will also be tasks where there simply isn't fifty percent worth of fat to cut. That's fine. If the task is already efficient, the correct answer is to leave the meat alone instead of hacking pieces off until a benchmark looks pretty.
Why I Built It
I don't think AI coding tools have a token problem because they are incapable of being concise. I think they have a discipline problem. Models are trained to be helpful, conversational, explanatory, cautious, and thorough, all of which are good traits until every file edit starts sounding like a project kickoff meeting.
When I'm using an AI as a programmer, I don't need it to constantly prove that it's helping me. I need it to understand the problem, inspect the right things, write good code, test the result, tell me what matters, and then stop talking.
That's what Butcher is meant to enforce.
It isn't there to make the model dumber, quieter, or artificially terse. It is there to make the work denser. Less repetition, fewer unnecessary reads, smaller tool outputs, less ceremony, less code echo, and fewer paragraphs explaining actions that already happened.
Cut the fat. Keep the meat. Try not to narrate the knife.
No comments yet.