Monitoring Anthropic Claude API Costs in Production

The Anthropic console tells you what you spent last month, account-wide. That's fine for accounting and useless for operating a product. To actually control Anthropic Claude API cost, you need real-time, attributed monitoring inside your own request path.

What to measure per call

Every Claude response returns a usage block. Capture it on the way out and you have everything you need:

const res = await anthropic.messages.create({ model, max_tokens, messages });

record({
  project: "prod-app",
  user: currentUser.id,
  model: res.model,
  inputTokens: res.usage.input_tokens,
  outputTokens: res.usage.output_tokens,
  // price with the model's current per-token rates
  costUsd: price(res.model, res.usage),
});

The dimensions that matter

• By feature — which part of the product spends the most.
• By user — the distribution is almost always long-tailed; find the whales.
• By model — Opus vs. Sonnet vs. Haiku changes the math by an order of magnitude.
• Input vs. output — output tokens cost several times more; a high output ratio is a tuning target.

Don't forget prompt caching and batch

Claude's prompt caching and batch API materially change cost, but only if your monitoring accounts for them. Cached input tokens are billed at a fraction of the normal rate — track cache hits so you can see the savings and spot when a prompt change silently busts the cache.

From monitoring to control

Monitoring tells you what happened; it doesn't stop anything. Pair it with two things: spike alerts so drift pages you in minutes, and hard caps so the worst case is bounded. Visibility plus enforcement is the whole game — the LLM cost control guide ties them together.