Claude API Cost Tracking Per Customer: A Practical Guide

If you're building a product on top of Claude and billing customers by usage, you need a reliable way to attribute every API call — and its cost — to the right customer. This matters whether you're running usage-based pricing, enforcing per-customer quotas, or just trying to understand your gross margin on each account. The short answer: track cost at the request level using token counts from the API response, tag each request with a customer identifier, and aggregate that data outside of Claude's own dashboard, since Anthropic's console reports usage at the account level, not per end-customer.

This article walks through the practical mechanics of doing that — what data you actually get back from the API, how to structure your tagging, and two common architectures (shared key vs. per-customer key) along with their tradeoffs.

Why this is harder than it sounds

The Claude API bills by tokens, not by request, and the Anthropic console shows aggregate usage for your whole organization. If you have ten customers hitting the same backend, the console gives you a single number — not a breakdown. To get per-customer cost, you need to:

1. Capture input and output token counts for every request.
2. Associate each request with a customer ID at the time it's made.
3. Store that association somewhere queryable (a database, a logging pipeline, or a billing table).
4. Multiply tokens by your model's per-token rate to get a dollar figure.

None of this is exotic, but it's easy to get wrong if you bolt it on after the fact instead of designing for it from day one.

Step 1: Capture token usage from every response

Every Claude API response includes a usage object with input_tokens and output_tokens. This is the ground truth for cost — don't estimate with a tokenizer library when the actual count is already in the response payload.

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

const data = await response.json();
const { input_tokens, output_tokens } = data.usage;

Store input_tokens and output_tokens alongside a customer_id, a timestamp, and the model used. That last part matters — Opus, Sonnet, and Haiku have different per-token rates, so cost calculations need to know which model served the request.

Step 2: Tag requests with a customer identifier

The tagging has to happen in your application layer, since Claude itself doesn't know who your end customer is. A simple pattern is a usage_events table:

CREATE TABLE usage_events (
  id BIGSERIAL PRIMARY KEY,
  customer_id TEXT NOT NULL,
  model TEXT NOT NULL,
  input_tokens INT NOT NULL,
  output_tokens INT NOT NULL,
  request_type TEXT,
  created_at TIMESTAMPTZ DEFAULT now()
);

Every time you call the API, insert a row right after you get the response back. This gives you a complete, queryable log you can aggregate by customer, by day, by model, or by feature (request_type is useful if your product has multiple AI-powered features with different cost profiles).

From there, cost per customer is a straightforward query:

SELECT
  customer_id,
  SUM(input_tokens) AS total_input,
  SUM(output_tokens) AS total_output,
  SUM(input_tokens) * 0.000015 + SUM(output_tokens) * 0.000075 AS estimated_cost_usd
FROM usage_events
WHERE created_at >= date_trunc('month', now())
GROUP BY customer_id
ORDER BY estimated_cost_usd DESC;

(Adjust the per-token rates to whatever model and pricing tier you're actually using — rates vary by model and change over time, so keep them in a config table rather than hardcoding them in every query.)

Shared key vs. per-customer key

There are two common architectures for multi-tenant Claude usage, and they have different cost-tracking implications.

Shared API key, application-level tagging. Your backend holds one Claude API key and routes all customer traffic through it, tagging each request as shown above. This is simple to set up and works fine if you control all the request paths. The risk is that any bug in your tagging logic silently corrupts your billing data — if a request fails to log, that cost is invisible.

Per-customer API keys. Each customer (or each application in your product) gets its own key, and you read usage per key directly. This is more robust because the attribution happens at the infrastructure layer instead of in application code, and it also gives you a natural place to enforce per-customer rate limits or revoke access without touching other customers.

This is the model SubToAPI is built around: instead of managing a single shared Claude key and building your own tagging and metadata layer, you issue a sub_live_... key per customer or per application from one dashboard. Each key's usage — tokens, request counts, cost — is tracked independently, so per-customer cost reporting is a lookup instead of a custom logging pipeline you have to build and maintain. If you're already deep into a homegrown tagging system, it's worth comparing the maintenance cost of that against just issuing scoped keys from the start. See the quickstart for how key issuance works, and pricing for plan details.

Common mistakes to avoid

• Estimating tokens instead of reading them from the response. Tokenizers can drift from the model's actual count, especially with system prompts and tool definitions. Always use the usage field.
• Forgetting cached or retried requests. If you retry on error, make sure you're not double-counting tokens for a request that technically succeeded twice (once with an error, once without) — or that you are counting them, if the retry still consumed tokens.
• Ignoring tool use overhead. If you're using Claude's tool-calling features, the tool definitions and tool results sent back and forth count as tokens too. Factor this in — see the tool use docs for how tool schemas affect the request payload.
• Not separating streaming from non-streaming cost tracking. Streamed responses still report final usage at the end of the stream, but make sure your logging code waits for the terminal event before recording — see the streaming guide for the event shape.

Putting it together

A minimal, production-ready setup looks like this: log token usage and customer ID on every request, store it in a table you can query by day and by customer, and multiply by current per-model rates to get a dollar figure. If you want attribution built into the infrastructure rather than your own logging code, per-customer API keys through a platform like SubToAPI remove most of this work — you get usage and cost per key out of the box, with messages and streaming support included. Either way, start tracking from day one; reconstructing historical per-customer cost after the fact is far harder than logging it as you go.

Questions

Does Anthropic's own console show per-customer costs? No. The Anthropic console reports usage at the account/organization level. If you serve multiple customers through one account, you need to tag and aggregate usage yourself, or use per-customer API keys so each customer's usage is tracked separately.

Should I calculate cost from tokens or from a fixed per-request price? Use tokens. Claude's pricing is per-token and varies by model, so a fixed per-request price will misrepresent cost for anything with variable-length prompts or outputs — which is nearly everything.

What's the simplest way to get per-customer cost without building a logging pipeline? Issue a separate API key per customer or per application. With SubToAPI, each sub_live_... key tracks its own usage and cost automatically, so you can read per-customer figures from the dashboard instead of maintaining your own usage_events table.