Updated September 14, 2026 for the usage analytics Anthropic now ships on Team and Enterprise plans, and October 6, 2026 to add privacy controls.
Every few weeks somebody tells us they'll build this themselves. They usually can. The vendor APIs are good now, and a first version is about a week of work.
Anthropic has since shipped most of that first version itself, inside the admin settings.
So here's how to build it. Then here's what you run into next, because that part nobody scopes.
Start with the dashboard Anthropic already ships
On a Team or Enterprise plan, click your initials, open Settings, then Analytics. Anthropic's walkthrough of the page lists every chart on it. Owners and Primary Owners see all of it, and on Enterprise, Admins see everything except spend.
Before you write a line of code, open that page and count how many of your questions it already answers. It refreshes daily, one day behind, and none of it carries what anyone typed.
| The question | Where it lives in Analytics |
|---|---|
| Who has a seat, and who uses it | Overview: active members against assigned seats, weekly active members, groups, and a member list, with a filter by product |
| How often, and on which surface | A page each for Chat, Claude Code, Cowork, and Claude Design: chats or sessions per day, the share of people with at least one, and daily, weekly, and monthly actives |
| What tools they use | Skills (uses and cost per use), connectors (users, plus read and write counts), top MCP (Model Context Protocol) servers, tool usage, and sessions by agent type |
| What came out | Pull requests, lines of code, designs, file operations, conversations, MCP writes, and an estimated time saved |
| What it costs | Total spend and spend by model (month, quarter, and year to date), spend concentration, usage limits, and an Export spend report button |
Enterprise adds two more. The Analytics API returns the same numbers per member per day (chat, Code, Cowork, and cost) once your Primary Owner turns it on and creates a key, and analytics chat answers plain-language questions about them.
How to build the rest of a v1
No paywall on this part. Claude is the worked example below; if you run several assistants, multiply the four pieces by the number of vendors and keep reading.
The dashboard gives you counts. Everything in v2 runs on the conversations themselves, and those still take a build.
- Claude Code telemetry. In your Anthropic org settings, under Claude Code, push OpenTelemetry config to your users: an OTLP logs endpoint, a traces endpoint, your auth headers, and protocol
http/protobuf. That covers the CLI, the IDE and the desktop app. You need Owner permissions. Each developer approves the new endpoint once, and prompt text stays out of the logs until you turn it on. - Cowork telemetry. Different screen, under Cowork monitoring, and it sends logs only, over
http/jsonorhttp/protobuf, with no gRPC option. It also wants a recent Claude Desktop build, and here the prompt text is on by default. - Chat history. Organization settings, then Data and privacy, then Export data. Anthropic emails a link to a zip file. This one is an export rather than a feed, so "current" means whenever somebody last ran it. Enterprise plans can pull it through the Compliance API instead, which also returns Cowork and Claude Code session transcripts, so one key covers history for all three surfaces.
- Cost. For a Team or Enterprise org this stopped being a separate API. The Export spend report button gives one CSV row per person, per model, per product (Chat, Claude Code, Cowork, and the Office add-ins). Each row carries request counts, prompt and completion tokens, and net and gross spend, for any window up to 90 days back. On a usage-based Enterprise plan the Analytics API serves the same numbers. On a seat-based Enterprise plan the export shows only the spend beyond your seat allotment.
One practical note: if anything else in your stack already consumes OpenTelemetry, don't point two exporters at two destinations. Run a single collector and fan out from there.
What v1 gets you
Anthropic's dashboard answers the volume questions on day one. Who has an account, who actually opens it, how often, on which surface, and what it costs.
A v1 that answers the volume questions earns its keep on its own. It settles the 200-seats-for-40-people question, finds the team that got licenses in March and never logged in, and puts a number on the bill before finance comes asking.
The feeds you built add the ability to spot-check individual runs, and v1 stops there. As it turns out, most of these projects stall right there: you can see that people use AI, and you still can't say whether any of it works.
What v2 takes
The real work is getting from "usage went up" to "here's what to do Monday," and that's where the next nine items live.
- Classification. A transcript tells you a conversation happened. To learn anything you need every conversation labeled: which task, how complex, whether it worked, whether the person had to fight the model to get there. That takes a model pipeline with an eval set behind it, not a chart. The dashboard's skill, connector, and agent-type counts tell you which tools people reach for, and leave the task itself unlabeled.
- Patterns instead of spot-checks. Nobody scans 40,000 conversations one at a time. You need clustering that surfaces the twelve things your team keeps doing, ranked by how much time they take, without a human sampling transcripts and guessing.
- People, skills and agents count as different units. A per-user chart quietly breaks the first time work moves to an agent, because the same task shows up as a service account at 3am. Deciding what counts as one person's output turns into a modeling problem.
- One story across surfaces. Chat, IDE, agents and Cowork describe the same person four different ways, in four schemas, on four release cadences. Stitching one identity across them consumes most of the ongoing maintenance. Anthropic now does this stitching for its own surfaces, one member per row in the dashboard and the Analytics API, which covers the counts. The content feeds still arrive in their own schemas, and a second vendor brings another set.
- Something to compare against. Your dashboard will say usage rose 30%. It can't say whether 30% counts as good for a team like yours, because it has only ever seen you. Comparing your own teams against each other covers part of it, and the rest takes someone who has watched a lot of companies try this.
- A tie-out to outcomes. Time saved only proxies for value. The Claude Code Value tab now hands you an estimated time saved, with the formula shown and the inputs yours to edit. The question a CFO signs off on joins usage to CRM data: did the accounts your reps worked with AI close faster, at better rates, and with fewer touches. That join is doable, and it takes longer than a week.
- A way to work with the data. Dashboards get opened during launch week and then live in a bookmark. Put the data behind MCP, so people can ask it questions inside the tools they already use, and you change who bothers to look. On Enterprise, analytics chat already does this for the dashboard's own numbers.
- Privacy controls before the rollout. The first thing employees ask is whether this means someone is watching them, and a v1 with every transcript behind one admin login has no good answer. Show patterns by team by default and grant named views person by person. Limit each leader to the teams they lead, hold back figures for groups too small to stay anonymous, keep conversation text out of view, and put sensitive topics behind their own clearance. Then you can start with patterns only and open names later, once you decide to.
- Change management. The last mile has nothing to do with analytics. Somebody has to take what the top quartile does, turn it into something everyone can run, and then get them to run it. A dashboard won't close that gap no matter what you build into it, because publishing and adoption are a different product.
Where that leaves you
Add it up honestly and it's classification models, an identity graph, a permission model, a benchmark set, a delivery surface, and somebody who owns the outcome. Almost none of that is dashboard work, which is worth knowing before you scope it as a dashboard.
Some teams should build it anyway. If AI usage data sits close to what you sell, own it.
For everyone else the useful move is smaller. Turn on the dashboard, build the feeds, price the next nine items in engineer-months, then make the call with real numbers.
Don't start v2 until you've priced it. Most teams find they need three of the nine, not all of them, and a week of telemetry is what tells you which three.