Per User Spending Caps for LLMs, and Why You Actually Need Them

Why an account level cap is the wrong tool

OpenAI and the other providers let you set a monthly usage limit on your whole organization. When you hit it, calls start failing. That is a circuit breaker for your entire product, not a scalpel.

Think about what actually happens when you trip it. Every user, including all your happy paying ones, gets a broken feature at the same moment, because one account somewhere ran hot. You took the whole product down to contain a single outlier.

The provider cannot help you here, because it has no idea who your users are. It sees one API key and one total. The knowledge of which customer generated which cost lives in your app, so the cap has to live there too.

The flat subscription problem, in cap form

This all traces back to the same mismatch behind most AI margin pain. Your revenue per user is fixed by the plan price, while your cost per user moves with how much they use.

On a flat plan, a heavy user can quietly cost you more than they pay, and nothing flags it until you go looking. A per user cap is the ceiling that turns that unbounded downside into a number you chose on purpose. It is the same idea as setting spending caps per user, framed around the thing that makes it necessary. The deeper structural version is in why power users hurt your AI margins.

A basic per user cap by hand

The logic is simple. Keep a running total of cost per user id, reset it each month, and check it before every call.

// per user monthly cap, checked before each call
function capFor(plan) {
  return { free: 1, pro: 20, business: 100 }[plan] ?? 1 // dollars
}

async function guardedChat(userId, plan, params) {
  const spent = await getMonthlySpend(userId) // from your db or cache
  if (spent >= capFor(plan)) {
    throw new Error('monthly cap reached') // block (see the downgrade option below)
  }

  const res = await openai.chat.completions.create(params)
  const cost = costOf(res.usage, params.model)
  await addSpend(userId, cost) // persist so the next call sees it
  return res
}

That is the whole shape of it. The check is trivial. The parts that bite are keeping getMonthlySpend fast and correct across every serverless instance, and recomputing cost the same way your provider bills so your numbers do not drift.

When a user hits the cap: block or downgrade

You have two moves the moment someone crosses their limit, and the right one depends on the plan and the stakes.

• Block the call. Strict and clear. You throw, and the user is told they hit their limit. The cost stops dead, but that user now has a broken feature until the reset or an upgrade.
• Downgrade the model. Graceful. You swap from a frontier model to a cheaper one, from gpt-4o to gpt-4o-mini, and keep serving. Cost drops hard and most users never notice the difference.

Blocking protects cost the hardest but risks a bad experience, so it fits abuse cases and the very bottom of your pricing. Downgrading protects the experience while still cutting spend, which is why it is usually the better default. The full case for it is in model downgrade on a budget, and choosing which model to drop to is the subject of model routing for LLMs.

Why the manual version gets painful

For one server and a few users, the code above is genuinely fine. It stops being fine at exactly the moment your product starts working.

Spend has to persist somewhere every call can read and write in a few milliseconds, and stay correct when two requests from the same user land at once. You have to wire the check into every feature, reset totals cleanly each month, and decide block or downgrade per plan. None of it is hard on its own, but together it is a small system you now own and maintain forever.

No code caps with Weckr

The alternative is to keep the check but stop building the plumbing. That is what Weckr does. You set the cap per plan in the dashboard, no code, and the SDK enforces it before each call.

import { Weckr } from '@weckr/sdk'

const wk = new Weckr({
  apiKey: process.env.WECKR_API_KEY,
  plans: { free: 0, pro: 29 },
})

// Weckr checks the user's cap before the call and blocks or downgrades per your
// dashboard setting. You do not track spend yourself.
const response = await wk.chat(openai, {
  model: 'gpt-4o-mini',
  messages,
  userId: user.id,
  feature: 'chat',
  plan: user.plan,
})

You pick block or downgrade per plan in the dashboard, and Weckr keeps the running per user spend, recomputes cost server side, and enforces the limit for you. The setup lives in the docs, you can watch caps run on seeded data at the demo, and it fits into the wider system in the guide to AI cost and margin management.

FAQ

Put a ceiling on your worst case

A per user cap is the difference between a worst case you chose and one that arrives on an invoice. It is the single most protective thing you can add to an AI product.

Weckr gives you that cap with no tracking code, plus the choice to block or downgrade, and cost and margin per user so you can see who is near the line. Start at the demo.