A model can start a stream quickly and still take several seconds to show a useful answer. It can also produce tokens quickly after a long initial wait. When an LLM API feels slow, identify which part of the request is slow before comparing models or changing your application.
AtmoRouter exposes several measurements in Usage logs. They describe different parts of a request and should not be treated as interchangeable speed scores.
Duration is the full request time
Duration measures the request from start to completion. It includes waiting and the time spent receiving the generated output. The dashboard displays it in milliseconds: 1,000 ms equals one second.
For an application that waits for a complete answer before displaying anything, duration is an important user-visible measurement. For an application that streams output, it does not tell you when the first readable sentence became available.
First byte is not always the first answer
The dashboard's first-byte measurement records when the response stream starts arriving. An early chunk can contain metadata, a keepalive or other stream content rather than answer text.
First-text time records the first answer text, excluding reasoning. A large gap between first byte and first text can explain why the client appears idle even though the HTTP stream has already started. Neither field alone proves that a particular gateway or model is the cause of a delay.
For precise definitions and unavailable measurements, see Usage & request timing. A dash in a timing field means the measurement is unavailable; it does not mean the request completed in zero milliseconds.
What effective tokens per second means
AtmoRouter's effective throughput uses the output token count divided by the full request duration in seconds:
texteffective tokens/second = output tokens / (duration in milliseconds / 1000)For example, an illustrative request reporting 600 output tokens and a duration of 12,000 ms has an effective throughput of 50 tokens per second. This is an arithmetic example, not an AtmoRouter model benchmark.
The value includes the effect of waiting. Reported output counts may include reasoning tokens, so the displayed throughput is not necessarily the rate of visible words appearing in the editor. It is also not a generation-only speed measurement calculated after the first token.
Compare requests under similar conditions
Keep the model, input size, requested output length and reasoning settings comparable. Run multiple samples rather than deciding from one unusually fast or slow response. Compare the middle of the distribution and the slower cases as well as a simple average.
Record the timestamp and model ID with each observation. A much longer answer naturally changes total duration, while a larger prompt can affect the time spent before output begins. Tool execution outside the model request can add delay that a gateway request log does not measure.
For coding agents, compare an entire task as well. A model that completes a task with fewer unsuccessful turns may give a better experience even when its per-request speed looks less impressive.
A practical debugging sequence
Start with a short text-only request. Check whether the delay appears before the first byte, between first byte and first text, or during the remaining output. Then add the original prompt length, tools and agent settings back one at a time.
If the issue occurs in an IDE, repeat a comparable request with the API quickstart. This helps distinguish client setup from request behavior. Do not add aggressive retries to a request that is already producing a valid stream.
Check Status for measured service health and Errors & retries for failed requests. For cost measurements alongside performance, read prompt caching for AI agents.