Two populations of traffic
Every request in a project falls into one of two populations. The split decides which views it shows up in.
In custom dashboards the same split is exposed as the
population field, with the values coding_agents and workloads.
Traffic only counts toward a person when it runs on that person’s personal key. Shared or project keys land in the workload population, even when a developer sends them from a laptop.
Where analytics live in the console
Developers space
Team and individual views, agent comparisons, sessions, repositories, and delivery for coding-agent traffic.
Analytics
Spend, Usage, and Activity tabs, with Tokens, Cache & compression, Routing, and Traffic shape reports.
Traces
Every request, span, and session, searchable down to the individual call.
Dashboards
Charts of your traffic, built by you or your coding agent, with alerts on any measure.
Set up analytics
1
Route coding agents through personal keys
Each developer gets a personal key and points their agent at the gateway. See Coding agent analytics.
2
Label your application traffic
Add workflow, session, tag, and end-user headers to app requests. See App analytics.
3
Connect GitHub (optional)
Link merged pull requests to the agent sessions that produced them. See Repositories and delivery.
4
Build the dashboards your team watches
Start from a built-in dashboard or let your agent build one. See Custom dashboards.
How to read the numbers
- Catalog spend is calculated at catalog list prices. It is not your provider invoice. Requests with no price or incomplete usage are excluded from cost.
- Requests count model calls, not finished work.
- Cache read measures reuse. It is not a verified saving; see Savings evidence for what counts as verified.
- Active days are UTC days with at least one request, not time worked.
- Money values need billing access. Viewers without it still see people, request, and attribution counts. See Access and limits.