AI Cost Tracking by Provider: What Each One Reports

AI providers do not expose one common cost record. Anthropic and Cursor can identify a member. OpenAI offers a partial key and model breakdown. Bedrock may arrive as a coarse marketplace line. A cross-provider total is only as useful as the detail preserved from each source.

The matrix below records three things for each provider: what can be attributed, the strongest evidence state available before reconciliation, and the control that closes the remaining gap. Use the most detailed native record first. Add gateway tags, cloud labels, or invocation logs only where the provider loses information you need.

The provider determines how much you can know

“Best confidence” means the strongest state available from the source itself. It does not replace reconciliation; the invoice remains the record that settles the amount.

Direct model APIs retain the most operating detail

Anthropic (Claude)

Anthropic is one of the most transparent direct providers. Its usage and cost reports resolve spend per API key, per workspace, and per member, which means developer-level attribution comes straight from the provider, with no gateway required. The figures are Provider reported until you match them to the invoice, but you start from the best grain in the category. Use that native detail before adding another attribution layer.

Cursor

Cursor exposes daily usage, team spend, and filtered usage events down to the member, so seat-based AI spend is attributable per developer. It is a seat license that reports more like a metered API. That makes member-level showback possible from the source record.

OpenAI

OpenAI’s organization usage and costs endpoints provide a partial breakdown by day, model, and key. That is enough to see the shape of spend, but not always enough to assign it cleanly to a team. The fix is structural: use a distinct API key per team or purpose, or an AI gateway that stamps each request, so spend is separated before it is ever summed. Everything it reports is Provider reported, provisional on the invoice.

Cloud billing trades request detail for infrastructure consistency

Bedrock and Vertex pass through billing systems designed to itemize infrastructure. Those systems are consistent at the account, project, and SKU level, but they do not automatically preserve the person or request that caused the spend.

Amazon Bedrock

Bedrock surfaces through AWS Cost Explorer and CloudWatch model-invocation metrics. Billed directly, the result is workable. When billed through AWS Marketplace, developer- and key-level attribution can disappear, leaving a coarse account-and-model figure. EnableBedrock model-invocation logging in CloudWatch and tag by inference profile to restore detail the invoice will not contain. Until the AWS bill reconciles it, the number is an Pharos estimate.

Google Gemini and Vertex AI

Gemini and Vertex bill through Google Cloud, so their cost tracking inherits GCP’s billing export: project- and SKU-level detail, with per-team attribution coming from project structure and resource labels rather than the model API. Set the labels up front and the allocation is clear. Skip them and you may get one Vertex line for the whole organization. Like any cloud-billing figure, it is an Pharos estimate until the GCP invoice settles.

Gateways preserve the context a shared key removes

A gateway can add team, project, customer, and model tags to every routed call. That restores an itemized record behind a shared key. Gateway figures may still be Pharos estimate values calculated from documented prices, so match them to the underlying provider invoices before close.

Use native detail first, then repair the gaps

The operating sequence follows directly from the matrix:

1. Use what the transparent providers give you. Anthropic and Cursor already report per member. Do not rebuild what the provider already records.
2. Add grain where it is missing. For OpenAI, Bedrock, and Vertex, the fix is a key per team, a gateway tag, or cloud labels and invocation logging, set up before spend aggregates, not reverse-engineered after.
3. Reconcile per provider, then roll one total. Never add a Provider reported figure to an Pharos estimate and call the sum precise. Settle each provider against its own invoice first.

Once you know what each provider can tell you, the remaining work is to rolling one trustworthy total across all of them, reconciling each against its invoice, and allocating the result to the teams and customers that drove it. And if you are choosing a tool to do this, judge it by its source labels: can it name the source of every figure, or only draw a line?