Most prompts carry tokens that earn nothing. Compression removes that weight without touching the answer, and on a high volume workload the saving is large. Here is how we cut prompt size on Claude while the output holds.
Prompt compression is one of the most misunderstood levers in Claude cost work. People hear the word and assume it means stripping a prompt down until the model starts making mistakes, trading quality for a smaller bill. That is not what compression should be. Done well, it removes only the tokens that were never doing any work in the first place: the redundant instructions, the duplicated context, the verbose framing, the examples that no longer teach the model anything it did not already infer. The output does not get worse because nothing the output depended on was removed. The bill gets smaller because you stop paying to send the model words it did not need. This piece lays out the techniques we use, in the order we apply them, so an engineering leader can run the work and a procurement leader can trust that the saving is real and not borrowed against quality.
No team sets out to write a bloated prompt. Weight accumulates the same way it does in any codebase. A prompt starts lean, then a developer adds an instruction to fix an edge case, then another adds an example to handle a different one, then a third pastes in a reference document because it was easier than summarizing it. Each addition was rational on its own day. Nobody ever goes back to check whether the earlier additions are still needed once the model and the surrounding system have changed. Over a year, a prompt that started at a few hundred tokens becomes several thousand, and most of the growth is sediment. Compression is the act of going back and asking, instruction by instruction, whether each one still earns its place. The first time a team does this they are almost always surprised by how much they can remove.
Begin by counting. For each high volume call, measure the token count of the prompt split into its parts: the system instructions, the static context, the dynamic context, the user input, and the examples. You want to know not just the total but where the tokens live, because that tells you where compression will pay. A prompt that is mostly a large static reference document is a different problem from one that is mostly accumulated instructions, and they call for different techniques. Multiply each prompt by its call volume to get the token weight per workload, and you will find, as with most cost work, that a small number of workloads carry most of the weight. Compress those first. Shaving a rarely called prompt is a poor use of engineering time no matter how satisfying the percentage looks.
The cheapest compression is deletion. Read the system prompt as if you were seeing it for the first time and ask, for each instruction, whether the model would behave differently without it. Many instructions were added to fix a behavior that the model no longer exhibits, or to handle an input that the upstream system now filters out, or to repeat something already stated elsewhere in the prompt. Remove them one at a time and test. The discipline here is to change one thing and check the output against your quality bar, rather than rewriting the whole prompt in one pass and losing track of what caused a regression. Most prompts have a surprising amount of dead instruction that can be cut with no measurable effect, and every token removed is a token you stop paying for on every single call.
The second technique is finding the same information sent twice. This happens constantly in applications that assemble prompts from multiple sources. The system prompt states a rule, then a reference document included later states the same rule, then a few shot example demonstrates it a third time. The model needed it once. Trace the full assembled prompt as it actually goes to the model, not the templates it was built from, and look for repetition. Consolidate each fact to a single clear statement. Deduplication is particularly valuable because it tends to live in the static portion of the prompt that is sent on every call, so the saving compounds across the entire workload volume.
The third technique is rewriting verbose instructions into precise ones. Models do not need polite framing, hedging, or long explanations of why a rule exists. They need the rule. A paragraph that says please be sure to always remember that it is very important to never include personal information in your response can become do not include personal information, and the model follows it just as reliably. Multiply that economy across every instruction in a prompt sent millions of times and the saving is meaningful. The caution here is real, though: tightening language is the technique most likely to cross the line into harming quality if done carelessly, because sometimes the extra words were doing subtle work. Tighten, then test, and keep the change only if the output holds. Precision is the goal, not brevity for its own sake.
When a prompt carries a large reference document, ask whether the model needs the whole thing or only the parts relevant to the task. Often a document was pasted in wholesale when the workload only ever uses a section of it. Replace the full document with a focused summary or with retrieval that pulls only the relevant passage at call time. This is the technique with the largest single saving when it applies, because reference material is frequently the heaviest part of a prompt. It also demands the most care, because removing context the model genuinely relied on will degrade the answer. The way to do it safely is to identify exactly what the model extracts from the document across a sample of real calls, and to confirm that the compressed version still contains that information.
There is a tension worth naming. Prompt caching takes up to 90 percent off the cost of repeated context, which means that a large static block, once cached, is cheap to keep sending. So is it worth compressing something that is already cached? The answer is yes, but with judgment. Caching reduces the cost of the repeated portion dramatically, so the priority order is: cache the stable context first, then compress what remains expensive. Compression still helps even cached content, because the cache write itself is billed and a smaller cached block costs less to establish and refresh. The two techniques work together. Cache the stable parts so you stop paying full price to resend them, and compress the dynamic parts and the cache contents so the underlying weight is smaller in the first place. A workload that is both well cached and well compressed is far cheaper than one that is only one of the two.
Compression is usually framed as an input problem, but output tokens are the more expensive side of the ledger, and a prompt can quietly drive long output. An instruction that asks the model to explain its reasoning, or to be thorough, or to provide examples, will lengthen every response and cost you on the expensive side of the bill. Audit your prompts for instructions that inflate output, and decide whether the use case actually needs the length. Asking the model for a concise answer, or constraining the format, or capping the response, will often cut output tokens substantially with no loss of usefulness. This is compression too, applied to what the model produces rather than what it receives, and because output is priced higher it frequently delivers the larger saving.
The whole credibility of compression rests on proof that the answers did not get worse. Before you compress, assemble an evaluation set of real inputs with known good outputs. After each change, run the set and compare. For tasks with a clear correct answer, this is straightforward accuracy measurement. For open ended tasks, you need a rubric or a model graded comparison, but the principle is the same: you are looking for evidence that the compressed prompt produces output indistinguishable in quality from the original. Keep the change only when it passes. This is what lets you tell a procurement leader, honestly, that the saving cost nothing in quality, and it is what separates real optimization from the reckless stripping that gives compression a bad name.
Apply the techniques in order of return, not difficulty. Deletion of dead instructions and deduplication are cheap, safe, and fast, so do them first. Language tightening is moderate effort and moderate risk, so do it next, with testing. Reference summarization and retrieval is the highest effort and highest risk, so reserve it for the workloads where the reference material is genuinely the bulk of the cost. Across a real application, the early, safe techniques often capture most of the available saving, which means a team can get a large result quickly and then decide whether the harder work is worth it. Measure after each stage so you know what you have banked.
The most durable result is not the one time cleanup but the habit. Once a team has compressed its prompts and seen the bill fall without the quality dropping, it learns to write lean prompts by default and to question every addition. Capture that as a lightweight standard: a new instruction has to justify its tokens, reference material gets summarized or retrieved rather than pasted wholesale, and prompts get a periodic review the same way code gets refactored. Weight will always try to creep back as the application grows, so a standing review, even a quick one each quarter, keeps the run rate low. The cleanup removes the sediment that has built up. The habit keeps it from rebuilding.
Like every token lever, compression pays twice. It lowers your running cost directly, and it lowers the baseline you carry into a commitment negotiation with Anthropic. A buyer who compresses, caches, and routes before committing presents Anthropic with an optimized run rate, which means a smaller and safer commit and a stronger position on the rate. A buyer who commits first locks in a number inflated by waste. This is why we treat the engineering work and the commercial negotiation as a single engagement. For the full framework across model routing, caching, and batch, read the pillar guide, the token optimization playbook.
If you want the compression run for you and turned into a negotiating position, book a strategy call and bring us your highest volume prompts. We will show you what can be removed and what it is worth.
Book a strategy call and we will compress your prompts without touching quality, then turn the saving into a stronger commit.
Book a Strategy CallWeekly intelligence on Anthropic pricing moves and the buyer side counters that work.