Hi ZenMux team,
Currently, PAYG API keys support a spending cap, but it's a single lifetime/total limit. For production use, this isn't granular enough to control burn rate or contain runaway usage from bugs, loops, or compromised keys.
Request
Add a cap period selector alongside the spending cap amount, with options:
- Daily — resets every 24h (UTC or user tz)
- Weekly — resets every 7 days
- Monthly — resets on calendar month or rolling 30d
Why it matters
- Blast radius control — a leaked or misbehaving key can't drain more than one period's budget before auto-cutoff.
- Budget predictability — teams can align API spend with monthly finance cycles without manual top-ups.
- Per-key experimentation — devs can issue short-lived daily-capped keys for tests/agents without risking the master budget.
Ideal UX
- Dropdown:
Cap period: [None | Daily | Weekly | Monthly]
- Numeric field:
Cap amount: $___
- Display:
Spent this period: $X.XX / $Y.YY · resets in Nd Nh
Nice-to-haves
- Webhook/email alert at 80% of period cap
- Per-key override of account-level defaults
Thanks — this would make PAYG keys much safer to hand to autonomous agents.
Hi ZenMux team,
Currently, PAYG API keys support a spending cap, but it's a single lifetime/total limit. For production use, this isn't granular enough to control burn rate or contain runaway usage from bugs, loops, or compromised keys.
Request
Add a cap period selector alongside the spending cap amount, with options:
Why it matters
Ideal UX
Cap period: [None | Daily | Weekly | Monthly]Cap amount: $___Spent this period: $X.XX / $Y.YY · resets in Nd NhNice-to-haves
Thanks — this would make PAYG keys much safer to hand to autonomous agents.