Skip to main content
A client report answers a question no vendor publishes: of the coding agents developers have installed, which ones do they actually spend their tokens in, and what do they run inside them. /metrics/clients ranks up to 100 coding clients by their trailing 30-day token volume, each with a sparkline of that window. Selecting one opens a full report at /metrics/clients/{client} covering up to 365 days. The windows and ranking rules behind both are on How Usage Reports Work.

​
The directory

The directory is the comparison view. Each row carries the client’s identity, its token volume over the ranking window, its movement against the prior window, and its publication status, so an agent still accumulating history is visible as such rather than missing. You can sort and filter the list, and search it by name.

​
What a client report shows

The detail page is where a client report earns its keep, because usage is broken down by token class rather than reported as one number:
  • The full token breakdown: input, output, cache-read, cache-write, and reasoning tokens, each counted separately.
  • Messages and active days alongside the token totals, so volume can be read against how often the agent is actually used.
  • Active developers, and how that count moved against the prior window.
  • Estimated spend, with spend per 1M tracked tokens and the cache-read share of the client’s traffic.
  • A profile of the client and links to its project.
Cache-read share is worth reading closely. Two agents with identical token totals can differ sharply in cost, because an agent that reuses context aggressively bills very differently from one that resends it.

​
The models inside each client

Every client report ranks the models developers chose inside that agent, with each model’s share of the client’s tokens, its estimated spend, its active developers, and its own movement. This is the half a model-first view cannot show. A model’s overall popularity says nothing about which harness developers reach for it in, and the same model often occupies a very different position in one agent than another. Each entry links through to that model’s own report.

​
How clients are identified

Clients are matched to a canonical registry before aggregation, so the same agent reported under several names collapses to one entry rather than splitting its usage across near-duplicates. The registry is its own list, maintained for attribution, and it is not the same list as the agents the CLI can read from disk. An agent can be readable by the CLI without yet being a ranked entry here. For what the CLI reads, see Supported Clients.

​
Next steps