Question presented to candidate: "Our LLM bill swings wildly: one month it was 40% over plan because a customer's integration got stuck in a loop, and another month a prompt change quietly doubled our token usage. Finance wants a number they can rely on. How do you make LLM spend predictable without killing the product?"
What a strong answer should cover:
- Why the bill is volatile: cost per request has a long tail (output length, agent steps, retries), and spend is driven by a few tenants and a few prompts, so averages hide the risk
- Bound every unit: per-request limits (
max_tokens, input size caps, agent step and tool-call caps) give a worst-case cost per request you can multiply by traffic - Budgets in layers: per-tenant and per-feature quotas enforced in your own gateway, plus provider-side spend limits as the last backstop, with the trade-off that a hard cap is an outage for that scope
- Detection before the invoice: daily spend and cost-per-request anomaly alerts, a burn-rate forecast against the monthly budget, and attribution so the alert names the tenant, feature or prompt version
- A degradation ladder instead of a cliff: cheaper model, shorter answers, queue or batch non-urgent work, then hard limits, decided in advance with product
- Commercial levers for predictability: reserved or provisioned capacity (a fixed bill that is cheaper only above a break-even utilisation) and pricing your own plans so heavy users pay for heavy use
Clarifying questions expected:
- Is the goal a lower bill, a predictable bill, or both, and how much over-budget risk is acceptable?
- Is usage per tenant visible today, and do customer plans include usage limits?
- Which features can degrade (cheaper model, slower answer) and which must always run at full quality?
Code / implementation expected: Optional โ sketching a per-tenant budget check in the gateway and a burn-rate alert is enough.