Skip to content
Multigrid

Reading Time and Token Time Estimator

Turn an output size and your own measured token rate into a wall-clock estimate, and compare it against how fast a person reads.

Wall clock, first byte to last
14.0 s

700 ms waiting, then 13.3 s of generation at 45 tok/s.

Output tokens
≈ 600
Words
450
Time to first token
700 ms
Generation time
13.3 s
Total wall clock
14.0 s
Reading time at 240 wpm
1m 53s
Rate needed to outrun the reader
5.3 tok/s
Reader is never left waiting
—
What this assumes: a constant token rate. Real streams are not constant: the rate falls as the context grows, varies with load, and stalls for reasoning models that think before they emit. The token rate and TTFT are yours — this page ships no provider numbers, because a throughput figure quoted here would be wrong for your region, your context length and your Tuesday afternoon. Measure them from a real call: TTFT is the time to the first content chunk, and the rate is output tokens ÷ (total time − TTFT). The reading comparison assumes the reader starts at the first token and reads continuously. Words-per-token is a ratio you set; the token figure in the paste mode is an estimate. Estimated, not tokenized. A real count needs the model's vocabulary; the authoritative number is usage.prompt_tokens on the response.

The number that decides whether streaming is worth it

The interesting comparison is not total time, it is the last two rows. If the model emits words faster than a person reads them, the perceived wait is just the time to first token: the reader starts, and the text is always already there. If it emits slower, the reader catches up and then sits watching a cursor, and the felt duration is the whole generation however nicely it animates. That crossover — around 5 tok/s for English at 240 words per minute — is why streaming transforms a chat UI and does nothing at all for a summary nobody reads until it finishes.

It also tells you which optimisation to buy. Below the crossover, the only thing that helps is a faster rate or a shorter answer, and a shorter answer is nearly always the cheaper change: cutting the output in half halves both the wait and the output bill, while doubling throughput usually means a different model. Above the crossover, rate improvements are invisible to the user and TTFT is the entire experience, so the money goes on the prompt, the cache and the first hop.

What this leaves out: network time before the request reaches the provider, queueing under load, any retry, and the tool calls in an agent loop — each of which is a whole round trip with its own TTFT. For an agent, run this once per model turn and add them up. That total is the one users actually feel.

The reasoning behind this

Related tools

Reading Time and Token Time Estimator · Multigrid