Most teams read four fields from the usage object in a Messages response: input_tokens, output_tokens, and the two cache counters (cache_creation_input_tokens, cache_read_input_tokens). That covers token billing. But if your requests use server tools like web search, or run on different serving tiers, two more fields decide what your invoice looks like — and they're the only per-response record you get.
usage.server_tool_use: counting the tool calls you're billed for
Server tools are tools Anthropic executes on its side — web search and web fetch are the canonical examples — and they're billed per use, on top of tokens. The usage.server_tool_use object in each response reports how many of those executions happened, with counters such as web_search_requests and web_fetch_requests.
This matters because a single Messages request can trigger several tool executions: Claude may search, read results, and search again before answering. Your application made one API call; the invoice reflects three searches. Without server_tool_use you'd have to parse the response content and count tool-related blocks yourself — fragile, and not authoritative. The usage object is the documented, billing-grade count, which is why it's the right basis for per-request server-tool reconciliation and for passing costs through to internal tenants.
The same counter surfaces in aggregate form in the Usage and Cost Admin API, whose per-bucket results include server_tool_use.web_search_requests — so a well-built pipeline can cross-check its per-response sums against the organization-level report. (One asymmetry documented there: code execution costs appear only in the cost endpoint, not in the usage endpoint.)
usage.service_tier: which lane served the request
The usage.service_tier field reports which serving tier actually handled the request — values such as standard, priority, and batch. The tier determines the pricing and capacity model applied: batch traffic is billed at 50% of standard rates, and Priority Tier runs on a different billing model entirely.
That last point makes service_tier more than trivia. Anthropic documents that Priority Tier costs are not included in the Admin cost endpoint at all — the documented way to track priority consumption is the usage endpoint filtered to service_tier=priority, or your own per-response records of this field. If your organization mixes tiers, a cost report that ignores service_tier will silently omit a slice of real spend.
usage object verbatim on every response, not a hand-picked subset. Fields like server_tool_use and service_tier only appear when relevant, and the requests where they appear are exactly the ones that are hardest to explain at invoice time.Platform notes
Anthropic documents that the response usage object is consistent across all platforms — the Claude API, Claude Platform on AWS, Amazon Bedrock, Google Vertex AI, and Microsoft Foundry — so the field shapes above are portable. What varies is whether the features that populate them exist on your platform: web search is absent on Bedrock and only available in its basic variant on Vertex AI, and web fetch is unavailable on both, so server_tool_use counters are largely a first-party, Claude Platform on AWS, and Foundry concern. Serving tiers follow a similar pattern — Anthropic's Message Batches API is not available on Bedrock or Vertex AI, which instead offer their own cloud-native batch inference with separate billing (S3-based on Bedrock, BigQuery/GCS-based with 50% batch pricing on Vertex). In streaming responses, these fields arrive in the final message_delta event — see the streaming usage semantics article for why that event is the one to record.
Where to go next
For the tools themselves, read the web search tool guide and the web fetch tool guide. For organization-level reporting that aggregates these fields, see the Usage API dimensions and filters and cost endpoint mechanics.