The problem is that most benchmarks are run from a single server in Northern Virginia. "Fast" is a meaningless word if you don't specify from where. To fix this, I built a provider-neutral tracker that actually measures latency from four distinct global regions (Germany, US Central, Tokyo, and São Paulo) instead of just scraping marketing claims.
The Technical Breakdown #
I didn't want a bloated backend that would wake me up at 3 AM, so the architecture is intentionally boring. I used a Python prober (standard library only) to track the actual handshake: DNS → TCP → TLS → TTFB.
The system separates "Edge Latency" (the network path) from "TTFT" (the model queue). This is crucial because if your app is slow, you need to know if it's a routing nightmare or if the provider's GPU cluster is just choking. The data dumps into SQLite and generates static pages via Cloudflare Pages on a schedule.
Making it "Agent-Native" #
Since we're all obsessed with LLM agents, I figured why make a dashboard that only humans can read? I built this to be consumed by machines first.
To avoid the nightmare of agents trying to scrape messy HTML, I implemented a few specific hooks:
MCP Server: A real Model Context Protocol server at/mcp
with aget_ai_api_latency
tool.A clean map for models to understand the site structure without hallucinating.llms.txt
:Markdown Negotiation: If you requesttext/markdown
, you get clean text instead of a DOM soup.
It's a practical tutorial in how to build for the "Answer Engine" era. By stripping out the junk, the site actually hit a Lighthouse 100 score, which is a rare win in a world of heavy JavaScript frameworks.
If you're doing a deep dive into which provider to use for a global deployment, don't guess based on a tweet. Use actual regional data.
Next LG ThinQ Terms: A Deep Dive into Data Rights →