How to Set Per-Customer Spending Limits on AI APIs (2026)

So your SaaS is running on GPT-4o or Claude and you're starting to get nervous every time you see an email from AWS or OpenAI with the subject "Your invoice is ready". We've all been there.

The default way of thinking is to just eat the cost and hope your subscription revenue covers it. But what happens when one power user on your $20/mo plan starts costing you $100/mo in API calls? You're literally paying them to use your product. It's a surprisingly easy trap to fall into.

The answer isn't to switch to local models or build some crazy complex proxy (not yet, anyway). The first, most important step is just to get a handle on the numbers. You can't optimize what you can't measure. Setting a budget sounds corporate and boring, but for an AI-powered app, it's a survival mechanism.

Here's a no-bs guide on how to actually set and enforce budgets for your AI API usage, based on my own experience getting burned by this.

Step 1: Stop Guessing - Get Per-User Cost Attribution

Before you can set a budget, you need to know where the money is going. A single line item on your OpenAI bill for "API Usage: $1,500" is useless. You need to break that down. Who are your most expensive users? Which features are burning the most tokens?

Forget fancy dashboards for a second. The simplest way to start is by adding metadata to your API calls. Most providers support this. When a user makes a request, tag the API call with their user_id.

// Example with OpenAI's client
const completion = await openai.chat.completions.create({
  messages: [{ role: "user", content: "Say this is a test" }],
  model: "gpt-4o",
  user: "user-id-12345" // <-- THIS IS THE MAGIC
});

Now, you can at least start to aggregate costs on your end. It's not perfect, but it's a hell of a lot better than flying blind. You can write a simple script to pull your usage data and group it by that user field.

If you want to get serious, you need a proper monitoring tool. I ended up building one myself for my projects (llmeter.org) because the existing options were either too expensive or too focused on observability rather than cost control. Something like LLMeter ingests your usage and gives you a clean breakdown of cost-per-user, per-model, per-feature, automatically.

The goal here is to be able to answer the question: "How much does User XYZ cost me per month?" Once you have that, you can move on.

Step 2: Define Your "Cost of Goods Sold" (COGS)

For a SaaS, your LLM API calls are a direct cost of goods sold (COGS). Just like a t-shirt company has costs for cotton and printing, you have costs for tokens. Your pricing needs to reflect this.

Look at your pricing tiers. For each tier, you need to define a "budget" or an acceptable cost ceiling.

Let's say you have a "Pro" plan for $49/month. You can't let a user on that plan cost you $50 in API calls. You need a margin. A good starting point is to allocate 10-20% of the subscription price to COGS.

Pro Plan ($49/mo): Your acceptable API cost per user should be around $5 - $10/mo.
Free Plan ($0/mo): This is where it gets tricky. The budget here should be low. Maybe $0.50 to $1.00 per user, total. Free users are for acquisition, not for burning your runway.

These numbers aren't random. They should be based on your actual data from Step 1. Find your median and 90th percentile user cost. Your budget should be somewhere above the median but should put a hard stop on those outlier users who are costing you a fortune.

Step 3: Implement Usage Tiers and Soft/Hard Limits

Once you have a budget per plan, you need to enforce it. You have a few options, from gentle nudges to hard walls.

1. Soft Limits & Nudging:

This is the most user-friendly approach. When a user is approaching their implicit budget for the month (e.g., they've used 80% of their $10 cost allocation), you can:

Show a banner: "You're a power user! You've used 80% of your monthly AI credits."
Slightly degrade the experience: Maybe they get switched from GPT-4o to a cheaper, faster model for less critical tasks.
Email them: "Hey, just a heads-up, you're one of our top users this month. If you keep this up, we might need to look at a custom plan."

2. Hard Limits (Pay-as-you-go):

This is the classic approach. Each plan comes with a certain number of "credits" (which is just a user-friendly abstraction for tokens/cost).

Pro Plan: Includes 1,000,000 credits.
Free Plan: Includes 50,000 credits.

Once they run out, they have to buy more or wait for the next month's refresh. This is the safest model for your business, as it prevents runaway costs entirely. The downside is that it can feel restrictive to users.

3. The Hybrid "Fair Use" Policy:

This is what a lot of "unlimited" plans actually are. You don't set a hard number, but your terms of service state that you reserve the right to limit users who are excessively straining the system. This gives you the flexibility to deal with those 1% of users who are causing 90% of the costs, without punishing the other 99%.

If you go this route, you must have the monitoring from Step 1 in place. You need to be able to identify those expensive users and have a clear, data-backed reason for reaching out to them.

Putting It All Together

Don't over-engineer this from day one. Start simple.

Add user_id to your API calls. Do it today.
Spend a week gathering data. Figure out what your average and your most expensive users are actually costing you.
Define a simple budget for each of your pricing plans. A 15% COGS target is a good place to start.
Implement a simple soft limit. When a user crosses their budget, start by just sending yourself an email alert. That's it. You can then decide to reach out to them manually.

Managing LLM costs isn't a one-time fix. It's an ongoing process of monitoring, adjusting, and making sure your pricing and your costs are aligned. But by setting clear budgets, you move from nervously hoping your bill isn't too high to actually being in control of your margins.