> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Spend caps on the dashboard > Where the carrier-side send envelope ends and your tenant-owned spend cap begins — and how the velocity-anomaly detector backs the thresholds you set. # Spend caps on the dashboard You own a prepaid wallet, and the first question is where the ceiling lives. Some of it is platform-side — the fraud envelope the checkpoint measures your traffic against — and some of it is yours alone to raise or tighten. This page maps the two halves, then shows how the velocity-anomaly detector backs the thresholds you set, without which every cap is still a guess. *** ## 1. Carrier-side envelope versus tenant-owned cap Every outbound send is measured against a platform fraud envelope — per-channel, per-minute and per-day ceilings measured on a spend estimate, not a message count. That envelope exists so a compromised API key cannot pump toll-fraud traffic through your wallet unchecked, and it is the same envelope the velocity-anomaly detector can only ever tighten, never loosen. Your tenant-owned spend cap sits on top of that envelope. You set it one level up in **Billing → Alerts** as a rule over `spend_percent` (of your monthly budget), `spend_amount`, `daily_spend`, or `balance_remaining` — and when the line trips you choose `notify`, `pause_outbound`, or `block_outbound`. The recipient list, the action, and the cooldown are all yours to edit; no Devotel support ticket touches the change. The full rule grammar is in [Spend caps, budget alerts, and auto-cutoff](/billing/spend-caps). This split is why two 429s look different: the fraud envelope refusal (`CHANNEL_DAILY_SPEND_CAP`) disappears the moment the estimate falls, while a tenant-owned pause returns `SENDING_PAUSED` (HTTP 402) until you clear the alert yourself in the dashboard. ## 2. Alert sources and the comparator chain Three independent evaluators watch spend, each answering a different question, and they chain rather than overlap: 1. **Your threshold rules** — fixed lines. Compared on the billing scheduler's ten-minute tick with `gt`/`gte` (`lt`/`lte` for balance floors). Absolute, but blind to shape. 2. **The velocity-anomaly detector** — a 14-day UTC baseline per channel, projected against today. A channel flags only when both the \$250/day floor and the 10x surge multiple hold. The tunables are platform defaults, not configuration — the model exists precisely to catch what a fixed line you picked last month cannot. The full model is on [Spend alerts, burn rate, and the velocity-anomaly model](/concepts/spend-anomaly-and-alert-model). 3. **Escalation** — a flagged channel may auto-throttle (10 per minute on `high`, pause on `critical`, expiring within six hours) and bridge onto an on-call incident plan when you wire `POST /api/v1/billing/spend-anomaly/escalation`. Pairing is deliberately asymmetric: a threshold rule chooses the absolute ceiling across all spend; the anomaly detector chooses tenant-relative velocity limits per channel. Velocity flags route to the fraud-review queue for operator eyes, while threshold breaches notify the recipients you named — you do not have to choose between the two, and only one of them can choke traffic without you noticing. ## 3. Usage-anomaly rules and the spend cap The usage-anomaly rules in [Usage & delivery anomaly alert rules](/guides/usage-anomaly-alert-rules) — SMS delivery rate, outbound message volume, and spend — are read-only over your ledger. They append to your fired-event feed and ring the dashboard's in-app Notification Center; they never pause traffic and never write to the wallet. That is the complement, not a duplicate, of the spend cap: an anomaly on `spend` or `outbound_message_volume` tells you where to look, and the spend cap enforces while you look. For a surge-shape metric the durable pairing is a hard ceiling on **Billing → Alerts** alongside the anomaly rule — one informs, the other enforces. Delivery-rate drops usually want the opposite: investigate the route, not clamp it. ## 4. Choosing the surface * **Billing → Alerts** — the tenant-owned spend cap, with `pause_outbound` and `block_outbound` actions. * **Settings → Agents** — a separate daily USD ceiling on agent LLM spend; it refuses new runs with a 429 until UTC midnight or you raise it. * **Sub-account caps (resellers)** — a hard monthly latch per child account that stays tripped until a new UTC month or a refund releases it. * **Usage anomaly rules** — notification-only tripwires to pair with any of the above. The envelope beneath all of them is the platform's job; the ceiling on top of it is yours. Raise it on the dashboard, not via a ticket. *** For the endpoint-by-endpoint reference see [Spend caps, budget alerts, and auto-cutoff](/billing/spend-caps) and the [Billing API reference](/api-reference/billing).