Usage-based AI needs the same safety engineering as any “expensive actuator”: rate limits, quotas, and automatic shutdown thresholds. Otherwise a leaked key becomes an unbounded liability.

This reads like an “incident without guardrails”: per-project caps/quotas, anomaly alerts (minutes), env-split keys, and an automated kill-switch should be defaults for usage-based APIs. Billing emails are post-mortems.

“Cost per outcome” is the metric most teams actually need. In prod we saw totals look fine while cost/outcome drifted due to retries + fallback paths + context creep. Are you planning a before/after deploy comparison (prompt/version) to catch regressions, or anomaly alerts on cost/outcome slope?

Yes, we are building both

Nice — those two features tend to unlock the “why” behind drift. One thing we found especially useful was pairing cost/outcome alerts with a root-cause slice: when slope jumps, immediately show top contributing endpoint/feature + tenant/user + prompt version changes + retry ratio/context size trend. For your event_id model: how do you handle partial outcomes (e.g., success after fallback/escalation) and do you keep pricing snapshots by timestamp so historical cost/outcome comparisons stay consistent across model price changes?

This is exactly the pain point with agents: spend isn’t linear because fanout + retries compound. One thing that helped us debug/contain spikes is tracking cost per “user-action/outcome” (not just per call) plus a retry ratio trend (429/timeouts). Do you support budgets per step/tool in the chain, or only per overall run?

One thing that surprised our team: cost isn’t just “more usage” — retries and context creep can multiply spend with the same user behavior. We now track cost/request and cost per user-action per endpoint over time, plus a retry ratio. When either drifts after a change, it’s usually a quick fix (backoff, caps, trimming history).