A travel platform's AI feature costs vary enormously between interactions and the total is growing faster than usage. Which levers apply, in what order?

In order of leverage

1. Attribution first. Cost per request, attributed to feature, tenant and model. Without it, optimisation targets the wrong thing — and the intuitive target, the most expensive request type, is frequently a small fraction of spend while the cheap majority dominates it. Rank by cost × volume, not by cost.

2. Reduce context size. Input tokens are frequently the dominant cost, and context is where waste accumulates: retrieved chunks that are not used, conversation history carried indefinitely, verbose system instructions, and tool results returned in full.

Concretely: retrieve fewer and better chunks (a reranker over a small candidate set beats a large candidate set), truncate or summarise history, and bound tool result sizes.

3. Cache. Repeated or near-repeated inputs are a large fraction of traffic in most products. Caching retrieval results, embeddings and — where inputs repeat exactly — generations. Centralising this at a gateway means every feature benefits.

4. Route by request class. Most interactions are simple — classification, extraction, routing, short summarisation — and are served well by a smaller, faster, cheaper model. Reserving the most capable option for the interactions that need it is usually the single largest saving, and it requires an evaluation harness to do safely.

5. Bound output length, since generation is typically the more expensive direction per token.

6. Eliminate unnecessary calls. Features that invoke a model where a deterministic rule, a lookup or a cached result would do. This is common in products that adopted AI enthusiastically.

The measurement discipline

Cost per successful user outcome, not cost per call. A cheaper model that requires three attempts is not cheaper, and an expensive call that resolves the task first time may be the better value. Optimising per-call cost while ignoring retry and escalation rates makes the product worse and the bill only slightly better.

The architectural prerequisite

Model and routing as configuration, not code, with an evaluation harness that can verify a cheaper configuration is acceptable. Without both, cost optimisation is either impossible or unsafe — and platforms that lack them tend to run their original expensive configuration indefinitely.