Paying frontier prices for routine work
Expensive models doing work a cheaper sibling completes to the same standard — including the migration you finished everywhere except one app.
- A frontier model doing work a cheaper model in the same family completes to the same standard.
- Short prompts running on a large-context model, where a smaller model in the same family serves the same requests.
- The same workload spread across several model families, where one of them serves it all at lower cost.
- A migration you already completed elsewhere, with one application left behind on the old model.executable steps
Paying for the same answer twice
Repeated prompts and prefixes billed at full price because nothing in front of the model remembers the last answer.
- Repeated near-identical prompts that a semantic cache in front of the model would answer without a call.
- Repeated prompt prefixes paying full input price because prompt caching is not switched on.executable steps
- Prompts whose length is dominated by a static preamble that could be shortened or cached.
- Cache writes that are never read back — paying the write premium for nothing.
Paying rush rates for patient work
Latency-tolerant jobs billed at synchronous rates, and calls billed at context tiers their prompts never reach.
- Latency-tolerant work billed at synchronous rates when a batch endpoint would serve it cheaper.
- Calls billed at a long-context tier whose prompts never approach that tier's threshold.
Paying above the market you already use
The same model, cheaper from a provider or region already in your stack.
- The same model available from a provider you already use at a lower per-token price.executable steps
- Traffic served from a region that costs more than an equivalent one you already use.
Paying for nothing at all
Spend on failed calls, and output far longer than the task ever needed.
- Spend on calls that failed — money paid for output nobody received.
- Output token counts far above what the task needs, usually a missing length instruction.
For 3 of the 14, the recommendation ships with steps reviewed to the standard an agent can execute; the rest are advisory, each saying why. Every priced move prices against the pinned model catalog, never a live scrape.
The registry, for engineers
Every rule by its identifier, what it detects, and what must be true of your telemetry before it says anything at all.
route_small_contextShort prompts running on a large-context model, where a smaller model in the same family serves the same requests.
Needs to fire: A material share of calls whose prompt sizes sit well under the model's context tier, and a cheaper target family that is priceable in the catalog.
missing_semantic_cacheRepeated near-identical prompts that a semantic cache in front of the model would answer without a call.
Needs to fire: Telemetry marked cacheable. The upload path does not carry a cacheability signal, so this rule stands down on uploaded data rather than guessing.
prompt_compressionPrompts whose length is dominated by a static preamble that could be shortened or cached.
Needs to fire: Enough calls with large, stable prompt sizes on one application to make the saving material.
region_optimizationTraffic served from a region that costs more than an equivalent one you already use.
Needs to fire: A `region` column. Without it the rule stands down — it will not infer geography.
batchingLatency-tolerant work billed at synchronous rates when a batch endpoint would serve it cheaper.
Needs to fire: A batch or scheduled tariff for the model in the catalog. Where the catalog carries only synchronous, on-demand schedules, the rule cannot price the move and says nothing.
overpowered_modelA frontier model doing work a cheaper model in the same family completes to the same standard.
Needs to fire: Full cache tariffs on the target family, so the comparison is priced rather than assumed, plus an output-cost share or a netted saving large enough to matter.
prompt_cache_adoptionRepeated prompt prefixes paying full input price because prompt caching is not switched on.
Needs to fire: A model whose published tariff includes cache read AND write prices. A family whose cache-write price is unknown is left alone rather than costed at zero.
model_family_consolidationThe same workload spread across several model families, where one of them serves it all at lower cost.
Needs to fire: More than one family carrying comparable traffic on the same application, and a priceable consolidation target.
cache_write_churnCache writes that are never read back — paying the write premium for nothing.
Needs to fire: Cache write tokens in your telemetry with few or no corresponding reads.
migration_laggardA migration you already completed elsewhere, with one application left behind on the old model.
Needs to fire: Evidence in your own telemetry that the move already happened somewhere — this rule reasons from your history, not from a recommendation it made.
provider_arbitrageThe same model available from a provider you already use at a lower per-token price.
Needs to fire: Per-provider endpoints in the catalog for the model in question. A logged `provider` column strengthens the conclusion from an inference to a fact.
context_tier_downgradeCalls billed at a long-context tier whose prompts never approach that tier's threshold.
Needs to fire: A model with tiered context pricing in the catalog and prompt sizes below the tier boundary.
failure_costSpend on calls that failed — money paid for output nobody received.
Needs to fire: A `status` column with real failures in it. On an all-success dataset the rule says nothing, because an absence is not a finding.
output_overheadOutput token counts far above what the task needs, usually a missing length instruction.
Needs to fire: Average output length above the rule's floor on an application with enough traffic for the saving to be material.
Why a demo shows fewer than 14
Every “needs to fire” line above is a real precondition, and a dataset that does not meet one gets silence rather than a recommendation. On our public demo that accounts for exactly the rules you do not see: its catalog is pinned to a scenario without per-provider endpoints or tiered context pricing, its upload path carries no cacheability signal, every logged call succeeded, and its prompt sizes sit inside the tier they are billed at.
This is a design decision, not a limitation to apologise for. An absence is not a finding. A rule that fired anyway would be manufacturing a recommendation out of missing evidence, and every figure downstream — the fee basis included — would inherit it.
What a rule produces
Rules do not emit finished recommendations. Each one produces evidence: an observation from your telemetry, an inference drawn from it, and a proposed move with its own expected impact. Ranking, Pareto rejection against your declared objective, safety holds and the final recommendation happen afterwards, over evidence from every rule at once — which is why two objectives over identical telemetry produce different recommendations.
Every recommendation carries the confidence it was derived at, the sample size behind it, its payback period, and the reasoning that produced it. You can ask any of them why it ranked where it did, and why the alternative did not.