Measuring your real throughput from your provider's console

Before sizing anything, you need to know what you actually consume. The consoles will tell you — provided you know what they leave out.

Anthropic's console reports consumption by model, workspace, and service tier. To pull it programmatically, the Admin API offers the /v1/organizations/usage_report/messages endpoint. Mind the key type: it requires an Admin API key, distinct from an ordinary API key, and Claude Enterprise organizations use an Analytics key instead.

The detail that matters for sizing is granularity. Time buckets go down to one minute. Divide a bucket's generated tokens by 60 and you have an average throughput in tokens per second — the only unit that helps you reserve capacity. At daily granularity that information is gone.

Don't conflate the two data streams. Usage shows up within minutes; cost refreshes every four hours, can take up to 24, and stays revisable for 30 days as late events reconcile. Size against usage. Invoice against consolidated cost.

Then comes the structural limit, and it's a serious one: an aggregated bucket says nothing about concurrency. Ten AI agents generating at 50 tokens/second for a minute and a single AI agent generating at 500 produce exactly the same number. Yet concurrency is what determines the capacity you need — not the total.

The second limit is easier to fix: attribution. A breakdown by team or service exists only if you separated keys and workspaces before you wanted the data. No console reconstructs retroactively who consumed what. If you expect to measure someday, create the separate keys now.

Other providers offer a console of comparable shape, with the same underlying limit. To get past the total and reach peak and concurrency, you have to instrument the path traffic takes rather than read the invoice.