Anthropic published a long guide on October 27, a 17-minute read, prompted by a recent webinar with Google Cloud. It answers the question platform teams get as soon as Claude Code runs at scale: what does this cost, and what comes back. Anthropic sorts the answer into three levers, control, track and prove.
Control: guardrails instead of caps
The control sits in the Claude apps gateway, a self-hosted service running inside your own Google Cloud project between Claude Code and Claude on Google Cloud. It ships in the same claude binary your developers already have. Sign-in goes through your identity provider, Google Workspace for instance, so every request carries a verified identity.
Four mechanisms build on that: spend caps per user, per IdP group or organization-wide, by day, week or month; in-CLI warnings past 75% and past 95%, while Google Cloud billing alerts are meant for admins; model defaults and allowlists the gateway enforces server-side on every request; and an admin API so caps can be raised from a ticketing workflow. At the cap, the gateway returns 429 until the period resets or someone lifts it.
The notable part is where Anthropic locates the waste. Expensive sessions are not bad in themselves, it argues, and are often the most valuable. The money burns in the long middle: Fable on a daily routine Sonnet could handle, or a scheduled task nobody needs that keeps firing anyway. The number that matters is not price per token but cost per task.
Track: where the money goes
Claude Code’s OpenTelemetry metrics report usage and estimated cost, broken down by skill, plugin, agent and MCP server. That makes it visible which of your internal skills and plugins people actually adopt. The route is OTLP into tools you already run, Google Cloud Monitoring among them.
You do not have to configure this per machine: set a telemetry destination on the gateway and it turns on for every signed-in developer, with each export tagged with their verified email and IdP groups instead of client-side values. For your own cost-center logic there is OTEL_RESOURCE_ATTRIBUTES. Alongside that sit the Google Cloud pieces: a dedicated project for Claude Code, budget alerts, spend caps in preview, quotas, provisioned throughput, and a BigQuery export filtered to Claude SKUs by model and token type.
Prove: three dimensions, and one hard question
Anthropic splits the proof into usage, developer satisfaction and impact. Satisfaction comes from a short survey before and after rollout. Impact breaks into three groups: time, meaning PR cycle time from open to merge and code review turnaround; effort, meaning review iterations, comments and rework per PR; and volume, meaning PRs per engineer, deployment frequency, and named bodies of work the freed capacity delivered.
The hard question hides in the unit of work. A typo fix and a feature release are both one PR. Anthropic’s suggestion: count only merged PRs of a defined class, the ones where Claude opens the PR and a person decides whether it ships. Not every finished thing is a PR; a service cutover or an incident closed at its root cause counts by the same rule, wherever it lands.
The guide arrives on the right day
On the same day, Amazon published a memo calling token usage a deeply flawed metric. Anthropic’s paper says much the same thing from the vendor’s side: price per token is not the number that counts. What makes the guide worth reading is not the feature list but the section on the unit of work. Skip that, and you build dashboards that look good and prove nothing.