Expand a member (▸) to see their Claude Code inference latency broken down by model, read from sub2api's own request log (usage_logs). Streamed requests only, and the timing is server-side (sub2api → Anthropic) — it excludes each user's own network, so it isolates model / account / queueing differences rather than someone's home Wi-Fi.

• reqs — how many streamed requests this user made for that model in the window (the sample size).
• TTFT p50 / p95 — Time To First Token: from the request being sent to the first token coming back (queue + prompt prefill). p50 = median, p95 = slow tail. This is the fair apple-to-apple number — it does not depend on how long the answer is, so you can compare users and groups directly. From first_token_ms.
• dur p50 — median total duration (first token → last token). It grows with answer length, so only compare it within a similar workload. From duration_ms.
• tok/s — output tokens per second (generation throughput) = output_tokens × 1000 / duration_ms.
• avg out — average output tokens per request (AVG(output_tokens)) — this is usually why one user's duration is higher than another's.
• low-n — fewer than 100 samples; treat that row as indicative only (percentiles need volume to be trustworthy).
• 24h / 7d — the time window the numbers cover. 7d gives steadier numbers (more samples); 24h reflects right-now behaviour.

Percentiles are computed in Postgres via percentile_cont over the per-(user × model) rows. Same metrics, per-group, appear in the fleet dashboard's “Model Response Delay by Group” section.