Neon AI Gateway

Neon AI Gateway

This is a preview feature and only available in us-east-2. The Neon AI Gateway is the LLM inference layer built into your Neon branch: one API and one Neon credential give you access to frontier and open-source models from Anthropic, OpenAI, Google, Meta, Alibaba, DeepSeek, and Databricks — powered by Databricks. Your existing OpenAI/Anthropic/Gemini SDK works by changing only the base URL.

Use this skill to help the user send model calls through the gateway, wire it into the AI SDK or Mastra, and switch providers without rewiring code. Deliver a working inference request, a configured agent, or a precise answer from the official Neon docs.

When to Use

Reach for the AI Gateway whenever an app or agent needs to call an LLM and the user would rather not manage model providers themselves:

• One credential instead of many provider accounts. A single Neon credential reaches the entire model catalog across seven providers. No separate OpenAI / Anthropic / Google billing, keys, or signups to provision and rotate.
• Switch models without rewiring. The unified endpoint is OpenAI-compatible and works with every model in the catalog — change one model field to move between Claude, GPT, and Gemini. Standard SDKs (OpenAI, Anthropic, google-genai) work with just a base-URL change.
• AI follows your branches. Each branch has its own gateway endpoint, scoped with the same lineage as your database. AI requests from a preview/feature branch are isolated to that branch — the same isolation your data already gets — which makes preview, CI, and agent environments self-contained.
• No extra infrastructure, and it's already next to your data. The gateway lives inside your Neon project (and is injected into Neon Functions automatically), runs on the same Databricks infrastructure that serves trillions of tokens a month, and supports streaming (SSE) out of the box.

If the user already has a deep, single-provider integration and no interest in Neon branching or multi-model routing, a direct provider SDK is fine — but the moment they want one credential, model portability, or branch-scoped AI, this is the reason to use it.

What It Does

• One API for all models — Frontier and open-source models behind a single endpoint, addressed by their catalog ID (e.g. claude-sonnet-4-6, gpt-5-mini, gemini-2-5-flash).
• Standard SDKs, one URL change — OpenAI SDK and AI SDK (OpenAI-compatible MLflow/Responses routes), Anthropic SDK (native Messages), google-genai (native Gemini).
• Branch-scoped — Each branch gets its own gateway host; the Neon credential authorizes requests for that branch and its descendants.
• Streaming — Server-sent events work on all endpoints with no extra configuration.

Setup

The gateway is part of neon.ts (see the neon skill for the branch-first workflow and neon.ts basics). Enable it under preview.aiGateway:

// neon.ts
import { defineConfig } from "@neon/config/v1";

export default defineConfig({
  preview: {
    aiGateway: true,
  },
});

neon deploy   # provisions the gateway on the linked branch

Neon Infrastructure as Code (neon.ts)

The preview.aiGateway toggle above is part of neon.ts, Neon's infrastructure-as-code file — one TypeScript file declares the gateway alongside every other branch service, in version control (see the neon skill for the full reference). Reconcile it against a branch the Terraform way:

neon config status   # print the branch's live config (is the gateway on?)
neon config plan     # dry-run diff of what apply would change
neon config apply    # enable the gateway on the branch  (neon deploy is an alias)

The gateway is branch-scoped: each branch gets its own gateway host. When a neon.ts is present, neon checkout applies the policy as it creates a branch, so a fresh preview/CI branch comes up with the gateway already enabled. Checking out an existing branch doesn't reconcile it — run neon deploy to apply changes. Provisioning (config apply / deploy), link, and checkout also pull the branch's gateway credentials into your local .env.local, so local runs hit the same branch gateway as the deployed function (no manual env pull needed).

For typed, validated access to the injected credentials, pass the same config object to parseEnv from @neon/env — it returns an env.aiGateway namespace (apiKey, baseUrl) derived from your neon.ts.

Environment variables

When preview.aiGateway is enabled, Neon injects the gateway credentials as OpenAI-standard env vars (so the OpenAI SDK and AI SDK work from the environment with no config), plus NEON_-branded aliases. Inside a deployed Neon Function these are injected automatically; locally, neon env pull writes them to .env/.env.local (or use neon-env run -- <cmd> to inject at runtime without a file):

The two base URLs are different: OPENAI_BASE_URL already includes the full /ai-gateway/openai/v1 (Responses) route, while NEON_AI_GATEWAY_BASE_URL is just the bare host, so you append /ai-gateway/<dialect> yourself (this is also what the @neon/ai-sdk-provider does for you). The routes under the host are:

• /ai-gateway/mlflow/v1 — unified, OpenAI Chat Completions-compatible; recommended default, works with every provider.
• /ai-gateway/openai/v1 — OpenAI Responses API (required for gpt-5-…-codex variants and gpt-5-5-pro). This is the route OPENAI_BASE_URL already points at, because the @ai-sdk/openai provider uses the Responses API by default.
• /ai-gateway/anthropic/v1 — native Anthropic Messages (extended thinking, prompt caching).
• /ai-gateway/gemini/v1beta/... — native Gemini generateContent.

So ${NEON_AI_GATEWAY_BASE_URL}/ai-gateway/mlflow/v1 is the chat-completions endpoint, ${NEON_AI_GATEWAY_BASE_URL}/ai-gateway/openai/v1 equals OPENAI_BASE_URL, and so on. If you only have OPENAI_BASE_URL and need chat completions, swap the dialect: baseUrl.replace("/openai/v1", "/mlflow/v1") (this is what the Mastra example does).

For typed access, parseEnv (from @neon/env) returns env.aiGateway (apiKey, baseUrl) derived from your neon.ts.