Claude on Vertex AI is serverless — Google describes the models as "fully managed and serverless models as APIs," with no infrastructure for you to provision. That's operationally wonderful and attributionally awkward: there's no VM or cluster to tag per team. Cost attribution therefore has to come from how you organize the calls, not from tagging hardware. Four layers, from coarsest to finest:
Layer 1: projects — the attribution unit that always works
On GCP, billing rolls up by project, and everything about Claude on Vertex — model enablement in Model Garden, IAM grants, quota buckets — is project-scoped. Giving each team (or each major product) its own project makes attribution automatic: the Billing cost table already breaks spend out per project, no queries required. Quotas are also per-project, so a project boundary doubles as a blast-radius boundary — one team's backfill can't exhaust another team's tokens-per-minute. If you're starting fresh, this is the highest-leverage decision; the project preflight checklist covers the setup cost, which is modest.
Layer 2: labels and the BigQuery billing export
Labels are GCP's key-value tags (team=payments, env=prod) attached to resources and carried into billing data. For finer-than-project reporting, the standard mechanism is Cloud Billing's export to BigQuery: enable the export on your billing account, and detailed usage rows — including project, SKU, and label metadata — stream into a dataset you can query with SQL and feed into dashboards. Grouping exported rows by label key gives per-team or per-feature cost views across shared infrastructure.
An honest caveat for the Claude case specifically: the serverless Claude endpoints are invoked per-request rather than provisioned as labeled resources, and Google's Claude partner-model documentation does not spell out label support on those prediction calls. Before you architect chargeback around request-level labels, verify in the current official documentation which label or annotation metadata (if any) the Vertex AI prediction surface propagates into billing export for partner models. If the answer is "not enough," fall back to project separation (Layer 1) — it is unambiguous — or to the usage-side layers below.
Layer 3: token metrics for usage-side attribution
Cost is tokens times rate, so accurate token accounting is attribution's other half. Google's quota documentation makes a point worth repeating: token usage shown on the console Quotas page can be inaccurate because of Anthropic's token estimation and refund system — for reliable numbers, use the token counting API or the token_count metrics in Metrics Explorer. Those metrics, combined with the per-model rates on Google's pricing page (and the modifiers that matter: 10% regional-endpoint premium, 50% batch rates, 0.1x cache hits), let you compute per-workload cost even where billing rows are coarse.
Layer 4: audit logs for per-caller forensics
When you need "who exactly made these calls," Cloud Audit Logs are the ground truth. Online prediction calls — including endpoints.rawPredict, which is what Claude requests are — are recorded as Data Access (DATA_READ) audit log operations, though note Data Access logs are disabled by default and must be explicitly enabled. Audit logs can be routed to BigQuery just like billing data, and joining "calls by principal" against token metrics gives a defensible per-caller usage picture. Reading Data Access logs requires the Private Logs Viewer role (roles/logging.privateLogViewer). The full setup is in exporting Vertex AI audit logs to BigQuery and the audit logs deep dive.
Putting it together
| Layer | Resolution | Effort |
|---|---|---|
| Project per team | Team | Low — billing console shows it natively |
| Labels + BigQuery billing export | Feature / environment | Medium — verify label propagation for partner-model calls |
| Token metrics (Metrics Explorer) | Model / endpoint / workload | Medium |
| Data Access audit logs → BigQuery | Individual caller | Higher — logs must be enabled first |
Where to go next
For reading the invoice itself, see reading your Vertex AI Claude bill; for the organizational practice this feeds, FinOps for LLMs.