Spend caps

A hard monthly INR limit on each API key. When the cap is hit, that key returns 429 until the next cycle — no email-then-pray, no surprise invoice.

Why every key needs one

The pattern that costs orgs the most money isn't a hack. It's a developer leaving a runaway agent loop running over a weekend, or a cron job that misfires every minute for ten days. A per-key cap turns "₹ 80,000 surprise bill" into "₹ 2,000, ticket filed Monday morning."

Set a cap

1. App.ollima.com → Keys.
2. Click the existing key (or set it when minting).
3. Enter a monthly cap in INR. We bill in paise internally; the form converts.
4. Save. The cap is live immediately.

Programmatically:

PATCH /orgs/<slug>/api-keys/<public_id>
{"monthly_spend_cap_paise": 100000}  # ₹1000

Raise or remove

Same PATCH endpoint. Send null to remove the cap entirely (not recommended for production keys).

When a key exceeds

The shim short-circuits the request before forwarding to the provider — you don't pay the upstream call. Response:

HTTP/1.1 429 Too Many Requests

{
  "error": {
    "message": "Monthly spend cap exceeded for this key. Raise the cap or wait for the next billing cycle.",
    "type": "spend_cap_exceeded"
  }
}

The Logs page shows the rejection with a red badge so you can spot the affected key quickly.

Org-level guardrails

Coming next: an org-level cap that overrides any single key's limit, plus 80% / 90% warning emails. Track on GitHub issues.