Abstract. Model routing, prompt compression, and prompt caching each independently reduce LLM cost, and each has its own body of evidence: routing sends a request to the cheapest capable model, compression shrinks the tokens that request carries, and caching discounts tokens a provider has already seen. Most teams that adopt more than one of these levers estimate the combined benefit by adding the individual percentages together. This post models what actually happens when the three are stacked on the same modeled 8-turn agentic workflow. The combined saving is smaller than the additive estimate, because the levers overlap: compression's best targets are frequently the same repeated tokens caching already discounts. Worse, one common implementation mistake, compressing the same prefix a cache is keyed on, does not just shrink the caching lever's contribution, it can flip it negative. In our model, applying all three levers in the wrong order costs more than applying just two of them correctly. All figures are illustrative, modeled from public Anthropic pricing mechanics and a synthetic agent-session workload, not derived from proprietary production traces. Clearly labeled throughout. The setup: one workload, three levers, eight configurations. The starting point is the identity every LLM bill reduces to: cost = tokens × price per token Three of the most common optimization levers each attack a different part of that equation. Routing attacks price per token, by sending a request to the cheapest model that can still handle it. Compression attacks tokens, by removing repeated schemas, minifying tool output, and dropping content the model doesn't use. Caching attacks price per token on a specific subset of tokens, the ones that repeat unchanged across turns, by billing them at a steep discount instead of the full rate. To measure how these three interact rather than how each performs alone, we modeled a synthetic 8-turn agentic session: a support-and-research assistant that reasons, generates search queries, retrieves tool and document context, re-reads that context, and synthesizes an answer on every turn. The naive baseline runs the entire session on a single premium-tier model, no routing, no compression, no caching. Per turn, that baseline sends 10,700 input tokens and produces 2,500 output tokens. At an illustrative premium rate of $5 per million input tokens and $25 per million output tokens, consistent with current frontier-tier pricing, that is $0.116 per turn, or $116.00 per 1,000 turns. We then modeled each lever's independent effect, each pairwise combination, and the full three-lever stack in both a correct and an incorrect implementation order, holding the underlying task and quality bar constant across all eight configurations. Research question. When model routing, prompt compression, and prompt caching are combined in an agentic pipeline, do their cost savings add, multiply, or interfere with each other, and does the order in which they're applied change the outcome? Where a naive turn's tokens actually go. Before stacking anything, it's worth seeing what the $116.00 baseline is actually paying for. Chart 1: Token consumption by workflow stage in a naive agent turn — retrieved context is 46% of the turn, more than reasoning, synthesis, and query generation combined | Workflow stage | Tokens | % of turn | |---|---:|---:| | Retrieved context (tool + RAG results) | 6,100 | 46% | | Final synthesis (output) | 2,500 | 19% | | Result reading / re-grounding | 2,330 | 18% | | Reasoning / planning | 1,850 | 14% | | Search query generation | 420 | 3% | Retrieved context alone is close to half the turn, which matters for what comes next: it's the largest single target for compression, and, separately, it's rarely the same content twice, which is exactly why caching barely touches it. Reasoning and synthesis, the tokens actually driving the answer, are under a third of the turn combined. Consistent with prior findings that retrieval and re-grounding, not the final answer, dominate agent token budgets. Retrieval research has shown for years that models use only a fraction of what they're given regardless of how much is provided. Source: Liu et al., "Lost in the Middle: How Language Models Use Long Contexts," arXiv:2307.03172, 2023 Stacking three levers: eight configurations, one number that doesn't add up. Here is where the naive assumption breaks. Routing alone cuts the bill 45%, to $63.80. Compression alone cuts it 26%, to $85.84. Caching alone, discounting only the static system prompt and tool schemas that repeat unchanged across the 8-turn session, cuts it a modest 8%, to $106.72. Add those percentages and the intuition says: 45 + 26 + 8 = 79% off, landing around $24.36. That is the naive-additive prediction, and it is the number most teams write into a slide deck before they've measured anything. Chart 2: Cost per 1,000 agent turns across nine configurations — naive addition predicts $24.36 for all three levers combined, the measured cost with correct sequencing is $43.38, and reversing the compression/caching order costs $49.63 | Configuration | Cost / 1,000 turns | vs. naive | |---|---:|---:| | Naive (single premium model) | $116.00 | baseline | | Caching only | $106.72 | -8% | | Compression only | $85.84 | -26% | | Compression + Caching | $78.97 | -32% | | Routing only | $63.80 | -45% | | Routing + Caching | $58.70 | -49% | | Routing + Compression | $47.21 | -59% | | Naive-additive prediction (all 3) | $24.36 | -79% | | All three, correct order | $43.38 | -63% | | All three, wrong order (compression breaks cache) | $49.63 | -57% | The measured combination is multiplicative, not additive: 1 − (0.55 × 0.74 × 0.92) ≈ 63%, not 79%. Each lever's percentage is measured against the full original bill, but by the time a second lever is applied, the first has already removed some of what it would have acted on. Compression's biggest target, repeated and low-information context, overlaps with caching's biggest target, static content that repeats unchanged. Take one before the other and the second lever has less overlap left to work with than its solo number implies. The wrong-order row is the one worth sitting with. If the compression pass rewrites the same system prompt and tool schema text a cache is keyed on, that prefix no longer matches the cache on the next turn, and every turn re-writes it at the 1.25x cache-write premium instead of reading it at a 90% discount. The result in our model: routing, compression, and caching all three enabled, at a higher cost than routing and compression alone with no caching attempt at all. The three-lever stack didn't just under-deliver, it lost to a two-lever stack. We've measured this same cache-fragility mechanism separately, in the context of routing a session to a cheaper model mid-conversation. The same fix that cuts cost also cuts latency. A common worry is that cost optimization trades away speed. In retrieval, the opposite tends to hold. Chart 3: Latency by retrieval strategy — sequential search-then-read averages 7.9s P50, an optimized pipeline with parallel search, selective read, and cached schemas reaches 3.0s | Retrieval strategy | P50 | P95 | |---|---:|---:| | Sequential search → read → search → read | 7.9s | 14.6s | | Parallel search, sequential read | 4.8s | 9.0s | | Parallel search, selective read (top-3 only) | 3.6s | 6.8s | | Optimized pipeline (parallel + selective + cached schema) | 3.0s | 5.5s | Selective reading, fetching a ranked shortlist and only expanding the passages the model actually cites, cuts P50 latency 62% in this model, using the same mechanism that removes the token waste in the chart below. Parallelizing search calls compounds on top. Neither requires a smaller or cheaper model. Cost versus quality: the dangerous zone is still downgrading blind. Stacking levers correctly is not the same as stacking them aggressively. The riskiest move in this whole exercise isn't routing, compression, or caching, it's swapping to a cheap model everywhere and calling it optimization. Chart 4: Cost vs. quality across four strategies — hybrid routing reaches 93% task success at $43.38 per 1,000 turns, small-model-first reaches 69% at $15.10, premium-only reaches 97% at $116.00 | Strategy | Cost / 1,000 turns | Task success rate | |---|---:|---:| | Premium-only (always frontier) | $116.00 | 97% | | Small-model-first (aggressive downgrade) | $15.10 | 69% | | Aggressive compression (no routing change) | $68.00 | 88% | | Hybrid routing (task-classified) | $43.38 | 93% | Small-model-first is the cheapest option here, and it's cheapest for the reason teams fear: a 28-point quality drop invites retries, and a retried task on a cheap model can cost more in aggregate than a correct answer from an expensive one on the first try. Aggressive compression alone does better on quality than blind downgrading but costs more than hybrid routing for a worse result, evidence that compression has a ceiling once it starts trimming content the model actually needed. Hybrid routing, classifying each step's complexity and sending only the steps that need it to the premium tier, lands closest to premium-only quality at roughly a third of the cost. Where the waste actually lives. Chart 5: Token waste breakdown — irrelevant retrieved chunks account for 38% of overhead tokens, duplicate context 20%, verbose tool output 16%, over-reading 15%, repeated reasoning 11% Irrelevant retrieved chunks never cited (38%): content fetched because a query returned it, not because the model needed it. Duplicate context (20%): the same tool output surviving in both the raw fetch and the accumulated conversation history. Verbose tool / API output formatting (16%): unminified JSON and pretty-printed responses that carry no information the model uses. Over-reading full documents past the cited passage (15%): fetching an entire document when the model quotes one paragraph of it. Repeated reasoning steps across retries (11%): re-deriving the same intermediate conclusion after a failed tool call or a retry. Irrelevant chunks and duplicate context alone are 58% of all overhead. Neither category is addressed by picking a cheaper model; both are addressed by tightening what gets retrieved and re-sent in the first place, which is also the reason routing and compression compound rather than substitute for each other. Implementation framework. Step 1: Instrument token usage by stage. Log input tokens before and after each addition, system prompt, tool schemas, retrieved context, history, at every turn. Most teams' actual distribution differs from their assumption before they measure it. Step 2: Separate reasoning tokens from context tokens. History and task instructions are what the model needs to reason; retrieved chunks and tool output are supplied context. The second category is where most of the waste in the chart above lives. Step 3: Detect over-reading and duplicate retrieval. Track citation rate: what fraction of retrieved chunks the model actually references in its answer. A citation rate under 50% signals retrieval precision, not model capability, is the problem. Step 4: Route simple steps to cheaper models. Query generation, chunk relevance scoring, and tool-output summarization are classification-grade tasks a smaller model handles correctly the large majority of the time, at a fraction of the per-token cost. Step 5: Compress only after retrieval, and only the dynamic portion. Compress what changes turn to turn, retrieved chunks, tool output, history, never the static system prompt or tool schema a cache is keyed on. Compressing the wrong slice is the specific mistake behind the wrong-order row above. def prepare_request(static_prefix: str, dynamic_context: str, tools: list) -> dict: Static prefix stays byte-identical so the provider's prompt cache keeps matching it. Only the dynamic slice gets compressed. compressed_context = compress(dynamic_context) # dedupe, minify, drop unused return { "system": static_prefix, # untouched, cache-eligible "tools": tools, # untouched, cache-eligible "context": compressed_context, # compressed before billing, not after } Step 6: Add confidence thresholds and fallback logic. A cheap-model step that fails a confidence check should escalate to a stronger model for that step alone, not restart the whole task on the expensive model. Step 7: Monitor cost, latency, and answer quality together, per configuration, not per lever. The eight-row table above is the reason: a lever's solo number is not what it contributes once other levers are already active. Measure the stack, not the sum of its parts. What this means for engineering teams. None of this is an argument against routing, compression, or caching. Each one, alone, is a legitimate double-digit saving with no quality cost when implemented correctly. It's an argument against estimating a combined stack by adding solo numbers, and against treating implementation order as a detail. The tradeoffs worth keeping in view: reducing cost too aggressively (small-model-first with no confidence gating) can cost more than it saves once retries are counted. Caching only pays off when a workflow actually repeats, a one-shot session gets none of its benefit. Compression is only safe when it preserves the information a decision downstream depends on, not just any information. Parallel retrieval reduces latency but can increase the total tokens fetched if it isn't paired with selective reading. And routing needs the same observability as the other two levers; a routing rule with no visibility into what it's actually costing is a guess with better branding. This is the kind of problem an efficiency layer sitting in the request path is built to solve, not by picking one lever and maximizing it, but by sequencing all of them so they compound instead of collide: compress the dynamic context first, leave the cache-eligible prefix untouched, and route on the resulting real cost rather than the original request size. Nadir runs that sequence on every request by default and shows the delta against an always-premium baseline per call, so the question stops being "which lever should we add next" and becomes "what does our actual stack cost today." Conclusion. The future of LLM cost optimization isn't a bigger list of levers, it's measuring how the levers you already have interact. A team that adds routing, compression, and caching and expects their published solo savings to sum has, in this model, overestimated the result by roughly a quarter, and if the implementation gets the order wrong, the caching lever can go from a small win to a net loss. The fix isn't more aggressive optimization. It's treating "how much does the combined stack actually cost" as its own measurement, not an arithmetic exercise performed once and never checked again. Data in this post is illustrative, modeled from Anthropic's public pricing mechanics and a synthetic 8-turn agent-session workload, not derived from proprietary production traces. Sources: Liu et al., "Lost in the Middle: How Language Models Use Long Contexts," arXiv:2307.03172, 2023. Anthropic, "Prompt Caching". Anthropic Claude Pricing.