How Tailscale built a model router on Vercel's AI Gateway

Tailscale is known for connecting laptops, servers, cloud instances, and personal devices into a single private network, the so-called tailnet. What Vercel's changelog documents is how the company took that same concept and applied it to AI models, through the Aperture product, built on AI Gateway and Vercel Sandbox.

Aperture's central idea is to stop distributing individual provider API keys to each employee, agent, or tool. Instead, access to models flows through network identity itself: add someone to the tailnet and they can use approved models right away; remove them, and access disappears. Remy Guercio, Aperture's product lead, sums up the tailnet concept as "basically a VPC that can span any cloud, on-prem, your house, and your phone."

For the Brazilian developer building an AI layer for production, what's interesting here isn't Tailscale itself, but the architecture pattern the case exposes: a model router with identity-based access control, transparent cost, and isolated agent execution. It's worth understanding what Vercel delivers out of the box and where you still need to get your hands dirty.

Why routing models is harder than it looks

Tailscale is an infrastructure company, so building the routing layer in-house was the obvious first option. They gave up on it after looking closely at the engineering effort.

The point that usually trips up whoever builds this kind of layer is assuming provider endpoints are interchangeable. "You'd think all the endpoints are the same," Remy says. "They're not." Each provider has its own quirks in format, authentication, streaming, and error semantics that need to be normalized.

David Carney, cofounder and chief strategy officer, points to a concrete detail that illustrates well the invisible work of a gateway:

There are a lot of things the big providers don't do, and it amazes me that the gateway does, like simply putting the cost in the response. We initially built these systems for customers ourselves, and the complexity is insane.

-- David Carney, cofounder of Tailscale

Returning cost on every request seems trivial, but it requires keeping pricing tables up to date per provider and per model, something that changes constantly. AI Gateway returns cost and usage on every call, which lets Aperture show spend to customers without Tailscale maintaining that registry.

Zero data retention as a requirement, not a feature

Tailscale's customers care about data protection, so zero data retention (ZDR) was a baseline requirement. AI Gateway helps on two fronts: the gateway itself doesn't retain data, and it's possible to configure ZDR globally or per request, with the zeroDataRetention flag, which automatically restricts routing to compatible providers.

This is the kind of logic nobody wants to maintain by hand. "This whole ZDR thing is a moving target, which models have zero data retention and which don't," David says. "But we don't have to write any of that logic, because it's all handled for us." In practice, delegating this routing decision means that when a provider changes its policy, the system's behavior follows along without a deploy.

Another relevant business point: AI Gateway doesn't apply markup on token cost for any provider or model, including when Tailscale's customers bring their own keys. Whoever consumes Aperture pays the same rate they'd pay going directly to the provider.

Isolated agents on the tailnet with Vercel Sandbox

The part that raises the security bar the most is agent execution. An agent that reads private data, acts on the text it reads, and also reaches the public internet sets up the problem the source calls the "lethal trifecta" (the lethal trifecta). The correct mitigation is an isolated sandbox, with identity and access control built in.

The flow Aperture runs for agents, as described in the source, is lean and worth using as a design reference:

1. A sandbox spins up and connects to Aperture.
2. Aperture connects to AI Gateway.
3. Tailscale validates identity.
4. The agent does its work.
5. The sandbox is shut down.

The critical detail: no key is ever handed to the agent. Authentication happens at the edge, by network identity, and the secret never reaches the code the agent runs. This design drastically reduces the credential-leak surface, a recurring problem in agent orchestration.

Tailscale even had a full sandbox implementation with another provider before switching. The reason for the migration was about focus, not just technical:

We tried many different sandbox providers and even had a full implementation with one of them, and we still switched to Vercel. It was surprisingly easy to migrate everything.

-- Remy Guercio, Aperture product lead at Tailscale

Remy's justification is the one that matters to whoever's deciding on a stack: "We wanted to focus on network identity, not sandbox security boundaries." It's the classic build vs. buy applied to AI, where the product's differentiator is identity, not runtime isolation.

The internal migration: cutover with no downtime

Tailscale's internal AI usage had grown the way almost every company's does: a mix of direct provider accounts and cloud endpoints, accumulated one team at a time. Internally, these requests already went through Aperture, but behind the proxy, each provider was still being called directly.

The engineering team built a switch inside Aperture pointing requests to AI Gateway instead of individual APIs. Since Aperture remained the endpoint being called and all models already in use were in the gateway's catalog, the cutover happened without downtime. "We managed to migrate the entire company to AI Gateway in seconds, and nobody noticed," Remy says.

This is the architecture point that's worth copying even without using Vercel: if your application has always talked to an internal proxy instead of talking directly to providers, swapping what's behind the proxy becomes a configuration decision. The abstraction pays for itself on migration day.

What's worth taking away (and where it doesn't hold)

The concept of "time to first token" shows up with two meanings in the case, and both are useful. The technical one is the classic: how long it takes to load the cache, generate the response, and return it to the user, in other words, latency. The product one, which David likes to use, is the time from user sign-up to the first model call, the real time-to-value. It's worth separating the two when defining a success metric for an AI feature.

David's final advice is direct: focus on the product delivered to the customer, not the infrastructure to run it. "A lot of people want to build their own router. And look at us, we tried too. But you don't need to build another router."

A reading caveat is in order: the case is published by Vercel itself, so the numbers and praise come from whoever sells the product, without independent benchmarking. Tying yourself to AI Gateway and Sandbox is a real vendor dependency, and the argument "don't build your own router" suits whoever sells routers. For small teams with few providers and no ZDR or agent-execution requirement, a thin proprietary layer might be cheaper than adopting an entire platform. The pattern that matters here, a single internal proxy, per-request cost, edge identity, and a keyless ephemeral sandbox, is replicable regardless of the vendor chosen.