Claude API Budget Alerts Per User: Setup Guide

If you're searching for "claude API budget alerts per user," you've probably already discovered the problem: Anthropic's API gives you one key and one aggregate spend number. There's no native concept of a "user" inside that key, and no dashboard toggle that says "alert me when user_123 hits €20 this month." If you're running a multi-tenant app, an internal tool with multiple team members, or a product where different customers consume Claude differently, you have to build per-user cost tracking and alerting yourself.

This article covers exactly how to do that: two practical approaches, the data you need to capture, and where the responsibility boundary sits between "track tokens yourself" and "let a layer on top of the API separate usage per key."

Why Claude's API doesn't give you this out of the box

A single Anthropic API key is a billing unit, not a user-management system. Every request you send — regardless of which of your end users triggered it — counts against the same quota and the same invoice. The usage object returned with each response tells you input_tokens and output_tokens for that single call, but nothing ties that call to a specific user unless you record it yourself.

This is fine if you're the only caller. It breaks down fast once you have:

• Multiple team members hitting the same key from different scripts
• A SaaS product where customer A uses 10x the tokens of customer B
• Interns, contractors, or agencies you want spend visibility on without giving them billing access

In all of these cases, "per-user budget alerts" really means: attribute token usage to an identity, accumulate it over a time window, and fire a notification when a threshold is crossed.

Approach 1: Track usage yourself in your own database

This is the most flexible option and works with any provider. Every Claude response includes a usage breakdown:

{
  "usage": {
    "input_tokens": 512,
    "output_tokens": 304
  }
}

You multiply these by your model's per-token pricing, tag the row with a user_id, and insert it into a usage table:

async function logUsage(userId, usage, model) {
  const cost = calculateCost(model, usage.input_tokens, usage.output_tokens);
  await db.insert("usage_log", {
    user_id: userId,
    input_tokens: usage.input_tokens,
    output_tokens: usage.output_tokens,
    cost_eur: cost,
    created_at: new Date(),
  });
}

Then a scheduled job sums cost per user over the current billing period and compares it against a configured threshold:

const spend = await db.query(
  `SELECT user_id, SUM(cost_eur) as total
   FROM usage_log
   WHERE created_at >= $1
   GROUP BY user_id`,
  [startOfMonth]
);

for (const row of spend) {
  const limit = await getUserLimit(row.user_id);
  if (row.total >= limit * 0.8) {
    sendAlert(row.user_id, row.total, limit); // email, Slack, webhook, whatever
  }
}

This gives you full control over thresholds, soft/hard caps, and notification channels. The downside: you're maintaining a billing system in parallel with your actual product code, and you need to make sure every single Claude call — including retries and streaming calls — gets logged correctly, or your numbers drift from the real invoice.

Approach 2: Separate keys per user, then poll usage per key

The alternative is to stop funneling every user through one shared key and instead issue a distinct application key per user or team member. This turns "per-user tracking" into "per-key tracking," which is a much simpler data model — you don't need to tag every row with a user_id, because the key itself is the identity.

This is the pattern SubToAPI is built around. Instead of one raw Anthropic key shared across your whole team or product, you generate application keys (sub_live_...) per user, per environment, or per customer from your dashboard, and each key carries its own usage metadata — tokens in, tokens out, request counts — that you can pull via the API.

A basic setup:

1. Create a sub_live_ key for each user via the dashboard or team seat assignment.
2. Have that user's part of your app call https://api.subtoapi.app/v1/messages with their own key instead of a shared one.
3. Pull usage metadata per key on a schedule and compare it against the budget you've set for that user.

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-4",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Summarize this report."}]
  }'

Each response carries a usage object the same way the underlying Claude API does, so your alerting job looks almost identical to Approach 1 — except you're aggregating by key instead of by a user_id column you invented yourself:

async function checkUserBudget(key, limitEur) {
  const usage = await fetchUsageForKey(key); // your own polling wrapper
  const cost = toEur(usage.total_tokens, usage.model_mix);
  if (cost >= limitEur * 0.8) {
    notifySlack(`Key ${key} at ${cost}€ of ${limitEur}€ budget`);
  }
}

Because keys map to team seats, this also solves a second problem that pure token-logging doesn't: access control. If someone leaves the team or a customer churns, you revoke their key instead of trying to retroactively filter their rows out of a shared log. See /docs/quickstart for key creation and /docs/messages for the request format; streaming and tool-use calls return the same usage structure, documented at /docs/streaming and /docs/tools.

Choosing thresholds that actually work

Whichever approach you use, the alert logic matters more than the plumbing:

• Set two thresholds, not one — a warning at 80% of budget and a hard stop at 100%, so people get a heads-up before anything breaks.
• Alert on rate, not just total — a user who burns 50% of their monthly budget in the first three days is a signal worth catching early, independent of the absolute number.
• Separate input and output token costs — output tokens are typically priced higher, and a user generating long completions will blow through budget faster than one with short exchanges, even at similar request counts.
• Reset windows explicitly — decide whether budgets are calendar-month, rolling 30-day, or billing-cycle aligned, and make sure your query matches that window exactly.

If you're evaluating whether to build this yourself or use a layer that separates keys per user from the start, compare the cost of engineering time against a plan that gives you team seats and per-key usage visibility out of the gate — Solo, Team, and Scale tiers all include separate application keys you can assign per person.

questions

Does the Claude API support per-user budgets natively? No. A single Anthropic API key tracks aggregate usage only. Per-user attribution requires either logging token usage against a user_id yourself or issuing separate keys per user so usage is naturally separated by key.

What's the simplest way to set a budget alert for one team member? Give them their own API key instead of sharing one, poll that key's usage metadata on a schedule, and trigger a notification when cumulative cost crosses your threshold for the period.

Can I alert on both tokens and euros/dollars? Yes — store raw input_tokens and output_tokens per request, convert to cost using your model's pricing, and alert on whichever unit is easier for your team to reason about (cost is usually more actionable than raw token counts).