Every major cloud provider sells a Singapore region, and if you measure the network you will conclude they all deliver one. From a server in Singapore, the connection to Amazon's Singapore endpoint completes in about 7 milliseconds. To OpenAI's API, about 6. To Anthropic's, about 2.
Those numbers are real, and they are close to useless, because they measure the wrong thing. What they tell you is where the front door is. They tell you nothing about where the work happens.
Two clocks, not one
When your code calls an HTTPS API, there are several separable delays and most tooling reports only the total. Two of them answer different questions:
- Time to connect — how long the TCP handshake takes. This is a measure of distance to whatever machine accepted the connection. With modern content delivery networks, that machine is almost always in your city.
- Time to first byte — how long until the first byte of the response arrives. Something had to actually produce that response. If it was produced far away, this is where the distance shows up.
Measured from a server in Singapore, five runs each, median reported:
| Endpoint | Connect | First byte | Gap |
|---|---|---|---|
| S3, ap-southeast-1 (Singapore) | 6.9 ms | 34.3 ms | 5.6 ms |
| DigitalOcean Spaces, sgp1 | 5.3 ms | 33.1 ms | 5.1 ms |
| Azure Blob, Southeast Asia | 5.0 ms | 52.7 ms | 6.1 ms |
| GitHub API | 5.4 ms | 38.1 ms | 8.4 ms |
| OpenAI API | 6.2 ms | 237.1 ms | 194.7 ms |
| Anthropic API | 2.3 ms | 278.0 ms | 250.9 ms |
| S3, us-east-1 (Virginia) | 262.7 ms | 788.8 ms | 261.5 ms |
Every endpoint in that table accepts your connection in single-digit milliseconds. Two of them then take a quarter of a second to say anything.
The control at the bottom is the argument
A gap of 250 ms could be a distant server or a slow one. Time to first byte contains both, and from the outside they look identical. So the table includes something with a known answer.
The last row is Amazon's Virginia endpoint — a genuinely distant machine, deliberately not fronted by an edge that would hide the distance. Its connect time alone is 262.7 ms. That is what a transpacific round trip costs, measured rather than estimated.
Anthropic's 250.9 ms gap and OpenAI's 194.7 ms sit squarely in that range. We can't prove the entire gap is network propagation, since a busy server could add its own delay. But the delay is the size of a round trip to North America, and it showed up on a request that did almost no work.
These were unauthenticated calls that came back 401. Nothing generated a single token. Whatever produced that refusal was far away, and any real inference request pays the same trip before the model starts thinking.
Why the connection is local and the answer is not
Both APIs sit behind a content delivery network with an edge in Singapore. Your packets reach that edge in a couple of milliseconds, complete a TLS handshake there, and then the edge opens its own connection to an origin somewhere else and waits.
This is a good architecture and it is doing what it should. The handshake is the expensive part of starting a connection, and moving it close to the user is a real improvement. But this creates an illusion. Any simple network tool like ping, traceroute, or a connect-time test will report a local service, because a local service is what answered the initial handshake.
Google's endpoint shows the other side of this and is worth flagging so you do not misread it. Its gap is 9.7 ms, which looks like local inference. It is not evidence of that: our request was refused with a 403, and a refusal can be issued at the edge without consulting anything. A fast rejection tells you where the bouncer is, not where the kitchen is.
What this costs you in practice
A quarter of a second is not a catastrophe on its own. It becomes one through multiplication.
Agent loops pay it per step. A chain that calls a model, reads a tool result, calls again and refines is paying the round trip on every hop. Ten steps is 2.5 seconds of pure travel before any model has produced a single token. This is the most common reason a workflow that feels fine in testing becomes sluggish in production, a delay that's invisible to any latency dashboard that only samples connect time.
It is the floor under your own response time. If you serve users in ASEAN from infrastructure in ASEAN and call a US-hosted model, you cannot be faster than that round trip. No amount of local optimisation moves it.
And streaming hides it from you specifically. When responses stream, users perceive the time to the first visible token, which sits after the round trip. It feels acceptable to a person watching text appear. It is still 250 ms of dead time on every call you make, and it is fully visible in your own bill for compute sitting idle.
The practical response is not to stop using these APIs, but to stop paying the round-trip cost so often. Batch what can be batched, cache aggressively, and be suspicious of any design that makes several sequential model calls where one would do. Our guide on latency against bandwidth works through why a fatter connection does nothing for a round trip, which is the same arithmetic seen from the other end.
How to measure your own
One command, no tooling to install:
curl -s -o /dev/null -w 'connect %{time_connect} ttfb %{time_starttransfer}\n' https://api.example.com/Run it five times and take the middle value. A small connect time with a large time-to-first-byte points to a local front door and distant work. If both numbers are small, the work is happening nearby. If both are large, you aren't even reaching a local edge.
The limits
Time to first byte is not a distance measurement. It is distance plus whatever the server did, and this guide claims only that a gap of that size is consistent with a transpacific origin — supported by the Virginia control rather than asserted.
We have measured this machine from other angles before: what we actually run on it and how much it sends, both from the same vantage point as this one.
One vantage point, one moment. Measured from a single Singapore server on 19 August 2026; a different network in the same city may route differently, and providers move capacity. Our own origin, in the same city, shows an 18.1 ms gap that is application work rather than travel — a useful floor for what "the work happened locally" looks like.
We tested unauthenticated endpoints on purpose, so no credentials were sent and nothing was billed. This means the figures exclude model computation time. A real completion will be slower, not faster; the round trip measured here is the fixed cost you pay before any useful work begins.
View author profile → · Editorial policy
