Claude API Usage Dashboard & Analytics Setup Guide

If you're searching for how to set up a Claude API usage dashboard, you're almost certainly trying to solve one of two problems: you have no visibility into who is spending what on your Anthropic bill, or you're building a product on top of Claude and need to show usage data to your own customers. Both problems have the same root cause — Claude's native console gives you an account-wide total, not a breakdown by application, team member, or feature.

This guide covers what a usable Claude API usage dashboard actually needs to track, how to build the logging pipeline yourself, and how to skip the engineering work entirely by using a layer that already does metering for you.

Why the default Claude console isn't enough

The Anthropic console shows aggregate token consumption and spend across your whole account. That's fine for a single personal project, but it breaks down fast once you have:

• Multiple apps or environments (staging vs. production) sharing one Claude account
• A team where several engineers or departments call the API under one bill
• Customers of your own product who need their own usage visibility
• A need to catch a runaway loop or misbehaving prompt before it burns through budget

Without per-key or per-user attribution, "who spent €400 last week" becomes a Slack archaeology exercise instead of a dashboard query.

The core metrics worth tracking

Before building anything, decide what the dashboard actually needs to answer. For most teams, that's:

• Requests per key/user/team — raw call volume, broken down by whoever is making the calls
• Input vs. output tokens — these are priced and billed differently, so lumping them together hides cost drivers
• Cost per request and cost per day — converted from tokens using current Claude pricing tiers
• Latency and error rate — not billing data, but essential for catching degraded performance or retried requests that double your spend
• Model used per call — if you route between Claude models, cost and quality vary significantly by model

If your dashboard only shows total tokens and total cost, you'll notice problems weeks after they start. Attribution by key or user is what turns the dashboard from a report into an alerting tool.

Option 1: Build the logging pipeline yourself

If you're calling the Anthropic API directly, you need to instrument every request yourself. A minimal version looks like this:

async function callClaude(prompt, { userId, feature }) {
  const start = Date.now();
  const response = 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: [{ role: "user", content: prompt }]
    })
  });

  const data = await response.json();
  const latencyMs = Date.now() - start;

  await logUsage({
    userId,
    feature,
    model: data.model,
    inputTokens: data.usage.input_tokens,
    outputTokens: data.usage.output_tokens,
    latencyMs,
    status: response.status
  });

  return data;
}

From there, logUsage writes a row to Postgres (or wherever), and your dashboard is a set of SQL aggregations: sum of tokens grouped by userId and day, cost computed by multiplying tokens by current per-model pricing, latency percentiles grouped by feature.

This works, but it's ongoing maintenance: every time Anthropic changes pricing tiers or adds a model, your cost calculation needs updating. You also need to build the auth layer that maps requests to userId in the first place — the raw Anthropic API has no concept of per-application keys, only one account-level key.

Option 2: Use a layer that already meters usage per key

This is the gap SubToAPI (https://subtoapi.app) is built for. Instead of calling Anthropic directly with one shared key, you issue scoped application keys (sub_live_...) through SubToAPI, one per app, environment, or customer. Every request made with that key is automatically logged with token counts, cost, latency, and model, and surfaced in a dashboard — no custom logging table required.

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 each key is scoped, you get per-key analytics for free: issue one key per teammate, per feature, or per customer, and the dashboard breaks down usage and cost accordingly without you writing a single aggregation query. Team and Scale plans add seat-based access so multiple people can view the same analytics without sharing credentials. See /pricing for plan details and /docs/quickstart to get a key issued in minutes.

Setting up alerts on top of your dashboard

A dashboard you only check manually will still let a cost spike run for days. Once metrics are flowing — whether self-built or through SubToAPI — add thresholds:

• Daily spend above a fixed euro amount
• Error rate above a percentage over a rolling window
• Any single key producing more than N requests per minute

Even a basic cron job that queries yesterday's totals and posts to Slack when a threshold is crossed is enough to catch most runaway-loop incidents before they become a billing surprise.

Streaming and tool use complicate metering

If your app uses streaming responses or tool calls, your usage logging needs to account for both. Streamed responses still return a final usage object once the stream closes, so log on stream completion, not per chunk. Tool-use turns typically involve multiple round trips (the model requests a tool, you return a result, the model continues), and each round trip consumes tokens — if you're only logging the final response, you'll undercount. See /docs/streaming and /docs/tools for how SubToAPI handles usage reporting across both patterns if you're using it as your API layer.

Getting started

If you're building the pipeline yourself, start with request-level logging (userId, tokens, cost, latency) before building any visualization — the dashboard is trivial once the data exists. If you'd rather skip the logging infrastructure entirely, sign up at /signup for a free trial, issue a scoped key per app or teammate, and the per-key analytics dashboard is already there the moment you make your first request.

FAQ

Does Anthropic's console show per-API-key usage breakdowns? The native console shows account-level totals, not granular per-key or per-user attribution, unless you build that mapping yourself in your own logging layer or use a metering service on top.

What's the difference between tracking tokens and tracking cost? Tokens are the raw unit Claude bills on, but input and output tokens are priced differently and rates change by model, so a dashboard showing only token counts without converting to cost at current rates will mislead you about actual spend.

Can I get usage analytics without building my own database? Yes — using an API layer like SubToAPI that issues scoped keys automatically logs tokens, cost, and latency per key, giving you a usage dashboard without writing custom logging or aggregation code. Check /docs/messages for request format details.