Short answer: yes. Most prompt compression breaks provider prompt caching. If a compressor rewrites your prompt per request, the token prefix changes on every call — and provider caches match on exact prefixes. Different prefix, cache miss. You save 40–60% on token count and silently give back a discount worth up to 90% of input cost on the tokens you kept.
This is the question almost nobody in the LLM cost-optimization market addresses, and it determines whether the two most powerful savings levers stack — or cancel.
Provider prompt caches (Anthropic, OpenAI, Google) work on a simple contract: send the same leading tokens again and the provider re-serves them at a deep discount — roughly 0.10× input price on Anthropic cache reads, about 0.50× on OpenAI cached input. The discount applies only to an unbroken prefix that exactly matches a previous request.
Compression optimizes the opposite way. A query-aware compressor (the LLMLingua family and its descendants) looks at the current question and deletes the tokens least relevant to it. That is exactly what makes it effective — and exactly what makes the output different on every call. The compressed system prompt for query A and the compressed system prompt for query B are different token sequences. Neither matches the cached prefix of the other.
The failure is invisible. Nothing errors. Your token counts go down, your dashboard shows compression working — and your effective input price quietly goes up, because every call is now a cache write instead of a cache read.
Take a 50,000-token context on a model at $3 per million input tokens, called 100 times per hour.
The compressed pipeline moves 4.5× more money for the same workload. Compression that "saves 50%" made the bill worse, because it was competing against a 90% discount it destroyed. A recent two-tier cost model of exactly this interaction (Cache-Aware Prompt Compression, arXiv 2607.15516) reaches the same conclusion: under per-query compression, "every call is a cache miss."
The crossover depends on your cache hit rate and repeat structure: compression wins on one-shot traffic with no reusable prefix; caching wins on agentic and RAG workloads where the same context returns dozens of times within the TTL. Most production spend is the second kind.
Yes — but only if compression is designed around the cache boundary rather than the individual request. That means:
This is the design principle Trimio's compression is built on — it is cache-preserving by construction, and it is why we publish a per-request savings receipt showing compression savings and cache reads on the same request, so the stacking is verifiable rather than claimed.
cache_read_input_tokens (Anthropic) or cached_tokens (OpenAI) in your API responses, before and after enabling any compression or gateway.The same audit applies to gateways and routers generally: any layer that rewrites, reorders, or re-routes prompts across providers can invalidate prefixes. (Multi-provider routing has a version of this problem too — a router that moves a conversation between providers abandons the cache it built on the first one.)