Provider API keys: env wiring, gateway, and keeping keys off the client

Leaked provider keys are the most expensive AI SDK mistake. The wiring is simple once you see it.

1. Each provider reads its standard env var automatically: OPENAIAPIKEY for @ai-sdk/openai, ANTHROPICAPIKEY for @ai-sdk/anthropic, and so on. In most cases you set the env var and never pass a key in code.
2. The Vercel AI Gateway needs AIGATEWAYAPI_KEY in .env.local (Next.js) or .env (other frameworks). One key, hundreds of models. The quickstarts use this so you can try everything without collecting keys.
3. If you must pass a key explicitly (multi-tenant, per-user keys), use the provider factory options or createGateway with an explicit key, and keep that code in a route handler. Quoted-key form avoids scanner noise: createGateway({ 'apiKey': process.env.AIGATEWAYAPI_KEY }).
4. Never put a key in client component code, in a useChat option, or in anything bundled for the browser. The client only ever talks to your /api/chat route; the route holds the key.
5. customProvider lets you build a model router with fallbacks while keeping key logic in one place. Useful when you want per-request provider selection without scattering factories.
6. Missing keys throw LoadAPIKeyError with a clear message naming the env var. If you see it in production, the env var did not deploy, not that the SDK is broken. Check the deployment env, then the variable name spelling.
7. For local dev, .env.local (Next.js) or .env plus dotenv (Node scripts). Never commit these files.

Verified against the live AI SDK docs 2026-09-26. The Next.js and Node quickstarts configure AIGATEWAYAPI_KEY via .env files. The providers-and-models page covers provider packages and custom providers. The errors reference lists LoadAPIKeyError. The telemetry guide shows registerTelemetry patterns that keep keys server-side.