How to Set a Hard Spend Cap Per User on LLM APIs

A single user can generate a wildly disproportionate share of your LLM cost — a long conversation, a pasted document, or a script hitting your endpoint in a loop. A hard spend cap per user is the control that contains the blast radius: each user gets a budget, and when they hit it, their calls stop until it resets.

Hard vs. advisory caps

An advisory cap logs a warning and keeps spending. A hard cap rejects the call. Only the second one actually protects the bill — if the limit doesn't change what happens at the moment it's crossed, it isn't a limit.

What a per-user cap needs to track

1. 01Identity — a stable user id on every call.
2. 02Accumulated cost — input + output tokens priced per model, summed over the budget window.
3. 03A window — per day, per month, or a rolling period that resets.
4. 04An enforcement point — a check *before* the call that can reject it.

const guard = new Guard(anthropic, {
  project: "prod-app",
  // $5 per user per month, hard-enforced.
  cap: { perUser: 5 },
});

try {
  const res = await guard.messages.create({
    model: "claude-sonnet-5",
    max_tokens: 1024,
    user: currentUser.id,
    messages,
  });
} catch (err) {
  if (err instanceof CapExceededError) {
    return respondWithUpgradePrompt(); // degrade gracefully
  }
  throw err;
}

Degrade gracefully when the cap is hit

A rejected call is a product decision, not just an error. Options, roughly in order of user-friendliness:

• Show a clear 'you've reached your limit' message with a reset time.
• Fall back to a cheaper model or a cached/templated response.
• Queue the request until the window resets.
• Prompt an upgrade if usage is a paid tier.

Setting the number

Start from unit economics: what is a user worth, and what fraction of that can go to inference? For free tiers, the cap is abuse protection — set it low enough that a runaway script hits it fast. For paid tiers, set it above genuine heavy use but below the point where a single user erases their own margin. Revisit it once you have real per-user spend data.