Engineering · Performance
Codex CLI owns the worst tail — 6.8k ms p95, 11.2k ms p99
The tail users feel lives in Codex CLI on gpt-5-codex — 6.8k ms at p95, 11.2k ms at p99, vs a fleet p95 of 2.5k ms. It also throughputs the fewest 31 out-tok/s. But speed is not success — 540 fast responses can still be wrong answers, and that axis is not measured here.
Fleet p95 latency
call-weighted across 5 agents
Slowest agent (p95)
Codex CLI · gpt-5-codex
Best throughput
data-pipeline-agent · fastest emitter
Outlier responses
slowest individual calls in window
LLM response latency — percentiles by agent
read the tail (p95 / p99), not the average · lower is betterCodex CLI
gpt-5-codex
Claude Code
claude-opus-4-8
support-copilot
gpt-4o
Cursor
claude-sonnet-4-6
data-pipeline-agent
claude-haiku-4-5
Codex CLI's p99 (11.2k ms) is 4.7× its p50 (2.4k ms) — a wide tail means users hit multi-second waits well beyond the typical case. data-pipeline-agent stays tight (400→2.2k ms).
Output throughput — tokens / second
how fast each agent emits tokens · higher is betterdata-pipeline-agent emits 120 tok/s — 3.9× the slowest (Codex CLI at 31 tok/s). Low throughput compounds tail latency: long answers on a slow emitter are where users wait the most.
Slowest responses
individual outlier calls · the tail you actually feelWhen | Agent | Model | Latency | Tokens | Session |
|---|---|---|---|---|---|
| 2026-06-02 19:28:00 | Codex CLI | gpt-5-codex | 11.2k ms | 28.4k | ee71aa90 |
| 2026-06-03 13:01:00 | Claude Code | claude-opus-4-8 | 7.8k ms | 19.8k | 1a1f867b |
| 2026-06-03 13:50:00 | support-copilot | gpt-4o | 6.1k ms | 14.2k | ab9920fd |
The slowest single call — 11.2k ms from Codex CLI (28.4k tokens) — is what a user actually waited on. Big-token answers on a slow model dominate the tail.
Latency ≠ task success — a fast wrong answer is still wrong
Every number on this page measures how fast a model responds — not whether the agent accomplished the goal. A 400 ms reply that hallucinates an API, ignores a constraint, or needs a human to redo it is a failure that looks healthy here. Optimizing latency without measuring outcomes optimizes for confident speed, not correctness.
Task Outcomes & Quality — success rate, goal completion, intervention rate, and output quality — is the named gap. Pair it with latency before re-modeling: a slow-but-correct agent may beat a fast-but-wrong one.
Do next
Fields: performance.agents (name · model · calls · p50 · p95 · p99 · avg_ms · tput) · performance.slowest (ts · agent · model · duration_ms · tokens · session). Derived: fleet p95 (call-weighted) · tail ratio (p99 ÷ p50) · throughput ratio — from app/data/c16-fleet.ts (qcontrol /api/performance shape).