How to Monitor Claude API Spend in Real Time

Monitoring Claude API spend means tracking token usage and cost in near real time, broken down by key, team member, or feature, so you catch cost spikes before the monthly invoice does. The short answer: you need per-request usage logging, a way to aggregate it by dimension (user, project, endpoint), and alerts that fire on thresholds — not just a dashboard you check once a month.

Most teams get burned not because Claude is expensive per call, but because nobody is watching aggregate usage until a bill arrives. A single runaway loop, a misconfigured retry, or one power user with a long context window can quietly multiply your spend. This guide covers what to track, how to track it, and where to set alerts.

What "spend" actually means for Claude usage

Claude API billing is based on tokens, not requests. A single call can vary in cost by 50x depending on context length and output size. Before you can monitor spend meaningfully, you need visibility into:

• Input tokens — the size of your prompt plus any system instructions and context
• Output tokens — generated response length, which costs more per token than input on most tiers
• Cache reads/writes — if you use prompt caching, these have their own pricing
• Request volume — raw call counts, useful for rate-limit planning, not cost alone

Tracking request count alone tells you almost nothing about spend. Two apps making the same number of calls can have wildly different bills if one sends 500-token prompts and the other sends 50,000-token documents.

Step 1: Log usage metadata on every request

Every Claude API response includes usage data in its payload — input/output token counts per call. If you're calling the API directly, you need to capture this yourself:

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-opus-4",
    max_tokens: 1024,
    messages: [{ role: "user", content: "Summarize this report." }],
  }),
});

const data = await res.json();
console.log(data.usage); // { input_tokens, output_tokens }

That usage object is the raw material for cost monitoring. Every call needs to log it somewhere — a database table, a log pipeline, a metrics service — tagged with who made the call and why.

Step 2: Tag requests by dimension

Raw token counts are useless without context. At minimum, tag each logged request with:

• User or team member ID
• Feature or endpoint (e.g. "support-bot", "pdf-summarizer")
• Environment (prod vs staging — staging usage shouldn't hit your prod cost dashboard)
• Timestamp

If you're building this from scratch, this tagging layer is the part most teams underinvest in. It's easy to log usage; it's harder to attribute it correctly when ten different parts of your product call the same API key.

This is the exact gap tools like SubToAPI are built to close. SubToAPI issues separate sub_live_... application API keys per project or team member, so usage and cost metadata are already segmented at the source — you don't need to build your own tagging layer just to know which feature is burning through tokens. See /docs/messages for the request format and usage fields returned with each call.

Step 3: Aggregate daily, not just monthly

Monthly totals catch problems after the damage is done. Aggregate spend data daily (or hourly if you have volume) so you can spot trend changes:

SELECT
  date_trunc('day', created_at) AS day,
  feature_tag,
  SUM(input_tokens) AS total_input,
  SUM(output_tokens) AS total_output
FROM api_usage_log
WHERE created_at > now() - interval '30 days'
GROUP BY 1, 2
ORDER BY 1 DESC;

Plot this and a spike is visible immediately — a sudden 4x jump in output tokens for one feature is far more actionable the day it happens than discovering it three weeks later in a reconciliation spreadsheet.

Step 4: Set threshold alerts

Dashboards require someone to look at them. Alerts don't. Define spend thresholds per key or per team member and page or email when they're crossed — daily, weekly, and monthly windows all matter since a slow leak and a sudden spike look different.

A basic alerting rule:

if (dailySpendByKey[keyId] > DAILY_THRESHOLD_EUR) {
  await notifyTeam(`Key ${keyId} exceeded daily threshold: €${dailySpendByKey[keyId]}`);
}

If you're running this on top of a platform that exposes usage per key natively, you skip building the aggregation pipeline entirely and just consume the numbers it already tracks per key or seat.

Step 5: Separate monitoring from rate limiting

Monitoring spend and limiting spend are different problems. Monitoring tells you what happened; rate limiting or quotas prevent it from happening again. Once you have visibility, the natural next step is capping usage per key so a single misbehaving integration can't blow through your budget before anyone notices the alert. That's a separate system from monitoring, but it depends on the same usage data you're already collecting.

Where a managed layer helps

If you're already managing Claude access for a team, standing up log aggregation, tagging, dashboards, and alerting from scratch is a real engineering project — one that has nothing to do with your actual product. SubToAPI wraps Claude access in application API keys with usage metadata, streaming, and tool use already exposed per key, so cost visibility is a byproduct of normal usage rather than a separate pipeline you maintain. Plans start at Solo €9, with Team (€19/seat) and Scale (€49/seat) tiers adding per-seat usage breakdowns for teams who need to see spend by person, not just by project. Check /pricing for details, or start with a free trial at /signup.

Questions

Does Claude's API tell me cost directly, or just token counts? The API returns token counts (input/output) per request, not a dollar figure. You calculate cost by applying your plan's per-token rate to those counts, which is why logging raw usage data is the foundation of any monitoring setup.

How often should I check Claude API spend? Daily aggregation with automated alerts is the minimum for production use. Monthly-only checks mean you discover cost spikes weeks after they happened, often after the damage compounds across a billing cycle.

Can I monitor spend per team member instead of just per account? Only if each person or feature uses a distinct, trackable key. Shared keys make per-user attribution impossible after the fact — issuing separate keys per team member, as SubToAPI does on Team and Scale plans, is the simplest fix.