Skip to main content
API7.ai Logo

Baseten

Connect AISIX AI Gateway to Baseten so applications can call Baseten-hosted models through the gateway's OpenAI-compatible API. AISIX keeps the Baseten credential on the gateway side. It authorizes model access with caller API keys and allowlists, and applies the same rate-limit and usage-accounting controls as other model aliases.

Baseten exposes an OpenAI-compatible API, so it uses the openai adapter with a Baseten api_base.

Baseten serves models through two different surfaces, and the choice determines the api_base you configure:

  • Model APIs — a shared, multi-tenant catalog of open-weight models at a single fixed endpoint. This page uses that surface.
  • Dedicated deployments — a per-deployment endpoint for a model you deployed into your own Baseten workspace. See Route to a Dedicated Deployment.

Prerequisites​

The following examples configure the upstream through the AISIX Cloud Admin API. Before configuring the upstream, prepare the following:

  • A running AISIX managed control plane with an environment and an attached gateway. Follow the AISIX On-Premises Quickstart to set up the stack, create an admin token with write scope, and capture the environment ID.
  • A Baseten API key from the API keys page of your workspace. See Baseten API keys.

Export the connection details used by every request below:

# Replace with your values
export AISIX_CP="http://localhost:8080/api"
export AISIX_TOKEN="aisix_pat_YOUR_ADMIN_TOKEN"
export ENV_ID="YOUR_ENVIRONMENT_ID"

Configure the Baseten Upstream​

Create a provider key, model alias, and caller API key for the Baseten-backed chat-completions route.

Create a Provider Key​

Create the provider key that stores the Baseten credential and API root:

# Replace with your value
export BASETEN_API_KEY="YOUR_PROVIDER_API_KEY"

PROVIDER_KEY_ID=$(curl -sS -X POST "$AISIX_CP/provider_keys" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "baseten-prod",
    "provider": "baseten",
    "api_key": "'"${BASETEN_API_KEY}"'",
    "api_base": "https://inference.baseten.co/v1",
    "allowed_environments": ["'"${ENV_ID}"'"]
  }' | jq -r '.provider_key.id')

echo "$PROVIDER_KEY_ID"

❶ provider is baseten. The Cloud Admin API derives the adapter from the catalog provider; the adapter field is only accepted on BYO provider keys.

❷ api_key stores the Baseten API key. It follows the credential-handling behavior in Provider Credentials.

❸ api_base is the Baseten Model APIs root and already includes the /v1 path. AISIX appends the endpoint path to it, so do not add /chat/completions. Baseten is one of the catalog providers for which the Cloud Admin API can fill this value in: if you omit api_base, the create still succeeds and resolves to https://inference.baseten.co/v1. Set it explicitly anyway — it is the only way to tell a Model APIs provider key apart from a dedicated-deployment provider key when you later read the resource back.

The command captures the returned provider key ID in PROVIDER_KEY_ID.

Create a Model​

Baseten Model APIs identifiers are namespaced as publisher/model-name, matching the upstream repository that published the weights. They are case-sensitive and the casing is not uniform across publishers: deepseek-ai/DeepSeek-V4-Pro and zai-org/GLM-5.2 use mixed case, while openai/gpt-oss-120b is entirely lowercase. Copy the identifier verbatim from the Baseten Model APIs overview rather than retyping it.

Create the model alias callers will send in requests:

MODEL_ID=$(curl -sS -X POST "$AISIX_CP/environments/$ENV_ID/models" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "baseten-deepseek-v4-pro",
    "model_name": "deepseek-ai/DeepSeek-V4-Pro",
    "provider_key_id": "'"${PROVIDER_KEY_ID}"'"
  }' | jq -r '.model.id')

echo "$MODEL_ID"

❶ display_name is the alias callers send in model. Because Baseten model identifiers contain a slash, a short alias also keeps client configuration readable.

❷ model_name is the Baseten model identifier, for example deepseek-ai/DeepSeek-V4-Pro, openai/gpt-oss-120b, or zai-org/GLM-5.2.

❸ provider_key_id attaches the alias to the Baseten provider key.

