What to do about it

Which lever matters most depends on your work: an estate of long documents gains most from retrieval, a busy estate on the top model from routing, a scheduled one from the ephemeral profile. So the first step is to read your own order of effect, not ours.

Find your own order of effect

1. Open Insights → Savings, or call GET /api/v1/savings/headline.
2. Sort the levers by their estimated dollars. A lever with no figure says why: that reason is usually the first thing to fix.
3. Read each lever’s coverage. A large saving on low coverage means more of your estate could report it; a small saving on full coverage is the real size.
4. Open Token optimisation → Models, cache and tokens for specific recommendations: moves to a cheaper model backed by evaluation parity, and waste flags per agent (a low cache share, oversized context, the model cost of failed runs and of retried ones), each with its threshold. Nothing there changes anything until you raise it as a change request. GET /api/v1/recommendations.

The levers, and where each is set

Retrieval: send passages, not documents

• What it changes: how much context each call carries.
• Where: connect sources under Setup and admin → Connectors, and watch each index under Agents → Knowledge. Measure the result under Insights → Retrieval.
• What to look for: reduction_pct on GET /api/v1/retrieval (the share of the stuffed baseline retrieval avoided), and searches that report no scope, which count for nothing until they do.

Model routing: the cheapest model that meets the bar

• What it changes: which model serves each call.
• Where: Agents → Routing. Switch the router on, set a quality bar per task class, pin or exclude a model. A client_admin makes each change as a person, with a reason, and it reaches your account as a signed command your policy can accept or refuse. Residency and your allow list stay in your deployment’s own policy. See Control.
• First: see what it would choose before it changes anything. The router’s own evaluation routes the 212 questions of the engine’s three golden sets against a deployment’s policy, reports the choices and the estimated saving, and calls no model. Your certified forward-deployed engineer can run it against your policy. Running it yourself from the installed engine: Coming. See A decision, worked.
• Then: run the Token Value Benchmark on your own tasks, so the router chooses on your evidence.

Prompt caching: read the stable prefix from the cache

• What it changes: what repeated input costs.
• Where: on Amazon Bedrock, the gateway marks the stable prefix of each call (the system prompt, or the prompt where there is none) for caching automatically. A prefix under about a thousand tokens goes uncached. Measure it under Spend → Caching.
• What to look for: the read ratio (the share of input read from the cache) and write amortisation (how many times reads paid back the writes). A write amortisation near or below one means the cache costs more than it saves for that agent: its prefixes are changing between calls.

Ephemeral infrastructure: nothing runs while nothing is asked

• What it changes: your cloud bill for the stack.
• Where: Settings → Deployments shows each deployment’s profile, its estimated always-on cost and the estimated saving. Request a change of profile there; your own pipeline applies it, because LightHouse never changes infrastructure in your account. See Deployment profiles.
• The trade: an ephemeral deployment wakes when asked. Its wake times (p50 and p95) are on the same page, so you can see what the saving costs in latency.

Your infrastructure against a hosted platform

• What it changes: nothing by itself. It tells you whether running the engine in your own account costs less than a hosted agent runtime would for the same work.
• Where: Insights → Savings, settings. Enter the rates of the hosted platform you would otherwise use, and the comparison becomes a full one and counts in the headline.

Caps, so a saving is not undone

A saving can be wiped out by one runaway agent. Set spend limits on the tenant, a pack, an agent or a person, daily or monthly, under Spend → Limits. They are enforced by the gateway in your account before each call. See Limits and alerts.