Quick answer
Collect tokens, model, project, and date from each machine, aggregate before sharing, and report team totals before individual ones. The decisions the data should support are seat sizing, budget planning, and tool choice, not performance ranking. Prompt content is never needed.
The minimum field set
| Field | Why | Sensitive |
|---|---|---|
| Tokens by type | Cost and efficiency | Low |
| Model | Rate and quality | Low |
| Project | Attribution | Medium |
| Date | Trend | Low |
| Person | Seat sizing | Medium |
| Prompt text | Not needed | High |
A process that survives review
- Agree the fields and the retention period in writing.
- Have each developer run a local tracker and export aggregates.
- Aggregate centrally without collecting session content.
- Publish team totals first, then per-seat numbers.
- Use the numbers to size plans, not to rank people.
A per-person leaderboard changes behaviour quickly and rarely for the better. It rewards small tasks and punishes the hard work that consumes the most context.
What the data should decide
- How many seats of each tier to buy.
- Whether a tool earns its renewal.
- Which project needs a budget cap.
- Whether an alert threshold is set correctly.
- Whether a cheaper model can cover routine work.
UsageAtlas runs per machine, so each developer can share aggregates without sharing sessions. The AI coding cost tracker guide covers the money view.
Questions, answered
How do I track AI usage for a team?
Run a local tracker per machine, export aggregates such as tokens, model, project, and date, and aggregate centrally. Prompt content is unnecessary.
Should managers see per-person token counts?
Only for seat sizing, and preferably after team totals. Individual counts are a poor performance signal because task mix drives them.
What is the smallest useful report?
Monthly tokens and spend by team, with blocked days noted. That is enough to size plans and spot a tool that is not earning its cost.