Skip to main content
API7.ai Logo

Moonshot AI (Kimi)

Connect AISIX AI Gateway to Moonshot AI so applications can call Kimi models through the gateway's OpenAI-compatible API. AISIX keeps the Moonshot 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.

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

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, plus an admin token with write scope. Follow the AISIX On-Premises Quickstart to set these up and capture the environment ID.
  • A Moonshot API key from the Kimi API Platform.

Export the connection details used by every request below:

export AISIX_CP="http://localhost:8080/api"
export AISIX_TOKEN="aisix_pat_YOUR_ADMIN_TOKEN"
export ENV_ID="YOUR_ENVIRONMENT_ID"

Configure the Moonshot AI Upstream​

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

Create a Provider Key​

Moonshot AI serves its API from two independent hosts. Pick the one that matches the console where you created the API key:

  • Global platform: https://api.moonshot.ai/v1
  • China platform: https://api.moonshot.cn/v1

The two hosts are separate deployments with separate consoles, so a key issued on one platform does not authenticate against the other. Always set api_base explicitly. When api_base is omitted for the moonshotai provider, AISIX fills in the China platform root https://api.moonshot.cn/v1, which is not what most callers outside China want.

Create the provider key that stores the Moonshot credential and API root, and capture its ID:

# Replace with your value
export MOONSHOT_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": "moonshot-prod",
    "provider": "moonshotai",
    "api_key": "'"${MOONSHOT_API_KEY}"'",
    "api_base": "https://api.moonshot.ai/v1",
    "allowed_environments": ["'"${ENV_ID}"'"]
  }' | jq -r '.provider_key.id')

echo "$PROVIDER_KEY_ID"

❶ provider is moonshotai, not moonshot or kimi. The Cloud Admin API only accepts catalog provider IDs and rejects other spellings with 400 INVALID_REQUEST. 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 Moonshot API key and is sent as a bearer token. The value is encrypted before storage and never returned by read endpoints. It follows the credential-handling behavior in Provider Credentials.

❸ api_base already includes the /v1 path segment, because Moonshot AI publishes its OpenAI-compatible surface under /v1 rather than at the host root. AISIX appends the endpoint path to it, so use https://api.moonshot.ai/v1 without a trailing /chat/completions. To route to the China platform instead, keep provider as moonshotai and set api_base to https://api.moonshot.cn/v1.

The command captures the returned provider key ID in PROVIDER_KEY_ID.

Create a Model​

Moonshot model IDs follow a kimi-<generation> pattern, with an optional suffix for a task-specific or throughput-specific variant. For example, kimi-k2.6 is the general-purpose model, kimi-k2.7-code is the coding model, and kimi-k2.7-code-highspeed is its higher-throughput variant. kimi-k3 is the current flagship. Moonshot AI retires older snapshots such as the earlier kimi-k2-*-preview IDs, so confirm the ID against the Kimi model list before pinning 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": "kimi-k26-prod",
    "model_name": "kimi-k2.6",
    "provider_key_id": "'"${PROVIDER_KEY_ID}"'"
  }' | jq -r '.model.id')

echo "$MODEL_ID"

❶ display_name is the alias callers send in model. The alias is independent of the upstream ID, so it does not need to carry the generation number.

❷ model_name is the Moonshot model ID, for example kimi-k2.6, kimi-k2.7-code, or kimi-k3. The dot is part of the upstream ID and must be preserved exactly.

❸ provider_key_id attaches the alias to the Moonshot provider key.

Create a Caller API Key​

Create the caller API key that can access the model alias. The gateway generates the key value and returns the plaintext once in the create response, so capture it now:

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": "moonshot-caller",
    "allowed_models": ["'"${MODEL_ID}"'"]
  }' | jq -r '.plaintext')

echo "$AISIX_API_KEY"

The allowed_models value references the model by its ID, so the key can only access the alias you created. 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": "kimi-k26-prod",
    "messages": [
      {
        "role": "user",
        "content": "Say hello from Kimi."
      }
    ]
  }'

The gateway returns an OpenAI-compatible response that echoes the caller-facing alias kimi-k26-prod. If the request fails, check the provider key api_key, api_base, and the Moonshot model ID in model_name. An authentication failure on a key that works in the Moonshot console usually means the api_base host does not match the platform that issued the key.

Use Thinking Mode​

Kimi models reason by default, and Moonshot AI controls this with a top-level thinking object rather than a per-message field. On kimi-k2.6, send {"type": "disabled"} to turn reasoning off for a request:

{
  "thinking": {
    "type": "disabled"
  }
}

AISIX forwards top-level request fields it does not model itself, including thinking, verbatim to the upstream, so no provider-key override is needed to use this control. Reasoning controls differ across model generations:

Modelthinking.type valuesReasoning depth
kimi-k2.6enabled (default), disabledNot exposed
kimi-k2.7-codeenabled only, so reasoning is always onNot exposed
kimi-k3enabled, disabled, adaptiveoutput_config.effort in adaptive mode: low, high, or max

Check the Kimi thinking mode guide for the parameters each model accepts.

Moonshot AI returns reasoning text in the reasoning_content field, which is the canonical field AISIX already normalizes to. On streaming responses, reasoning_content deltas arrive before content deltas; on non-streaming responses, the field appears at choices[0].message.reasoning_content. Because the upstream shape already matches, the moonshotai catalog entry sets no response.reasoning_field override and none is required. Set response.reasoning_field only for an upstream that streams reasoning from a different delta path.

Reasoning tokens count toward the request's max_tokens budget on Moonshot AI, because the token counts for reasoning_content and content are summed against that limit. Raise max_tokens when a reasoning-heavy prompt returns truncated content, and account for the same tokens when you set per-model budgets in AISIX.

Review Endpoint Support​

Moonshot-backed aliases work on the chat-completions route and on bridged Responses requests. Several other proxy routes gate on the provider value rather than on the adapter, so they reject a moonshotai alias even though it uses the openai adapter:

  • /v1/images/generations requires a model whose provider is openai and returns 400 for any other provider.
  • /v1/rerank accepts only the openai, cohere, and jina provider values.
  • /v1/videos accepts only its own provider allowlist, which does not include moonshotai.

For a Moonshot-native endpoint that AISIX does not model, use Provider Passthrough with moonshotai as the provider segment:

curl -sS -X GET "http://127.0.0.1:3000/passthrough/moonshotai/v1/models" \
  -H "Authorization: Bearer ${AISIX_API_KEY}"

Passthrough keeps caller authentication and upstream credential injection. When the request path starts with the same version segment that already ends api_base, AISIX collapses the duplicate, so the request above reaches https://api.moonshot.ai/v1/models rather than a doubled /v1/v1 path.

Next Steps​

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