Enforce spend controls

Enforce spend controls

1. Cap the team's monthly spend

Operate ▸ Budgets ▸ Manage → pick the TEAM scope → add an all-models, MONTHLY cost limit (hard), plus an optional soft limit that warns earlier without denying.

Command
curl -s -u admin:PASSWORD -X POST https://aam.example.com/admin/budgets \
  -H "Content-Type: application/json" \
  -d '{
    "scopeLevel": "TEAM",
    "scopeId": "TEAM-UUID",
    "costLimit": 2000,
    "softCostLimit": 1500,
    "currency": "USD",
    "period": "monthly"
  }'

Route the soft-limit warning to a channel in Govern ▸ Notifications so the team hears about it before the hard cap bites.

2. Throttle the noisy project

Operate ▸ Rate limits → pick the PROJECT scope → set RPM (and/or TPM).

Command
curl -s -u admin:PASSWORD -X POST https://aam.example.com/admin/rate-limits \
  -H "Content-Type: application/json" \
  -d '{"scopeLevel": "PROJECT", "scopeId": "PROJECT-UUID", "rpmLimit": 60}'

Verify

  • The Budgets ▸ Manage meters show live spend against both thresholds.
  • The Rate limits ▸ Limits meters show RPM/TPM against the effective cap.
  • Exceeding the RPM cap returns 429 with a Retry-After header; an over-budget call returns 429 before any vendor is reached. Both denials are recorded in Audit & usage.

Why it works

Both controls are enforced across the whole scope chain at once, so the team cap and project limit apply on top of anything set at the org or key level — the tightest wins. A key inside the throttled project cannot escape the limit by belonging to a generous org.

Refinements

  • Stack a per-model budget on the same team ("$500 of that is the expensive model") — budgets are keyed by scope + model + provider + period, so several coexist.
  • Use Budgets ▸ Explore for burn rate, projected end-of-period, and time-to-exhaust across every budget in the org.
  • For spend caps that should fail over rather than deny, use per-deployment budgets: Cost-aware failover.