Prompt compression means removing tokens from your requests without removing information the model needs. Done well, it cuts input cost proportionally and often improves output quality, because a tighter prompt is also a clearer one. Done carelessly, it introduces ambiguity that shows up as eval regressions weeks later. The techniques below are ordered from safest to most dangerous.
Cut what carries nothing
Boilerplate and hedging. Phrases like "please make sure to always carefully…" survive from prompt to prompt by copy-paste. Anthropic's prompting guidance favors clear, direct instructions — the golden rule being that if a colleague with minimal context would be confused, Claude will be too. Directness is both a quality technique and a compression technique.
Redundant examples. The official guidance recommends 3–5 relevant, diverse few-shot examples wrapped in <example> tags. If your prompt carries fifteen examples, the last ten are probably paying rent without working. Trim to the diverse core and check the eval.
Verbose formatting. Consistent, descriptive XML tags (<instructions>, <document>) are the recommended structure and are cheap; multi-line decorative banners and repeated section recaps are not.
Reference-by-ID instead of inlining
The biggest wins come from not sending data at all. If your prompt inlines a full customer record, product catalog, or policy document when the task touches two fields, replace the blob with a compact identifier plus just the fields the task needs — or give Claude a tool to fetch details on demand, so tokens are spent only when the model actually asks. The same logic drives retrieval-based designs generally: send the relevant chunk, not the corpus. When you do need long context, follow the documented long-context guidance — longform data at the top, query at the end (which can improve response quality by up to 30%) — so you are at least buying accuracy with those tokens.
Abbreviations: the sharp edge
Replacing "purchase order" with "PO" everywhere saves tokens, and Claude handles common abbreviations fine. The risk is ambiguous shorthand: internal jargon, overloaded acronyms, or single-letter field names in schemas. A safe pattern is to define each abbreviation once ("PO = purchase order") in the cached system prompt and use the short form thereafter — the definition costs a handful of tokens one time; the expansion would cost tokens forever. Never abbreviate anything a new employee at your company would have to ask about, because the model is in exactly that position.
Templating — and the cache trap
Compression interacts with prompt caching, and the cache usually wins. Cached prefix reads are billed at 0.1x the base input price, so a stable long prompt can be cheaper than a varying short one. Concrete arithmetic at Claude Sonnet 5's listed introductory input price of $2 per million tokens: a 10,000-token system prompt served as a cache read costs $0.002 per request ($0.20 per million cache-read tokens), while a hand-compressed 3,000-token prompt that changes per request and never caches costs $0.006. The "optimized" prompt is three times more expensive.
Structure templates so all static content — instructions, definitions, examples, tool schemas — forms an identical prefix, with per-request variables appended at the end. Serialize any JSON deterministically (in Python, sort_keys=True), since non-deterministic key order is a classic silent cache killer.
Measure before and after
Token intuition is unreliable — and the newer tokenizer used by Claude Opus 4.7+, Sonnet 5, and Fable 5 produces roughly 30% more tokens for the same text than earlier models, so numbers from last year do not transfer. Use the free token-counting endpoint against the exact model you run in production:
from anthropic import AnthropicVertex
client = AnthropicVertex(project_id="my-project", region="global")
count = client.messages.count_tokens(
model="claude-sonnet-5",
system=COMPRESSED_SYSTEM_PROMPT,
messages=[{"role": "user", "content": sample_input}],
)
print(count.input_tokens)Count the old and new versions, diff them, and run your accuracy eval on both. A compression that saves 20% of tokens and costs two eval points is not a savings — it is a quality incident on a payment plan.
Where to go next
Continue with maximizing cache hit rates, auditing prompt length, and the token counting API.