Published

Latency Is Bimodal: why one measurement window lies

Ejentic Research Desk

3 November 2026

Abstract

A speech provider measured at 9.9s, 3.2s, 3.4s and 42.7s in one window, then 3.2s, 3.0s and 3.0s twenty minutes later. The first window produced a confident conclusion that the second window contradicted. Neither was wrong; the sample was too small to see the shape.

What we measured

Text-to-speech from a provider on a free tier, sampled directly from the production box, same payload, same credentials.

window 1:  9.87s   3.16s   3.39s   42.7s
window 2:  3.24s   3.01s   2.99s

A decision taken on window 1 alone would have concluded the provider was too slow to use. A decision taken on window 2 alone would have concluded it was fine. Both conclusions were supported by their data.

The actual shape

Around three seconds when the tier is healthy, ten to forty seconds when it is busy, and the busy windows last at least an hour. So the honest description is not a latency figure, it is a latency distribution with a condition attached.

What we changed

Not the threshold. The design. Provider order became configuration rather than a hard-coded guess, the timeout became configurable, and the slow provider stayed wired as a failover rather than being promoted or discarded on the strength of one afternoon.

The lesson for evaluation

Tail latency is a different quantity from typical latency and needs a different sample. Three requests tell you something happened. They do not tell you what usually happens, and they are especially bad at revealing a mode you have not landed in yet.

Sample across time, not just across requests.

BibTeX

@article{desk2026latency,
  author    = {Ejentic Research Desk},
  title     = {Latency Is Bimodal: why one measurement window lies},
  year      = {2026}
}

2026

Deleting the ROI Calculator

A plausible number is worse than no number. A visitor cannot tell the difference, which is the problem, not the defence.

2026

SilentProbe: Measuring Silent Failure in Production APIs Used as Agent Tools

Read this before you let an agent call anything a customer will see the output of. The failure mode is not a crash, it is an API returning 200 with a body that means "I did not understand you". There is no exception to catch and no status code to branch on. The result we quote most often is the last one: the fix was one line of schema, not a better model.