Create a Caller API Key​

Create the caller API key that can access the model alias. The plaintext key is server-generated and returned once in the response — store it securely:

AISIX_API_KEY=$(curl -sS -X POST "$AISIX_CP/environments/$ENV_ID/api_keys" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "baseten-caller",
    "allowed_models": ["'"${MODEL_ID}"'"]
  }' | jq -r '.plaintext')

echo "$AISIX_API_KEY"

The allowed_models value must reference the model ID captured in the previous step.

After the write, the configuration projects to attached gateways automatically.

Verify the Provider Connection​

Send a chat-completions request through the AISIX proxy:

curl -sS -X POST "http://127.0.0.1:3000/v1/chat/completions" \
  -H "Authorization: Bearer ${AISIX_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "baseten-deepseek-v4-pro",
    "messages": [
      {
        "role": "user",
        "content": "Say hello from Baseten."
      }
    ]
  }'

The gateway returns an OpenAI-compatible response that echoes the caller-facing alias baseten-deepseek-v4-pro, not the upstream deepseek-ai/DeepSeek-V4-Pro identifier. If the request fails, check the provider key api_key, api_base, and the Baseten model identifier in model_name — a casing mismatch in model_name is the most common cause, because the identifier is case-sensitive upstream.

Route to a Dedicated Deployment​

A dedicated deployment does not answer on the shared Model APIs host. Baseten gives each deployment its own hostname derived from the model ID, and the OpenAI-compatible routes live under an environment-scoped path segment:

https://model-{model_id}.api.baseten.co/environments/production/sync/v1

See Call your model for the current URL form and the environment names available in your workspace.

Two consequences for gateway configuration:

  • Create a separate provider key for each dedicated deployment, with api_base set to that deployment's URL. The Cloud Admin API only fills in the shared Model APIs root, so api_base is effectively required here.
  • model_name on the alias is the model name the deployment itself serves, which is usually the original weights identifier rather than a Baseten Model APIs catalog identifier.

Keep the baseten provider value on a dedicated-deployment provider key so usage accounting, metrics, and access logs stay grouped with your other Baseten traffic. A dedicated deployment serves a model the pricing catalog does not cover, so set its rate as an organization pricing override rather than switching provider values. See Model Pricing and Cost Metadata.

Use Reasoning Models​

Several models on Baseten Model APIs emit reasoning traces. AISIX needs no extra configuration for them:

  • Reasoning output. Baseten returns reasoning in reasoning_content, which is already the field AISIX treats as canonical for both streaming and non-streaming responses. Unlike providers that stream reasoning under a vendor-specific delta path, Baseten needs no response.reasoning_field override on the provider key.
  • Reasoning controls. AISIX does not model every request parameter explicitly. Top-level fields it does not recognize are forwarded to the upstream verbatim through the openai adapter, so the per-model reasoning controls Baseten documents — a top-level reasoning_effort for some models, a top-level chat_template_args object for others — reach Baseten unchanged. Check Baseten reasoning for the control each model accepts, because it varies by model rather than by account.

No parameter renames are configured for Baseten, so token-limit fields also pass through as sent. Send the field name the target Baseten model documents.

Endpoint Support​

A Baseten-backed alias works on the normalized chat routes and on /v1/embeddings when the configured api_base serves an embeddings route. Baseten Embeddings Inference deployments expose an OpenAI-compatible /v1/embeddings route, so an embedding alias works when its provider key points at that deployment URL.

Anthropic-style clients calling /v1/messages are served through AISIX translation into the OpenAI request shape, because the alias resolves to the openai adapter. AISIX does not dispatch to a Baseten-native Anthropic-shaped route.

note

A Baseten model identifier that begins with openai/, such as openai/gpt-oss-120b, does not make the alias an OpenAI-provider model. The provider value is baseten, so routes that gate on the provider identity rather than the adapter — image generation, video generation, and rerank — reject the alias. See Provider Compatibility for the full route matrix.

Next Steps​

You have now connected AISIX to Baseten and verified the model alias. Continue with these guides: