Data as of 2 September 2026. Methodology version 1.0. Every figure below is our own measurement of our own agent sessions; external figures carry a source and the date we read them.
Benchmarks Time a Sprint
Model speed, measured in real sessions
118,896 real agent requests, timed end to end, by model, week and hour
Benchmarks time a sprint. Your agent runs a marathon
Every speed figure you can find for a frontier model is one prompt, from one benchmark harness, timed from the first token to the last. Artificial Analysis defines output speed as "the average number of tokens received per second, after the first token is received" and samples it eight times a day from a Google Cloud zone. OpenRouter publishes a rolling five-minute median of the same thing. On 2 September 2026 those pages put Claude Opus 5 at 52 tokens a second at maximum effort and GPT-5.6 Sol at 74.
Neither number describes what happens when you hand a model a codebase and let it work. An agent session is a chain of requests. Each one waits for the model to think, streams a few tool calls, runs them, and starts again with a bigger context. The pace you feel is set by how the model spends its minutes, not by its decode rate on a clean prompt.
We run a fleet of Claude Code and Codex agents across our own client work, and every session leaves a transcript on disk with a timestamp on every record and the provider's token counters on every reply. So we measured the thing no benchmark page publishes: how many output tokens a model actually delivers per wall-clock minute inside real sessions, across eight weeks, by model, by week and by hour. The dataset covers 118,896 model requests, 103 million output tokens and 484 hours of model time. This is what it says.
What 118,896 real requests say
The table below is the median observed output rate per model in our main interactive sessions, with the ninetieth percentile, the median seconds until the first content block landed, and the share of output that was thinking rather than visible text or tool calls. One request is one reply from the model; rates are output tokens per wall-clock minute from the moment the request was sent to the moment its last block was written.
| Model | Requests | Median tokens per minute | Tokens per second | 90th percentile | First output (median) | Thinking share |
|---|---|---|---|---|---|---|
| Claude Fable 5.1 | 1,003 | 4,311 | 72 | 5,282 | 10.9 s | 39% |
| Claude Opus 5 | 64,675 | 3,628 | 60 | 4,754 | 8.1 s | 18% |
| Claude Fable 5 | 20,282 | 3,375 | 56 | 4,760 | 8.8 s | 21% |
| Claude Opus 4.8 | 4,024 | 3,261 | 54 | 4,298 | 11.3 s | 4% |
| Codex (GPT-5.6) | 18,368 | 2,490 | 42 | 3,639 | 3.5 s | 37% |
| Codex auto-review | 4,465 | 1,538 | 26 | 2,185 | 2.5 s | 41% |
Three things stand out. Claude Fable 5.1, released the day before this snapshot, is the fastest model we have run in a main session, and it gets there while spending 39 percent of its output on thinking. Claude Opus 5 sits at 3,628 tokens a minute across nearly 65,000 requests, which is the number to plan around if you run agents on it today. And Codex on GPT-5.6 delivers fewer tokens per minute than any Claude model, but its first output lands in 3.5 seconds, less than half the wait of any Claude model, which is exactly why it feels quick in the terminal.
Aggregate rates (total tokens over total minutes) run a little above the medians: 3,717 for Opus 5, 4,697 for Fable 5.1, 2,581 for GPT-5.6. Long replies amortise the first-output wait, so the more a model writes per request, the closer its aggregate gets to its decode rate.
Observed output speed by model, main sessions
Output tokens per wall-clock minute per request. Bar spans the 10th to 90th percentile, the dot is the median. 7 July to 2 September 2026.
Models with fewer than 500 measured requests in a scope are in the download, not the chart. Source: Jordan James Media session transcripts, provider-billed tokens.
How we measured it, and what the number is not
Every Claude Code session writes a JSONL transcript under ~/.claude/projects/, and every Codex session writes a rollout under ~/.codex/sessions/. Each record carries a timestamp. Each model reply carries the provider's own usage counters, including output_tokens and, for Claude, output_tokens_details.thinking_tokens. We reused the parser our platform already runs at every session close and taught it to time each request.
The rule for one request is simple. It starts at the record written immediately before the request was sent: the user message, tool result or attachment the request went out with. It ends at the last content block of the reply, because Claude Code writes each block as it finishes streaming. Tool execution time is excluded, because the tool result record is written after the tool finishes. Thinking time and time to first token are included, because you wait through both. Divide output tokens by minutes and you have the rate.
We exclude what would mislead. Replies under 20 output tokens are dropped, because a five-token tool call over four seconds says nothing about generation speed; that removed 32,400 of the raw requests. Placeholder and fallback turns, replies with no counters, and 12 requests longer than an hour (an anchor error, not a slow model) are also out. Every exclusion is counted by reason in the published dataset, so a zero is a measured zero.
One thing this number is not: a rate limit. Anthropic quotes its limits in input and output tokens per minute, OpenAI and Azure quote TPM, Google quotes TPM for Gemini. Those are quotas. Ours is observed throughput, which is why we write it out in full and never abbreviate it. When Anthropic talks about speed it says output tokens per second, so every figure here also shows tokens per second.
The other thing it is not: a benchmark decode rate. Our tokens are provider-billed tokens, the ones your invoice and your rate limit count. Artificial Analysis counts every model in OpenAI's o200k_base tokenizer. On this very session's output, billed visible tokens ran 1.64 times the o200k count of the same text, partly because Anthropic's tokenizer has produced more tokens per word since Opus 4.7 (about 555,000 words per million tokens, against 750,000 for the models before it, per Anthropic's models overview). We checked the opposite hazard too: a February 2026 issue reported Claude Code transcripts undercounting output tokens by about two times on Opus 4.6. On the current format the usage counter repeats identically on every block of a reply and carries an iterations array, and the tokenizer check above runs the other way, so the counts we publish are complete.
How one request is timed
A real Claude Fable 5.1 reply from the session that built this page: 1,988 output tokens in 26.7 seconds, 4,467 tokens a minute. The tool then ran for 63 seconds, which is not counted.
Anchor
The request starts at the transcript record written just before it: the user message, tool result or attachment it went out with.
Stream
Every content block is written as it finishes streaming. Thinking is the first block on a reasoning model, so its time is inside the window.
Stop
The request ends at its last block. Tool results are written after the tool finishes, so tool time never enters the rate.
Count
Output tokens from the provider's own usage counter, divided by minutes. Replies under 20 tokens are excluded and counted.
Not a rate limit
The same model runs at three speeds
The headline table is main sessions only: a person at a terminal, a large context, long replies. The same models also run as subagents, short-lived workers spawned for a search or a review with a small context. There the picture changes.
| Model | Scope | Requests | Median tokens per minute | First output (median) |
|---|---|---|---|---|
| Claude Sonnet 5 | subagent | 2,254 | 4,114 | 5.8 s |
| Claude Opus 5 | subagent | 2,368 | 3,724 | 4.6 s |
| Claude Opus 5 | main | 64,675 | 3,628 | 8.1 s |
| Claude Haiku 4.5 | subagent | 339 | 3,621 | 9.3 s |
| Claude Fable 5 | subagent | 835 | 3,017 | 5.0 s |
Opus 5 gets its first block out in 4.6 seconds as a subagent against 8.1 in a main session. Same model, half the wait, because the context is a tenth of the size and there is less to think about before the first token. Sonnet 5 is the fastest thing we run as a worker. And Haiku 4.5, the model Anthropic ranks fastest, is no faster than Opus 5 in our subagent runs: 3,621 against 3,724 tokens a minute, with a longer first-output wait. Short tasks are dominated by the wait for the first token, and a small model does not wait less on our network path than a large one.
Thinking share is the third speed. Opus 4.8 spent 4 percent of its output thinking in our sessions; Fable 5.1 spent 39 percent; GPT-5.6 spent 37. A model that thinks more delivers fewer visible tokens per minute even when its total rate is higher, and visible tokens are the ones that become code. Fable 5.1's 4,311 tokens a minute is about 2,630 visible tokens a minute; Opus 5's 3,628 is about 2,975. On what you can read, Opus 5 is the faster writer.
Main session
- Large context, long replies
- Opus 5 first output 8.1 s
- Median 3,628 tokens/min
Subagent run
- Small context, short task
- Opus 5 first output 4.6 s
- Median 3,724 tokens/min
Speed moves every week
A benchmark page shows today's number. A session dataset shows the drift. Claude Opus 5 went from a median 3,483 tokens a minute in the week of 20 July to 3,865 in the week of 31 August, an 11 percent gain, and its median wait for the first block fell from 10.8 seconds to 6.5, a 40 percent improvement over six weeks. Claude Fable 5 climbed from 2,518 to 3,863 over the same period, although its first two weeks are only a few hundred requests.
Codex went the other way. GPT-5.6 delivered a median 2,856 tokens a minute in the week of 24 August and 2,287 in the week of 31 August, a 20 percent drop in seven days across more than seven thousand requests each week. Anthropic's status page logged elevated-error incidents on several days in August (one example), and OpenAI restored the five-hour Codex cap on 25 August to "smoothen the load on our compute". Weekly medians are where those weeks show up.
If you choose a model on speed, choose on the current week and check again next month. The dataset behind this page is re-snapshotted monthly for that reason.
Weekly median speed, main sessions
One panel per model so the lines never cross. Shared scale, 2,000 to 4,200 tokens per minute. Weeks with fewer than 50 requests are omitted.
Read the Week, Not the Page
Time of day matters for Codex, not for Claude
We bucketed every main-session request by the UTC hour it started. Claude Opus 5 barely moves: between 3,415 and 3,713 tokens a minute in every hour with more than 900 requests, a spread under 9 percent, with its slowest hours at 19:00 to 21:00 UTC, the US afternoon. Whatever load Anthropic carries through the US working day, it reached our sessions as a few percent, not a cliff.
Codex on GPT-5.6 is a different shape. From 04:00 to 16:00 UTC (early afternoon to the small hours in Sydney, the European working day, the US morning) eleven of the thirteen hourly medians sit between 2,130 and 2,440 tokens a minute. From 17:00 to 03:00 UTC every hour sits between 2,600 and 2,940. That is a 15 to 20 percent swing by clock time, on hundreds to thousands of requests per hour. We report it as observed; the cause could be OpenAI's load, our own mix of Codex work by hour, or both. Either way, an Australian team running Codex overnight gets the slow band.
Median speed by hour of day (UTC), main sessions
Darker is faster within each model's own range of well-sampled hours. Outlined cells hold fewer than 500 requests and are left out of the shading range. Hover any hour for the value.
Claude Opus 5 stays within 3,415 to 3,713 in every hour with more than 900 requests, a spread under 9 percent. Codex on GPT-5.6 runs 15 to 20 percent slower from 04:00 to 16:00 UTC than through the rest of the day.
Schedule Around the Slow Band
What the published numbers miss
Put our Opus 5 figure in benchmark units and the gap becomes explicit. 3,628 billed tokens a minute is about 2,210 o200k tokens a minute, or 37 tokens a second, end to end. Artificial Analysis shows 52 tokens a second for the same model at maximum effort, and 47 at high, decode only, after the first token. The difference is the wait: 8.1 seconds to the first block on a median request, plus the thinking inside it.
That gap is also why fast mode moves an agent session less than its headline. Anthropic's fast mode promises up to 2.5 times the output tokens per second and says plainly that the gain is decode speed, not time to first token. OpenAI's Fast mode makes the same 2.5 times claim at twice the price, and the Codex product documentation puts it at 1.5 times the speed for 2.5 times the credits. If a request spends eight seconds waiting and twenty seconds streaming, a 2.5 times decode rate turns 28 seconds into 16, a 1.75 times gain, and the tool runs between requests do not speed up at all. Every request in our dataset ran at standard speed, so the day we turn fast mode on, the dataset will show exactly how much of the claim survives contact with a session.
The only earlier attempt to measure inside a harness was METR's RE-Bench in November 2024, which found agents generating 20 to 120 output tokens a second while spending most of their wall-clock waiting for commands. Every agent benchmark since reports minutes per task and tokens per task, never tokens per minute. Our sessions confirm the shape two years on: the model is rarely the slowest thing in the loop, and when it is, it is because it is thinking.
A benchmark number
- One prompt of 1k, 10k or 100k tokens
- Timed after the first token arrives
- Counted in OpenAI o200k tokens
- Opus 5: 52 tokens a second at max effort
A session number
- 64,675 real requests with growing context
- Timed from dispatch to the last block
- Counted in the tokens you are billed for
- Opus 5: 60 a second billed, about 37 in o200k units
In most runs the agents spend a majority of their time waiting for commands to run on the VM, rather than on generating tokens.
How to choose a model on speed that is real
Decide what you are optimising. For an interactive session where a person waits on each reply, the number that matters is seconds to first output, and Codex wins it outright at 3.5 seconds. For a batch of subagents chewing through a queue, the number is the aggregate rate, and Sonnet 5 and Opus 5 lead. For a long autonomous build, the number is visible tokens per minute after thinking, and Opus 5 writes more code per minute than Fable 5.1 despite the lower headline.
Then measure your own sessions, because your prompts, your context sizes and your network path are not ours. The fields are in the transcript already: the timestamp on every record, message.usage.output_tokens on every reply, output_tokens_details.thinking_tokens for Claude, last_token_usage on every Codex token_count event. Anchor each request to the record before it, end it at its last block, drop the tiny replies, and publish the median and the ninetieth percentile, never the mean. If you build agents with us we set this up on day one, because a fleet you cannot measure is a fleet you cannot tune; that is the same discipline we apply to Claude Code agent teams and custom subagents.
Treat fast mode as a purchase, not a setting. Turn it on for the session shapes where decode dominates, long generation with few tool calls, and leave it off where the wait is the model's thinking or your tools. And never let a vendor's relative label stand in for a measurement: Anthropic's own models page ranks Fable 5.1 "slower" than Opus 5, and on its first day and 1,003 requests in our main sessions it ran 19 percent faster.
Choose a model on speed that is real
- Interactive session: pick on seconds to first output (Codex 3.5 s, Opus 5 8.1 s)
- Batch of subagents: pick on aggregate rate (Sonnet 5 and Opus 5 lead)
- Long autonomous build: pick on visible tokens per minute after thinking
- Measure your own transcripts: timestamp, usage.output_tokens, thinking_tokens
- Publish medians and 90th percentiles, never means
- Re-check monthly: Opus 5 moved 11 percent in six weeks
Build agents you can measure
We instrument every agent fleet we build from the first session, so you always know what a model is really delivering. Custom platforms, integrations and agent workflows, built and run by an AI-native studio in Sydney.
Talk to us about AI developmentWatch it live, take the data
This article launches a standing page, the AI model speed benchmark, which carries the live feed, the per-model figures at stable addresses, the versioned methodology and the downloads, and re-snapshots monthly. The chart above this section is live. Our platform's heartbeat carries each running session's rolling rate (the last 50 requests) into a public feed, refreshed every minute, alongside the weekly history published from the workstation that holds the transcripts. When no sessions are running, the feed shows the last snapshot and says so.
The dataset is free to download and reuse with a link back: model-speed-2026-09-02.csv holds the weekly rows per model, scope and speed tier, and model-speed-2026-09-02.json adds the per-model distribution (p10 to p95), the hour-of-day table and the exclusion counts. Rows carry model names, ISO weeks, counts and durations. No project, prompt, session identifier or dollar figure is in the data. To cite it: Jordan James Media, "AI Model Speed, Measured", dataset of 2 September 2026, methodology 1.0.
Two caveats travel with the numbers. Everything was measured from a single vantage point, our Sydney workstation and its connection, by design: every first-output figure includes the network path a working team actually has, where a benchmark run from a US data centre would flatter the wait. A team in Virginia will see shorter first-output times than we do. And the mix of work differs by model: Opus 5 carried our long interactive sessions, Codex carried more review and verification, so the models were not given identical tasks. We publish the distribution rather than a single number for that reason. The measurement code is the same module our platform uses to reconcile every session at close, the same one that decides whether an agent gets to grade its own homework, and it will be the module that tells us the first week a new model is worth switching to, as it did for Fable 5.
The standing benchmark page
This article is the launch story. The page below is the permanent address: live figures, one section per model, the versioned methodology and the downloads, re-snapshotted monthly.
Right now
Snapshot of 2 September 2026: medians over 118,896 requests. Live figures load when sessions are running.
Take the data, read the method
The standing benchmark page, the dataset behind it, and the posts that explain how we run the fleet it came from.
Questions people ask
The answers below are the short versions of the sections above, kept on the page so that they stay in step with the data.
The short answers
How fast is Claude Opus 5 in a real coding session?
Across 64,675 of our main-session requests between 7 July and 2 September 2026, Claude Opus 5 delivered a median 3,628 output tokens per wall-clock minute (60 tokens a second) with a 90th percentile of 4,754, and its first content block arrived a median 8.1 seconds after the request was sent. Those are provider-billed tokens measured end to end, including thinking, not a benchmark decode rate.
Is tokens per minute the same as the TPM rate limit?
No. Anthropic, OpenAI, Azure and Google all quote rate-limit quotas in tokens per minute, which is how many tokens you are allowed to send or receive. The figures on this page are observed throughput, how many output tokens a model actually delivered per minute inside real sessions. We write the metric out in full and never abbreviate it so the two are not confused.
Why is my agent session slower than the benchmark number?
Benchmarks time one prompt after the first token arrives and count tokens in OpenAI's o200k tokenizer. A session request also waits for the first token and for thinking, and the billed tokens you see run about 1.6 times the o200k count for the same Claude output. Put Opus 5's 3,628 billed tokens a minute in benchmark units and it is about 37 tokens a second end to end against a published 52 decode-only.
Is fast mode worth it for AI agents?
Fast mode raises decode speed by up to 2.5 times on both Anthropic and OpenAI, at 2 to 2.5 times the price or credit burn, and it does not shorten time to first token or tool execution. A request that waits eight seconds and streams for twenty goes from 28 seconds to about 16, a 1.75 times gain, and the tool runs between requests do not change. It pays for long generation with few tool calls and not for sessions dominated by waiting.
How do I measure model speed in my own Claude Code or Codex sessions?
Every Claude Code transcript under ~/.claude/projects/ and every Codex rollout under ~/.codex/sessions/ carries a timestamp on each record and the provider's usage counters on each reply. Anchor each request to the record written just before it, end it at its last streamed block, divide output tokens by minutes, drop replies under 20 tokens, and report the median and 90th percentile per model. Our measurement module and dataset are linked on this page.
Which AI coding model is fastest right now?
In our main sessions Claude Fable 5.1 has the highest median at 4,311 tokens a minute, but 39 percent of that is thinking, so Claude Opus 5 writes more visible tokens per minute. Claude Sonnet 5 is the fastest subagent at 4,114. Codex on GPT-5.6 has the lowest rate at 2,490 but the shortest wait for a first token at 3.5 seconds. Speed drifted by 11 to 20 percent within weeks, so check the live figure on this page before deciding.
Stay in the Loop
Get notified when we publish new content. Choose what interests you.
Choose your interests:
No spam, unsubscribe anytime. We respect your privacy.
Key Takeaway
- 1
Benchmarks time one prompt after the first token; a session pays for the wait and the thinking too.
- 2
Opus 5 delivers a median 3,628 billed tokens a minute end to end; Fable 5.1 4,311 with 39 percent thinking; Codex 2,490 with a 3.5 s first output.
- 3
Speed drifts by 10 to 20 percent within weeks and, for Codex, by hour of day. Measure your own sessions and re-check monthly.
Social Media Carousel
8 cards • Download as ZIP (images) or PDF (LinkedIn)
Benchmarks Time a Sprint
Model speed, measured in real sessions
118,896 real agent requests, timed end to end, by model, week and hour
60 tokens a second across 64,675 requests, first output in 8.1 seconds
How One Request Is Timed
Anchor record to last block, tool time out
Benchmark vs Session
One prompt, decode only, after first token
Whole request, thinking and wait included
Where the Minutes Go
Wait, think, stream, then the tools run
Fast Mode Is a Purchase
2.5x decode speed moves a session far less than 2.5x. Buy it for long generation with few tool calls, not for waiting.
Choose on the Current Week
Opus 5 gained 11 percent in six weeks; Codex lost 20 percent in seven days. Speed drifts. Measure your own sessions.
Build Agents You Can Measure
We instrument every fleet we build from day one
Share This Article
Spread the knowledge