Save Twice

The bill has two numbers, and most tools only touch one

The cost of an LLM call is simple:

cost  =  tokens  ×  price per token

Every prompt-compression product attacks the left side. LLMLingua drops low-information tokens. Headroom runs a model that rewrites verbose context. Claude Code hook tools compress tool output before the agent reads it. They are good at what they do, and they all do the same thing: fewer tokens, sent to the same model, at the same price per token.

That leaves the right side of the equation untouched. And the right side is where the biggest lever is. An Opus input token costs roughly 19x a Haiku input token. If the request did not need Opus, compressing its context is optimizing the wrong number first.

Routing attacks the right side. Send each request to a cheaper model that clears the workload's measured bar, and the price per token falls. Nadir's older 60% / 98% RouterBench result is a reference-assisted research ceiling on 11,420 triples, not deployed performance or a customer forecast.

Compression and routing are not competing strategies. They are two factors of the same product. Do both and the savings compound.

Saving twice, in one call

cost  =  tokens  ×  price per token
          ▲            ▲
          │            └── routing: send it to a cheaper capable model
          └── compression: strip repeated schemas, minify JSON, drop dead context

Take an input-heavy agentic workload, the kind where context is the bill.

• Start at an always-Opus baseline. Call it 100.
• Route it. The cheap-but-capable model handles most of the traffic, and the price per token drops. You are at roughly 40.
• Now compress the context that still crosses the wire before it is billed. Even a conservative 15% input reduction on top takes you to roughly 34.

That is the point. 1 minus (0.40 times 0.85) is about 66%, not 60% and not 15%. The second saving lands on the already-reduced bill, not the original one.

There is an ordering detail that matters here, and Nadir gets it right: it compresses first, then ranks models on the compressed cost. A request that was going to be borderline-expensive can become cheap once its context is smaller, and the router sees that. Compression does not just shrink the bill, it changes the routing decision.

Built in, not bolted on

Here is the part that usually gets skipped in the pitch.

To add compression to your stack the normal way, you install a package, or you stand up a sidecar proxy, or you wrap every agent with a hook, and then you keep that dependency current as your providers and SDKs move. It is real work, and it is a second system to operate next to whatever you use for model selection.

Nadir does not ask for any of that. Point your OpenAI-compatible calls at Nadir with model=auto. Compression runs inside the request path, before the model is chosen. There is:

• no pip install of a compression library,
• no separate proxy or guardrail process to deploy,
• no client code change beyond the base URL you already set,
• no second dependency to patch when a provider changes.

The compression is Nadir's own, developed against real routing traffic, not a third-party library you install and keep current. The safe transforms are deterministic and switched on per account, key, or request. They minify embedded JSON, deduplicate repeated tool schemas and system prompts across a request, and normalize whitespace outside fenced code blocks while keeping indentation. Nothing is paraphrased, nothing is guessed, and past 40 user turns the middle of the conversation is trimmed. For heavier context, an aggressive mode adds semantic deduplication, replacing a near-duplicate message with a short reference plus only the phrases that actually changed. Same methods, one endpoint, no extra dependency.

An honest word on the number

We are not going to print one big compression percentage on a banner, because the honest answer depends on your traffic, and we would rather you trust the small number than distrust a large one.

• Plain back-and-forth chat has almost nothing for the safe pass to remove. The savings there are single digits, and that is fine, because routing is doing the heavy lifting on that traffic.
• Tool-using and agentic traffic is where compression earns its keep. Repeated tool schemas and pretty-printed JSON are exactly the shapes the safe pass removes, and the reductions there run well into double digits before the aggressive pass is even involved.

The compressor is not the ceiling. Your traffic is. The more bloated the context, the more the first saving is worth, and either way the second saving from routing still stacks on top.

The takeaway

Compression alone saves you once, on how many tokens you send. Routing alone saves you once, on the price of each token. Run them together and the two savings multiply, on every call, with the compressed size feeding the routing decision.

You do not need another package to get there. It is the endpoint.

Point `model=auto` at Nadir and pay for neither too many tokens nor too expensive a model.