Blog

What the Anthropic and OpenAI admin APIs actually tell you about spend

Both providers expose usage and cost reports to administrators. Here is what each one groups by, what neither reports, and what that means for anyone trying to attribute AI spend to people.

Sep 11, 2026 · 5 min read

If you want to know what your company spends on AI per person, the first question is what the providers will tell you. Both Anthropic and OpenAI have administrative APIs that report usage and cost for an organization. They are more capable than most finance teams realize and less complete than most engineers assume. This is a plain description of what each one reports, as of this writing, and what you have to do yourself.

Anthropic

The Anthropic admin API is opened by an admin key, a different credential from the API keys that send prompts. An admin key reads usage, cost and the directory of workspaces and keys. It cannot send a prompt and it cannot read one.

Usage comes back as daily buckets grouped by the dimensions you ask for: workspace, API key, model, service tier, and context window. Each bucket carries token counts split by type: uncached input, cached input, cache writes at two durations, and output. That split matters because each type is priced differently. So at the key level you know exactly how many tokens of each kind a key used, per model, per day.

Cost comes back as daily buckets grouped by workspace and by a description line that names the model, the token type and the tier. Cost is not grouped by key. This is the central fact for attribution: Anthropic will tell you a workspace spent a certain amount on output tokens for a given model on a given day, and it will tell you which keys used output tokens for that model that day, but it will not tell you which key the dollars belong to. That join is yours to make, and the natural method is to split each cost bucket across the keys by their share of the matching tokens.

The directory lists workspaces and the keys in each, with names and status. A key's name is often the only human clue to what it is for. Anthropic does not, on the admin API, name the person who created a key.

Claude Enterprise is a separate surface with a separate credential, an analytics key created by the organization's primary owner in the Claude application. It reports, per user and per day, usage and cost across the products the seat covers: chat, Claude Code, and the others. Every actor comes with an email, so this surface resolves to people on its own. Cost here is what the seat's usage consumed, reported, not allocated.

OpenAI

OpenAI's admin API is opened by an admin key created at the organization level, again distinct from project keys. It reads usage, cost and the directory of users, projects and keys.

Usage is per endpoint family (completions, embeddings, images and so on), as daily buckets grouped by project, user, API key, model and whether the request was batch. Token counts are split into input, cached input and output. Grouping by user is available where the request carried a user identifier, which it often does not for server-side traffic.

Cost is daily buckets grouped by project and by line item, where a line item names a model and a token type. As with Anthropic, cost is not grouped by key. Tokens at the key level, dollars at the project level, the same gap to close the same way.

The directory lists organization users with emails, projects, and the keys in each project. Here OpenAI does something useful: a key records its owner, and when the owner is a user rather than a service account, you know the person. A key owned by a user resolves to that user without anyone doing anything. A service account key does not, and should not.

ChatGPT Enterprise is different again. Per-person usage for a workspace is published as a cost log on OpenAI's compliance logs platform: files, one row per user per hour, with product, model, tokens and the charge in credits or dollars, read with a workspace admin key that carries only the cost and user permissions. It is retained for thirty days, so a company reading it has to keep reading it.

What neither reports

Reading both APIs for a while makes the shape of the gap clear.

  • Neither reports API cost by key. Both report tokens by key and cost one level up. Allocation is on you.
  • Neither reports who is behind a key in the general case. OpenAI records an owner when there is one; Anthropic records a name. A shared key is a shared key on both.
  • Neither reports what the tokens were for. No prompts, no completions, no conversation content, and a finance tool should not want them. Usage metadata is the boundary.
  • Neither reports spend on personal plans. A Max plan on a corporate card does not appear on any admin API. That is a card program problem.
  • Cost gets revised. Both providers correct recent days as late events land, so any reader should re-read the last week or so on every pass rather than trusting a day the first time it appears.

What that means in practice

To get from these APIs to a per-person spend figure you have to do five things, and the APIs do none of them for you.

  1. Keep one usage ledger with one row per day, per source, per identity, per model, per tier and per token type, so the two providers land in the same shape.
  2. Allocate each day's cost buckets across the keys by their token share, per token type, with rounding that adds back to the reported total.
  3. Resolve keys to people, using what the provider gives you (an owner, a name) and a directory of people by email for the rest.
  4. Keep the seat surfaces separate and unallocated, because they are already per person.
  5. Show what will not resolve, rather than spreading or dropping it.

None of this is hard once it is written down. All of it is missing from the providers' own dashboards, which is why the invoice stays a total.

Arbitir reads both admin APIs and both enterprise surfaces with the credentials described here, validated against the live API before they are stored in a vault, and does the five steps above on a nightly schedule, with the last seven days re-read each night for the providers' revisions.