How to Monitor Claude API Usage Per User

If you're building a product on top of Claude, you need to know who is using how many tokens, not just a single aggregate number from the Anthropic console. The console shows total account usage, but it doesn't break usage down by customer, team, or feature — which is exactly what you need for billing, abuse prevention, or capacity planning.

There are two practical ways to solve this: build your own usage-tracking layer around the raw Anthropic API, or use a proxy/gateway that issues per-user keys and reports usage metadata automatically. This article covers both, with working code, so you can pick the approach that fits your stack.

Why the Anthropic console isn't enough

The native Anthropic dashboard gives you organization-wide token counts and spend. That's useful for your own invoice, but it tells you nothing about:

• Which customer account is driving a cost spike
• Whether a specific user is hitting rate limits
• How much a free-tier user consumed before you need to throttle them
• Per-feature cost (e.g., summarization vs. chat vs. code review)

If your product has more than one user sharing a single API key, you have a blind spot. Solving it requires attaching an identity to every request and persisting the resulting token counts somewhere queryable.

Option 1: Build your own tracking layer

If you're calling the Anthropic API directly, every response includes a usage object with input_tokens and output_tokens. The work is wiring that into a per-user ledger.

async function callClaude(userId, messages) {
  const res = await fetch("https://api.anthropic.com/v1/messages", {
    method: "POST",
    headers: {
      "x-api-key": process.env.ANTHROPIC_API_KEY,
      "anthropic-version": "2023-06-01",
      "content-type": "application/json",
    },
    body: JSON.stringify({
      model: "claude-sonnet-4-5",
      max_tokens: 1024,
      messages,
    }),
  });

  const data = await res.json();

  await db.usageEvents.insert({
    userId,
    model: data.model,
    inputTokens: data.usage.input_tokens,
    outputTokens: data.usage.output_tokens,
    createdAt: new Date(),
  });

  return data;
}

From there you aggregate usageEvents by userId and time window to produce per-user dashboards, cost alerts, or billing exports. This works, but you own:

• The logging pipeline and its failure modes (what happens if the DB write fails after a successful API call?)
• Rate limiting per user on top of Anthropic's account-level limits
• Cost calculation as pricing or models change
• Securing the raw Anthropic key so individual users never see it

It's a reasonable approach for a single internal tool. It gets harder once you have external customers, each needing their own credentials, usage caps, and visibility into their own consumption.

Option 2: Per-user API keys with built-in usage metadata

A cleaner separation is to give each user, team, or application its own key, and let the layer issuing those keys track usage for you. This is the model SubToAPI uses: you connect your Claude access once, then issue scoped sub_live_... keys per user or per project from a dashboard, instead of sharing one raw key across your whole product.

Each request against a SubToAPI key returns usage metadata in the response, and the dashboard aggregates it per key:

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

Because the key itself identifies the user or app, you don't need to build your own attribution logic — you just look at which key made the call. This matters for a few concrete scenarios:

• Multi-tenant SaaS: issue one key per customer account, see their token spend without a custom logging table.
• Internal teams: give each engineering team its own key so you can see which feature is actually expensive.
• Free trial abuse prevention: cap usage per key instead of per IP or per account, which is easier to game.

See the quickstart for how key issuance works, and the messages docs for the full request/response shape including usage fields.

Designing your per-user usage schema

Whichever approach you take, the underlying data model is the same. At minimum, track:

user_id
api_key_id (if using scoped keys)
model
input_tokens
output_tokens
request_id
timestamp
feature_tag (optional, e.g. "chat", "summarize")

The feature_tag is worth adding even if it feels like overkill early on. Once you have more than one Claude-powered feature, "per user" usage questions almost always become "per user per feature" questions — a support bot might be cheap, a document analyzer might not be.

Setting alerts and caps

Monitoring is only half the job — most teams eventually want to act on the numbers:

1. Soft alerts: notify internally when a user crosses a token threshold in a day or month.
2. Hard caps: block further requests once a user hits their plan limit, returning a clear error rather than a silent failure.
3. Rate limiting: separate from volume caps, limit requests per minute per user to avoid one account causing latency for everyone else.

If you're tracking usage manually, this means writing a check before every Claude call. If you're on a gateway with per-key issuance, caps and limits are typically configured at the key level in the dashboard instead of in your application code.

Streaming and tool use complicate manual tracking

If your product uses streaming responses or tool calls, token accounting gets trickier — usage is often only finalized at the end of the stream, and tool-use turns can involve multiple round trips with their own token counts. If you're rolling your own tracking, make sure you're summing usage across the entire conversation turn, not just the first chunk. This is one of the areas where a managed layer saves real engineering time, since streaming usage is reported consistently regardless of how the response was delivered.

Choosing an approach

• Build your own tracking if you have a single internal tool, one or two users, and no billing requirement.
• Use per-user scoped keys if you have external customers, need to cap or bill by consumption, or want usage visibility without maintaining a logging pipeline.

You can try the scoped-key approach with a free trial at signup, and compare plans — Solo, Team, and Scale — on the pricing page.

questions

Does the Anthropic API report usage per user automatically? No. The API reports token usage per request, not per user. Attribution to a specific user is something you have to add yourself, either by logging userId alongside each response's usage object or by using per-user API keys that a gateway tracks for you.

What's the fastest way to see usage broken down by customer? Issue a separate API key per customer or team instead of sharing one key. With SubToAPI, each sub_live_... key's usage shows up separately in the dashboard, so you get per-user breakdown without building a custom logging table.

Can I set a hard usage cap for a single user? Yes, but the implementation differs by approach. If you built your own tracking, you check cumulative tokens against a limit before each call. If you're using scoped keys through a gateway, caps are typically set per key in the dashboard instead.