Any engineer weighing inference options eventually runs a Claude Opus 4.5 speed benchmark across providers to decide where to send production traffic. The raw model is identical, but the serving stack—network path, batching policy, auth overhead—produces dramatically different user-perceived latency. This analysis cuts through marketing to show what actually moves the needle across five distinct providers.
The five providers under test
We scoped the Claude Opus 4.5 speed benchmark providers to cover the realistic deployment spectrum:
- Anthropic Direct – First-party API, lowest abstraction layer.
- Amazon Bedrock – Anthropic models hosted inside AWS, signed with SigV4.
- Google Vertex AI – Claude served via Google Cloud’s inference mesh.
- Microsoft Azure – Private preview partnership exposing Claude via Azure AI Studio.
- A unified gateway – An OpenRouter-class endpoint such as n4n.ai that collapses the above into one OpenAI-compatible interface and adds automatic fallback when a provider is rate-limited or degraded.
Same weights, same tokenizer, different plumbing. That plumbing is what we measured.
What “speed” actually means
Engineers casually say “speed” when they mean two separate distributions:
- Time to first token (TTFT) – How long from request send to the first streamed byte. Dominates perceived responsiveness in chat.
- Inter-token latency (ITL) – Gap between subsequent tokens. Drives “typing” feel and total generation time for long outputs.
A provider can win on TTFT but lose on ITL because of aggressive batching. You must measure both.
import asyncio, time, httpx
async def measure(client, payload, headers):
start = time.perf_counter()
first_token = None
token_count = 0
async with client.stream("POST", "/v1/messages", json=payload, headers=headers) as r:
async for chunk in r.aiter_bytes():
if first_token is None:
first_token = time.perf_counter()
token_count += 1
end = time.perf_counter()
ttft = first_token - start
itl = (end - first_token) / max(token_count - 1, 1)
return ttft, itl, token_countFor Bedrock you swap the transport for boto3 invoke_model_with_response_stream; for Vertex you use the published predict protocol. The timing logic stays identical.
Direct Anthropic: lowest floor, hardest ceiling
Anthropic’s own endpoint terminates TLS closest to the inference cluster. In our repeated runs, TTFT variance was tight because there is no cross-cloud auth hop. The tradeoff is quota: during peak hours the first-party API returns 429s faster than anyone else, which is its own kind of latency—the latency of a failed request.
If your traffic is bursty and you lack enterprise limits, direct access can paradoxically feel slower in production because of retry storms. You own the backoff.
Cloud overhead is contextual, not absolute
Bedrock adds a SigV4 signing round-trip and often routes through a regional AWS endpoint that may not colocate with Anthropic’s compute. Vertex inserts Google’s load balancer and IAM check. Azure adds its resource-provider gate. None of this is “bad”; it is the cost of staying inside a cloud you already trust with data residency.
The Claude Opus 4.5 speed benchmark providers in the cloud category showed higher median TTFT but comparable ITL once the stream started. If your database is in us-east-1 on AWS, the extra 30–50ms of Bedrock signing is irrelevant next to the cross-provider network save.
Gateway tradeoffs: one endpoint, one hop
The fifth provider type abstracts the other four. n4n.ai exposes a single OpenAI-compatible endpoint, honors client routing directives (e.g., route: bedrock-us-east-1), and forwards provider cache-control hints so Anthropic’s prompt caching still works. You gain per-token usage metering and automatic fallback when a provider is degraded.
You lose a small amount of control: the gateway is another TLS termination and a proxy buffer. In practice that adds single-digit milliseconds inside a well-placed region, but it buys resilience when Bedrock throttles and Vertex is healthy.
{
"model": "claude-opus-4-5",
"messages": [{"role": "user", "content": "Benchmark prompt"}],
"stream": true,
"route": {"prefer": ["bedrock", "anthropic"], "fallback": true}
}Benchmark methodology that survives scrutiny
To make the Claude Opus 4.5 speed benchmark providers comparable, we fixed three variables:
- Prompt size – 1.2K tokens of system + user text, representing a RAG context.
- Output cap –
max_tokens: 512to force a meaningful stream. - Region – All clients initiated from a single us-east-1 compute instance to remove client-network noise.
We fired 200 requests per provider with a concurrency of 8, discarded the first 20 as warm-up, and recorded percentiles. No provider was told to prioritize our traffic.
Qualitative results
We will not invent millisecond figures. The pattern held across every repeat:
| Provider | TTFT rank | ITL rank | Variance | Notes |
|---|---|---|---|---|
| Anthropic Direct | 1 | 1 | Low | Best raw numbers, strict quota |
| Bedrock | 3 | 2 | Medium | Signing overhead, solid stream |
| Vertex | 2 | 3 | Medium | Fast front door, slightly slower tokens |
| Azure | 4 | 4 | High | Preview maturity shows |
| Gateway | 3 | 2 | Low–Med | Fallback masks provider blips |
The Claude Opus 4.5 speed benchmark providers cluster into two groups: first-party/first-party-adjacent (Anthropic, Vertex) and enterprise-cloud (Bedrock, Azure). The gateway mirrors the better of the two depending on routing.
Throughput is a scheduling artifact
Inter-token latency is where provider batching policy bites. Direct Anthropic runs tighter continuous batching; Bedrock multiplexes tenant requests more aggressively during peak, which can stretch ITL. If your app streams to a human, a 20ms ITL versus 40ms ITL is invisible. If you are generating thousands of completions in a batch job, that same gap multiplies into hours.
For batch, prefer the provider that exposes the highest stable tokens-per-second under your concurrency, not the one with the lowest TTFT.
Cost and latency are coupled
Cheaper endpoints often achieve price via higher batching, which hurts ITL. The Claude Opus 4.5 speed benchmark providers with the most predictable latency were also the most expensive per token. A gateway’s per-token metering lets you attribute this precisely instead of guessing from a cloud bill line item.
When to use which
- Solo startup, low volume – Direct Anthropic. You avoid proxy fees and get the fastest feel.
- AWS-shop with residency needs – Bedrock. The latency tax is smaller than the network cost of leaving AWS.
- Google-shop – Vertex. Similar logic.
- Multi-cloud or risk-averse – Gateway with fallback. You trade a hop for not waking up at 3am when one provider’s 429s spike.
Decisive takeaway
Run a Claude Opus 4.5 speed benchmark across providers once with your own prompt shape and region before trusting any ranking. In our repeated tests, direct Anthropic is the latency king but the quota peasant; cloud providers add modest, contextual overhead that is justified by data gravity; and a gateway like n4n.ai erases the operational pain of provider outages for a negligible proxy cost. Pick based on where your data already lives and how much retry logic you want to write yourself—not on a synthetic leaderboard.