---
title: "Edge network"
description: "A pirouter request enters at the edge node nearest to you and goes straight to the provider from there. This page covers the path a request takes, what runs at the edge, how a failed deployment is replaced, the dedicated relay for mainland China upstreams, and why request content never touches disk."
canonical: "https://pirouter.ai/docs/edge-network"
last-updated: "2026-10-17"
lang: "en"
source: "content/docs/en/(start)/edge-network.mdx"
---

# Edge network

A pirouter request enters at the edge node nearest to you and goes straight to the provider from there. This page covers the path a request takes, what runs at the edge, how a failed deployment is replaced, the dedicated relay for mainland China upstreams, and why request content never touches disk.

Your call enters at the nearest edge node and goes straight to the provider from there. No detour through a central region.

![Requests enter at the edge node nearest to them, where TLS, authentication, routing and metering run, and go straight to the provider with no detour through a central region](https://pirouter.ai/docs/diagrams/edge-network.en.svg)

## At the edge

TLS terminates at the nearest edge node. Authentication, rate limits and routing run right there, so the decision about which provider serves your request is made close to you.

- **Authenticate**: Your API key is checked at the edge node.
- **Route**: A provider is chosen for the model and your routing settings.
- **Meter**: Tokens and cost are measured as the response streams back.

## Straight to the provider, with automatic failover

From the edge node the request goes directly to the chosen provider. Each model is served by more than one deployment where possible. When the chosen deployment fails before the first byte of the response, the gateway moves to the next deployment of the same model, then to the next model in the request's `models`.

A failure moves on when the upstream returns `429`, `500`, `502` or `503`, when the connection fails, and when the upstream refuses the platform's own credentials (`401`, `403`). A `504` or any other `4xx` does not. The full rules are in [Automatic retry on another provider](https://pirouter.ai/docs/routing.md#automatic-retry-on-another-provider).

A request is tried at most 5 times, counted across all models.

You pay only for the attempt that answered. An attempt that failed and was taken over by the next one is not billed. See [billing for fallbacks](https://pirouter.ai/docs/fallbacks.md#billing).

## Upstreams in mainland China

Some upstreams in mainland China are reached through a dedicated relay in Japan East. The relay forwards the encrypted traffic by the host name in the TLS handshake and never decrypts it.

Median time to first byte for large-context requests (about 80,000 input tokens, cache hit, streaming):

| Time window (UTC+8)      | Via the relay | Direct |
| ------------------------ | ------------- | ------ |
| Night, from 01:47        | **2.68 s**    | 3.76 s |
| Evening, from 18:43      | **3.20 s**    | 5.25 s |
| Evening peak, from 20:05 | **3.26 s**    | 5.69 s |

Small requests (80 input tokens, from 02:02): **1.25 s** via the relay, 1.43 s direct.

Measured on 2026-10-10 and 10-11 against the one upstream that goes through the relay. The figures cover the outbound leg from the gateway to the upstream, not the full round trip from your client.

## No content on disk

Prompts and completions pass through the pirouter gateway in memory only. The gateway never writes them to disk. For the metadata pirouter does record, see [Data policy & ZDR](https://pirouter.ai/docs/data-policy.md).

## Next steps

- [Data policy & ZDR](https://pirouter.ai/docs/data-policy.md): What pirouter stores, each provider's data policy, and what you control.
- [Provider routing](https://pirouter.ai/docs/routing.md): Control which providers serve your requests.
- [Model fallbacks](https://pirouter.ai/docs/fallbacks.md): Switch to another model automatically when the one you asked for is unavailable.