OpenAI AI Gateway Benchmarks
AI Gateway Benchmarks - OpenAI
Benchmark AI gateway latency and token throughput, measured against a direct-to-OpenAI baseline. Inspired by this benchmark from Ronny Badilla.
Powered byProvider Leaderboard
"OpenAI (Direct)" is a no-gateway control, not a competing gateway — it isolates how much latency each gateway adds on top of the underlying model provider.
Provider VarianceComposite Score
"OpenAI (Direct)" is a no-gateway control, not a competing gateway.
Delta vs. the OpenAI (Direct)'s composite score. Positive is better than baseline; negative is worse.
Performance Over Time
Composite Score
Detailed Metrics
Provider | Score | Cold E2E (med) | Warm TTFT (med) | Tokens/sec (med) | DNS (med) | TCP (med) | TLS (med) | Success |
|---|---|---|---|---|---|---|---|---|
| OpenRouter | 91.2 | 470ms | 357ms | 72 | 0.79ms | 0.92ms | 3.33ms | 100% |
| OpenAI (Direct)Baseline | 90.5 | 383ms | 344ms | 75 | 0.83ms | 0.96ms | 2.71ms | 100% |
| Pydantic AI Gateway | 90.1 | 481ms | 543ms | 67 | 0.79ms | 1.60ms | 4.51ms | 100% |
| Cloudflare AI Gateway | 89.9 | 476ms | 382ms | 69 | 0.78ms | 0.88ms | 5.14ms | 100% |
| Vercel AI Gateway | 89.6 | 521ms | 441ms | 59 | 0.85ms | 0.81ms | 5.17ms | 100% |
| Neon | 89.3 | 698ms | 503ms | 59 | 0.79ms | 19.51ms | 40.12ms | 100% |
| Concentrate AI | 87.0 | 827ms | 627ms | 51 | 0.75ms | 0.84ms | 5.22ms | 100% |
| LLMgateway | 85.8 | 1027ms | 996ms | 57 | 0.73ms | 1.54ms | 5.11ms | 100% |
| ngrok AI Gateway | 84.8 | 1364ms | 851ms | 41 | 0.74ms | 19.28ms | 21.48ms | 100% |
Want to see a gateway added?
Methodology
Every run executes on a GitHub Actions runner hosted by Namespace, physically located in Northern Virginia, US. Since results are a property of the network they're measured from, treat rankings as relative to that vantage point rather than a universal number — see Limitations in the full methodology.
What We Measure
Every gateway is hit directly with the same prompt and model (GPT-5.4 Mini), addressed the way each API expects it to be addressed — no gateway is proxied through another. Each request is either cold (a brand-new TCP+TLS connection, opened from scratch) or warm (a second request reusing an already-open keep-alive connection).
Cold requests are broken into DNS, TCP, and TLS phases (real socket timestamps, not estimates), plus time to first response byte and first streamed token. Every request also records output tokens/sec and success/failure.
This family's no-gateway control is a direct call to OpenAI's own API, not a competing participant — it isolates how much latency each gateway adds on top of the underlying model provider. See the other target-model families on the AI Gateway Benchmarks overview. Full methodology, including how "cold" and "warm" are defined and their limitations, is documented in the public benchmarks repo.
How We Score
The Composite Score combines cold end-to-end latency and warm time-to-first-token — the short-lived-process case and the steady-state case — with generation throughput, all multiplied by success rate.
- • Cold E2E median: 30%
- • Warm TTFT median: 30%
- • Cold E2E P95: 15%
- • Warm TTFT P95: 15%
- • Tokens/sec: 10%