Skip to content

PATTERN Cited by 1 source

Dual-limit daily-plus-monthly

Problem

A single spend limit cannot simultaneously catch runaway automation (requires a low threshold) and allow legitimate heavy use (requires a high threshold). At scale, this forces a choice between constant user interruption and inadequate runaway protection.

Solution

Implement two coupled budgets with different time windows and different unblock paths:

  1. Daily budget (runaway guard): Small relative to monthly spend. When hit, user receives a notification and self-serve acknowledges to raise by one increment. Resets nightly. Cannot be tripped by smooth monthly spend (ratio-coupled to monthly).

  2. Monthly budget (extraordinary-spend gate): High enough that typical users never hit it. Requires manager approval to raise. Moves through coarse tiers (2×, 5×, unlimited). Time-scoped to project duration, then reverts.

Effective limit formula: min(month_to_date + daily_increment, monthly_max)

Structure

                   ┌─────────────────┐
   Request ──────▶│  Gateway checks  │
                   │  both budgets    │
                   └────────┬────────┘
                            │
              ┌─────────────┼─────────────┐
              ▼                           ▼
   ┌──────────────────┐      ┌──────────────────┐
   │  Daily budget     │      │  Monthly budget   │
   │  (runaway guard)  │      │  (spend cap)      │
   │                   │      │                   │
   │  Unblock: self-   │      │  Unblock: manager │
   │  serve ack (1s)   │      │  approval (async) │
   │  Reset: nightly   │      │  Reset: monthly   │
   └──────────────────┘      └──────────────────┘

Key design choices

  • Tiered groups, not arbitrary values. Both budgets use fixed tiers (gateway group membership). This keeps the system legible — a group listing answers who is above default and by how much.
  • Asymmetric promotion. Daily tiers auto-promote on ack and auto-reset; monthly tiers require deliberate approval and auto-revert at project end.
  • Proactive notification at ~90%. Users become eligible for a raise before blocking, avoiding interruption during active work.
  • Human signal as discriminator. The self-serve acknowledgment button cannot be clicked by an unattended automation loop — the human-in-the-loop property is the runaway detector.

Consequences

  • Positive: Eliminates approval-queue friction (hundreds of tickets/month → near zero). Engineers stop rationing AI usage. Runaway protection is calibrated, not compromised.
  • Negative: Requires all traffic through a single control point (gateway) for enforcement. Tier management adds configuration complexity. Notification fatigue possible if daily increment is too small.

Known uses

Seen in

Last updated · 602 distilled / 1,824 read