How to Monitor Claude API Token Usage in Production

Why Token Monitoring Matters

If you're calling the Claude API in production, you need to know how many tokens each request consumes — not just for billing accuracy, but to catch runaway prompts, detect abuse, and budget spend per feature or per customer. The good news is that Claude's API returns token counts on every response, so monitoring isn't about guessing — it's about capturing data that's already there and doing something useful with it.

The short answer: every Claude API response includes a usage object with input_tokens and output_tokens. Log that object on every call, tag it with metadata (user ID, endpoint, feature), and aggregate it somewhere you can query — a database table, a logging pipeline, or a dashboard. The rest of this article covers how to do that in practice, at different levels of effort.

Reading Usage Data from the API Response

Every non-streaming Claude API call returns usage inline:

{
  "id": "msg_01...",
  "type": "message",
  "role": "assistant",
  "content": [{ "type": "text", "text": "..." }],
  "usage": {
    "input_tokens": 412,
    "output_tokens": 187
  }
}

For a Node.js client, capturing this is as simple as reading the field after the call:

const response = await client.messages.create({
  model: "claude-sonnet-4-5",
  max_tokens: 1024,
  messages: [{ role: "user", content: "Summarize this document..." }],
});

console.log(response.usage.input_tokens, response.usage.output_tokens);

If you're building anything beyond a prototype, log this on every request — not just when something breaks. You want a historical record, not a debugging tool you remember to use after the fact.

Handling Streaming Responses

Streaming makes usage tracking slightly less obvious, because tokens arrive incrementally and the final usage numbers show up in the terminal event of the stream, not upfront. With Claude's streaming format, the message_start event includes input token count, and the message_delta event near the end includes cumulative output tokens:

for await (const event of stream) {
  if (event.type === "message_start") {
    inputTokens = event.message.usage.input_tokens;
  }
  if (event.type === "message_delta") {
    outputTokens = event.usage.output_tokens;
  }
}

You need to accumulate these across the stream and log them once the stream closes, not on every chunk. Skipping this step is the most common reason teams have accurate non-streaming logs but blank spots for streamed conversations.

What to Log Per Request

Raw token counts are only useful if you can slice them later. At minimum, capture:

• Timestamp — for time-series graphs and spend-over-time views
• Input and output tokens — separately, since output is usually priced higher
• Model — usage patterns differ across model tiers
• User or account ID — to attribute cost per customer or per team member
• Endpoint or feature name — to see which parts of your product are expensive
• Request ID — for tracing back to a specific call when debugging a spike

A simple log line or database row per request is enough to start. You don't need a dedicated observability platform on day one — a Postgres table with these columns and a scheduled aggregation query will get you 90% of the value.

Aggregating Usage Into Something Actionable

Once you're logging per-request data, the next step is turning it into numbers people actually look at:

• Daily/weekly token totals by model, to project spend before the invoice arrives
• Per-user or per-team breakdowns, especially if you're billing customers based on usage
• Alerts on unusual spikes — a single user generating 10x their normal token volume in an hour is worth investigating, whether it's a bug in a retry loop or misuse
• Cost estimates, since token counts alone don't tell you much until you multiply by the current per-token pricing for input and output separately

If you're maintaining multiple raw API keys across environments or team members, this aggregation work multiplies — you end up reconciling usage from several dashboards instead of one. This is one of the practical reasons teams move to a layer that centralizes key issuance and usage reporting: instead of piecing together logs from five different API keys, you get one place to see usage across your whole team.

A Lower-Effort Path: Centralized Usage Metadata

If you'd rather not build and maintain your own logging and aggregation pipeline, SubToAPI sits between your app and Claude and gives you usage metadata per application key out of the box. You issue scoped sub_live_... keys per app, feature, or team member from one dashboard, and usage is tracked centrally instead of being scattered across whichever raw keys people created individually. That's particularly useful once you have more than one or two developers hitting the API — usage monitoring stops being a personal habit and becomes something the whole team can see. The quickstart walks through issuing your first key, and the messages docs cover the request format if you're migrating from direct Claude API calls.

Practical Tips for Keeping Costs Visible

• Log usage before you need it. Retrofitting monitoring after a surprise bill is much harder than logging from day one.
• Separate input and output token tracking. Output tokens are typically more expensive, and prompts that generate long completions are often the real cost driver, not long inputs.
• Watch for tool-use loops. If you're using tool calling, a request that triggers multiple tool round-trips can multiply token usage per user action — make sure your logging captures the full chain, not just the first call.
• Set soft budgets, not just hard limits. A daily digest showing "you're on track to spend X this month" catches problems earlier than a hard cutoff that blocks users mid-request.

questions

Does the Claude API tell you token usage automatically? Yes. Every response includes a usage object with input_tokens and output_tokens. For streaming responses, input tokens appear in the message_start event and output tokens accumulate through message_delta events, finalized when the stream ends.

What's the difference between monitoring tokens and monitoring cost? Token counts are raw usage; cost requires multiplying input and output tokens separately by their respective per-token pricing, since output tokens are usually priced higher than input tokens. Track both — tokens for capacity planning, cost for budgeting.

How do I monitor usage across multiple team members or API keys? Either build a shared logging table that all your services write to, tagged with a key or user identifier, or use a platform like SubToAPI that issues scoped keys per user and reports usage centrally, so you're not reconciling logs from separate raw API keys.