Claude API Cost Tracking: A Practical Setup

Claude API cost tracking has the same goal as tracking any LLM provider — attribute every rupee of spend to the feature, model, and user that caused it — but Anthropic’s API has a few mechanics worth understanding so your instrumentation captures the right things. This post walks through a practical setup: what to measure, how Claude’s pricing structure and caching change the maths, and how to route across the current model family without losing visibility.

If you run more than one provider, this pairs directly with the multi-provider cost dashboard — Claude is one slice of a picture that only makes sense when it is consolidated with the rest.

The current Claude model family

Anthropic’s latest models are the Claude 4.x family, which spans several tiers built for different trade-offs between capability, speed, and cost — broadly an Opus tier for the hardest reasoning, a Sonnet tier for the balanced default, and a Haiku tier for high-volume, latency-sensitive, cost-sensitive work. The tiers differ substantially in per-token price, which is precisely why tracking which model served each call matters as much as tracking how many tokens it used.

Because model names and prices change, do not hard-code either into your cost logic as constants you forget about. Read the model from the API response, and keep a rate table you can update. When you need current numbers, check Anthropic’s pricing page rather than trusting a figure from a blog post — including this one.

Input tokens, output tokens, and why the split matters

Claude, like other providers, bills input tokens and output tokens at different rates, and output typically costs several times more than input. This has direct instrumentation consequences:

• Record both counts separately on every call. The API returns input and output token usage; capture both, not a single total. A feature that sends short prompts and receives long responses has a very different cost profile from one that does the reverse, and only the split reveals it.
• Watch output-length drift. A prompt change that makes Claude more verbose inflates cost on every call, invisibly, unless you are tracking average output tokens over time — a classic case for anomaly detection.
• Cap output deliberately. Set max_tokens to what the feature actually needs. An instruction to “explain” will happily produce four paragraphs where one line was required, and you pay for all four.

Prompt caching changes the arithmetic

Anthropic supports prompt caching, where a stable prefix — a long system prompt, a fixed instruction block, a reused document — is cached and billed at a steep discount on repeat calls. For any workload that re-sends the same large prefix on every request (which describes most agent and RAG systems), this materially changes the cost per call.

Two implications for tracking:

1. Cached and uncached tokens are priced differently. Your cost computation has to account for the discount on the cached portion, or your per-call cost will read high and your reconciliation against the Anthropic invoice will never tie out.
2. Cache hit rate is a cost metric. If your prefix structure changes and the cache stops hitting, cost climbs with no change in visible behaviour. Treat cache hit rate as a first-class signal, not an implementation detail.

Routing across the family without losing visibility

The largest lever on Claude spend is usually the same as on any provider: send each request to the cheapest capable tier rather than defaulting everything to the top of the family. A great deal of production work — classification, extraction, routing, short replies — runs well on a Haiku-tier model, while only the genuinely hard reasoning needs an Opus-tier one. We covered the routing patterns in general in model routing for cost savings.

The discipline that keeps routing honest is attribution: tag every call with the feature and the model that served it. Without that, a routing change is invisible until the invoice, and you cannot tell whether a cost movement came from more traffic or from traffic drifting onto a more expensive tier. Token cost tracking captures feature, model, and token split on every Claude call, alongside your other providers, in one schema.

A minimal tracking checklist

Bringing it together, a practical Claude cost setup records, per call:

• The model that served it (read from the response, never assumed).
• Input and output token counts, separately.
• Cached versus uncached input tokens, so the discount is applied correctly.
• Your business tags — feature, team, user.
• A computed cost from a current, updatable rate table.

With those five things captured, the useful questions follow directly: cost per feature, cost per user, cost per completed task, and whether any of them is drifting. As an illustrative example only, and with entirely made-up numbers: a support feature might run most of its traffic on a Haiku-tier model at a small fraction of a rupee per call while an escalation path uses an Opus-tier model at many times that — the exact figures depend on current pricing and your token profile, so treat this only as the shape of the analysis.

FAQ

How do I track Claude API costs by feature? Tag every Anthropic call at the call site with your feature, team, and user, record the model and the separate input/output token counts, and compute cost from a current rate table. Token cost tracking does this across Claude and your other providers.

Which Claude models should I use to control cost? The Claude 4.x family spans Opus, Sonnet, and Haiku tiers at very different per-token prices. Route high-volume, simpler work to a Haiku-tier model and reserve Opus-tier models for genuinely hard reasoning, then verify the split with per-model attribution.

How does prompt caching affect cost tracking? Cached prefix tokens are billed at a steep discount, so your cost computation must price cached and uncached tokens differently, and you should track cache hit rate as a cost metric — a dropped hit rate raises spend invisibly.

Where do I get current Claude pricing? Always check Anthropic’s official pricing page. Model names and per-token rates change, so keep pricing in an updatable rate table rather than hard-coding it.

---

Tracking Claude cost well is mostly discipline: capture the model, the token split, the cache state, and your tags on every call. See how AI Vyuh FinOps does this across Anthropic and every other provider with token cost tracking, watch for output drift with anomaly detection, and cap spend with budget alerts — or read more on the blog. Running Claude at scale across teams? Email finops@aivyuh.com or see enterprise.