We ran real, authenticated streaming completions against OpenAI's flagship gpt-5.6-sol — with reasoning effort set to "low" — from Amsterdam, San Francisco, Montreal, Singapore and Tokyo, 20 per city, parsing the token stream itself and timestamping the moment the first visible token arrived.
Independent measurement by LatencyRadar. Not affiliated with OpenAI. · Last updated August 2026.
Every single completion succeeded, and the first token typically arrived in 0.8–1.1 seconds: Tokyo was fastest at 824 ms, Singapore slowest at 1096 ms — only a 1.3× spread. That's because gpt-5.6-sol thinks before it speaks: OpenAI holds the response until the first token is ready — our stream timestamps show the headers and the first visible token arriving within 23–54 ms of each other — and subtracting each city's measured network floor leaves a fairly constant 0.66–0.86 seconds of OpenAI-side time everywhere, which dwarfs the network. The number to plan for is the slow case: the slowest first tokens we observed took 2.0 to 3.4 seconds, and they didn't follow geography.
Tokyo came out fastest at 824 ms, followed by Montreal (832 ms), San Francisco (865 ms), Amsterdam (878 ms) and Singapore (1096 ms). Compare that to our unauthenticated probe of the same API, where regions spread 3.4× apart (70–235 ms): once the model's roughly constant thinking time is added on top, the spread compresses to 1.3×. Your region still sets a floor — Singapore pays real physics on every call — but for a flagship reasoning model it's far from the dominant term.
Marker size and color reflect p95 latency by region.
These timings come from parsing the token stream itself, not from transport phases alone. For OpenAI the stream only opens when the first token is ready: headers and first visible token arrived within 23–54 ms of each other in every city, so nearly all of the 0.8–1.1 second wait is queueing plus the model's low-effort reasoning before the stream opens. Subtract the pure network floor we measured separately (70–235 ms by city) and the model-side share comes out at a fairly constant 0.66–0.86 s per region. Connection setup and TLS stay under ~25 ms everywhere — Cloudflare's edge.
DNS resolution is measured once per region before the requests run, so it sits outside these bars: Amsterdam 3 ms · San Francisco 52 ms · Montreal 15 ms · Singapore 4 ms · Tokyo 3 ms
Phases come from the typical (median) request, so they add up to its total.
Both IPs our probes reached belong to Cloudflare and TLS terminates locally. For streaming APIs our delivery verdict is computed from stream-open times rather than the inference-dominated totals — though note that for OpenAI, stream-open itself includes the model's thinking, since the response is held until the first token; read the 292 ms spread as an upper bound on the network's share. What's clearer is that the slowest requests didn't follow geography: Amsterdam's and San Francisco's slowest first tokens (~3.2 s) were worse than Tokyo's and Montreal's, despite shorter routes — which suggests the variance sits beyond the network path, though a single run can't pin down where.
Regions resolved to 2 different IP addresses but latency varies by 292ms, so some regions appear to be served from a distant location.
Start with the headline number for each city. Open the technical breakdown only if you want to see where that time is coming from.
20 requests · 100% successful
20 requests · 100% successful
20 requests · 100% successful
20 requests · 100% successful
20 requests · 100% successful
In a chat UI, perceived speed is the time until the first word appears. The typical numbers here are workable — around a second everywhere — but the slowest completions we observed took 2.0 to 3.4 seconds to produce a single token, and slow cases showed up in every city we tested. A closer region doesn't appear to fix it, because the slow cases didn't follow geography. What you can do is design for it: stream tokens as they arrive, show the request was accepted immediately, and treat a multi-second first token as normal rather than as a timeout.
We ran real, authenticated streaming completions — POST /v1/chat/completions with stream: true — against OpenAI's gpt-5.6-sol from servers in Amsterdam, San Francisco, Montreal, Singapore and Tokyo, 20 per city, all with the same fixed prompt. We parsed the SSE token stream and timestamped each event as it decoded: when the stream opened, when the first visible token arrived (the headline number on this page), and when the response completed — alongside the usual DNS, connect and TLS phases. OpenAI holds the response headers until the first visible token, and the timestamps confirm it: the two events landed within 23–54 ms of each other in every city. We also probed the same hostname unauthenticated to measure the pure network floor the copy cites.
Run a free speed test from multiple cities and find out where your users are waiting — no setup, no account required.
Takes about 30 seconds.