Claude API Usage Dashboard: Open Source Options

If you're searching for a "Claude API usage dashboard open source" solution, you're probably trying to answer one of two questions: how much am I spending on Claude, and who on my team is spending it. There isn't a single official open source dashboard maintained by Anthropic, but there are several practical paths — from rolling your own with the Anthropic SDK and a logging layer, to self-hosted observability tools, to a managed API layer that gives you usage metadata without the maintenance burden.

This article walks through what's actually available, what each option costs you in engineering time, and how to decide which approach fits your team.

Why there's no official open source dashboard

Anthropic's API is intentionally minimal: you send requests, you get responses, and usage data comes back in the response headers and body (token counts per request). There's no built-in web UI for usage analytics, no per-user breakdown, and no team seat management. That's by design — the API is a primitive, not a product.

This means every "Claude API usage dashboard" you find is either:

• Something you build yourself on top of raw API responses and logs
• A generic LLM observability tool (open source or commercial) that you wire up to Claude
• A managed layer that sits between your app and Anthropic and tracks usage for you

None of these are wrong. The right choice depends on how much engineering time you want to spend on observability versus on your actual product.

Option 1: Build it yourself from token usage data

Every Claude API response includes usage information:

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

A minimal DIY dashboard is just a database table and a cron job:

async function logUsage(userId, response) {
  await db.insert("api_usage", {
    user_id: userId,
    model: response.model,
    input_tokens: response.usage.input_tokens,
    output_tokens: response.usage.output_tokens,
    cost_estimate: calculateCost(response.usage, response.model),
    created_at: new Date(),
  });
}

Then you build a simple page querying that table, grouped by day, user, or model. This is genuinely open source in spirit — you own every line — but it's also work you have to maintain: handling streaming responses (where usage arrives in the final chunk), reconciling costs against Anthropic's pricing changes, and building the UI itself.

This approach makes sense if:

• You already have an internal admin panel and just need to add a table and a chart
• You want full control over cost attribution logic (e.g., splitting cost by feature, not just by user)
• You're comfortable maintaining this as Anthropic's pricing or response format evolves

Option 2: Self-hosted LLM observability tools

Several open source projects support LLM usage tracking generically — they're not Claude-specific, but most support Anthropic's SDK through wrapper functions or proxy modes. Typical setup involves:

1. Running the tool as a sidecar service or Docker container
2. Pointing your app's Claude calls through their SDK wrapper (or a proxy URL)
3. Viewing a self-hosted dashboard for tokens, latency, and errors

Trade-offs to know before going this route:

• Operational overhead: you're now running and patching another service, often with its own database
• Proxy latency: routing every request through an extra hop adds measurable latency, especially for streaming
• Partial coverage: many of these tools were built API-agnostic and don't surface Claude-specific details like tool-use blocks or extended thinking tokens cleanly

If your team already runs observability infrastructure (Grafana, Prometheus, a logging pipeline), bolting on token tracking to that existing stack is often less work than adopting a new dedicated tool.

Option 3: A managed layer with usage metadata built in

The alternative to building or self-hosting is using a service that already sits between your application and Claude and gives you usage data as a side effect of normal use — no proxy configuration, no extra database.

This is what SubToAPI does: it turns your existing Claude access into an HTTPS API with application-specific keys (sub_live_...), and every request — streaming or not — reports usage metadata back to your dashboard automatically. You get per-key usage breakdowns, team seats, and billing visibility without writing a logging layer or running a sidecar container.

A typical request looks like this:

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 changelog."}]
  }'

Because usage is tracked at the key level, you can issue a separate sub_live_... key per environment, per customer, or per internal team and see exactly who's consuming what — no custom analytics code required. See the quickstart for setup, the messages docs for request structure, and streaming if you need token-by-token delivery with usage still reported at the end.

For teams that need tool use alongside usage tracking, the tools docs cover how function calls are logged the same way as regular messages — so a dashboard built on this layer doesn't lose visibility just because a request involved tool calls.

How to choose

| Approach | Setup time | Maintenance | Per-user/team visibility | |---|---|---|---| | DIY logging table | Low-medium | Ongoing | Depends on your schema | | Self-hosted observability tool | Medium-high | Ongoing (infra) | Varies by tool | | Managed API layer (e.g. SubToAPI) | Low | None | Built in, per key |

If you're a solo developer who just wants to see your own token spend, a DIY table is fine. If you're running a team where multiple people or services call Claude and you need seat-level accountability without becoming the maintainer of another piece of infrastructure, a managed layer is the faster path. Pricing starts at €9/month for solo use, with team and scale tiers for seat-based accounts, and a free trial at signup if you want to compare the usage view against whatever you're currently stitching together.

Questions

Is there an official open source Claude usage dashboard from Anthropic? No. Anthropic's API returns token usage in each response, but there's no built-in dashboard — any UI you use is either custom-built, a third-party observability tool, or a managed service layered on top.

Can I track Claude usage per user without building a full dashboard? Yes, minimally — log usage.input_tokens and usage.output_tokens per request with a user ID, then query that table. For per-team or per-key breakdowns without custom code, a managed layer like SubToAPI tracks this automatically per API key.

Does usage tracking work with streaming responses? Yes, but it requires care: in streaming mode, token counts typically arrive in the final event of the stream, not upfront. Managed layers handle this reconciliation for you; DIY setups need to explicitly capture the final usage payload.