Vercel's AI Gateway Can Now Pin Your AI Requests to the US or EU

What happened

Vercel’s AI Gateway, the proxy service that routes an app’s AI model calls to whichever provider is configured, now supports regional inference. You can pin a request to run in the US or the EU instead of letting the Gateway route it to whichever server answers fastest.

You set this with a new inferenceRegion option when you call a model through Vercel’s AI SDK, the code library most Vercel-hosted AI apps already use to talk to models:

import { streamText } from 'ai';

const result = streamText({
  model: 'moonshotai/kimi-k3',
  prompt: 'Summarize this internal document.',
  providerOptions: {
    gateway: {
      inferenceRegion: { scope: 'zone', geoRegion: 'us' },
    },
  },
});

streamText is the function that actually sends the prompt to the model and streams the answer back. That geoRegion: 'us' line is the whole feature: it tells the Gateway “only run this on a server located in the US.” Every response also reports back which region actually served it, so you can confirm the pin held instead of taking it on faith.

Why it matters

“Data residency” is the requirement, common in healthcare, finance, and any contract with an EU customer, that certain data must be processed and stored in a specific country or region, not wherever a server happens to be free. Until now, meeting that requirement through an AI Gateway meant configuring routing separately for every model provider, with no simple way to confirm where a request actually ran once you’d set it up.

Regional inference replaces that patchwork with one field that behaves the same across providers. If you don’t set inferenceRegion, nothing changes: requests still route globally with no residency guarantee, exactly as before. The feature is opt-in.

There’s a real cost and a real failure mode attached. Vercel says pinning a region “can cost more,” with the provider setting a regional rate typically around 10% above standard and no extra markup from the Gateway itself. And if no provider can serve your chosen model in the region you picked, the request fails outright rather than quietly falling back to a server somewhere else. That’s the safer design, since a silent fallback would defeat the point of pinning in the first place, but it means a region pin can break a working feature if you didn’t check model availability first.

Who should care

This matters most if you’re building for EU users, or for any customer, enterprise or otherwise, who has asked where their data gets processed. It’s also worth knowing about even if nobody has asked yet: the first time a prospective customer’s legal or procurement team asks “where does our data go when we call the AI,” you want an answer ready instead of a scramble.

It matters less if you’re building a personal project or an app with no data residency promises to keep. Skip it until you have a concrete reason to pin a region.

What builders should do next

Before adding inferenceRegion to a live request, check that your chosen model actually supports the region you want. Vercel’s docs say you can filter the model list for US- or EU-available models, or check the regions array returned by the Gateway’s /v1/models address (a URL your code can request that lists every available model and where it can run), before you pin anything in production.

Then test it like a config change that can break a feature, not a cosmetic setting: send a real request with the region pinned, and read the region field back from the response to confirm it actually ran where you told it to. Compare the response’s cost against an unpinned call to see the real size of that roughly 10% premium for your specific model and provider. If the model doesn’t support your chosen region, you’ll see the request fail immediately, so run that check somewhere you’ll notice it, not for the first time in production.

Two weeks ago, Vercel’s own usage data showed open-weight models tripling their share of Gateway traffic. Regional inference is a reminder that the Gateway isn’t just a cost and reliability layer between you and a model. It’s also becoming the place where compliance decisions get made, one field at a time.

End of article