Доступ к Kimi (Moonshot) API, OpenAI-совместимо — и его thinking по умолчанию

Длинный контекст Kimi хорош для больших файлов и repo-масштабных промптов, а через DaoXE он за тем же ключом, что GPT, Claude и DeepSeek — без отдельной регистрации в Moonshot. Вызывайте /v1/chat/completions с ID Kimi. Маршрутизация — гайд по дешёвым API.

Как вызвать Kimi (Moonshot) через DaoXE#

Используйте /v1/chat/completions с точным ID Kimi. Рассуждения управляются по-разному внутри текущего семейства: K2.6 хранит поле thinking (по умолчанию ВКЛ; отключайте для обычного вывода), сборки K2.7-code блокируют thinking без отключения, а K3 заменяет поле на верхнеуровневый reasoning_effort (low/high/max, по умолчанию max).

# Kimi's reasoning contract differs by generation: K2.6 keeps the thinking
# field (ON by default - send disabled for plain output), K2.7-code locks it
# on, and K3 drops the field for a top-level reasoning_effort instead.
curl --fail-with-body --show-error --silent \
  https://daoxe.com/v1/chat/completions \
  -H "Authorization: Bearer ${DAOXE_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "YOUR_EXACT_MODEL_ID",
    "max_tokens": 64,
    "messages": [{"role": "user", "content": "Reply with OK."}],
    "thinking": {"type": "disabled"}
  }'

Как Kimi отдаёт рассуждения#

Контракт на рассуждения у Kimi разделился на три ветки по мере эволюции семейства. K2.6 хранит K2.x-объект thinking (enabled по умолчанию, disabled для отказа) — это поле только для K2.x, у OpenAI SDK нет для него нативного слота, поэтому оно едет через extra-body. K2.7-code блокирует: thinking всегда включён, {"type": "disabled"} даёт ошибку, принимается лишь {"type": "enabled", "keep": "all"}. K3 выбрасывает поле в пользу верхнеуровневого reasoning_effort (low/high/max, по умолчанию max) и всегда рассуждает с Preserved Thinking — трасса по-прежнему приходит в reasoning_content, который в многошаговом tool use надо возвращать как есть. Две ловушки стоимости: смена effort посреди диалога инвалидирует prefix-cache, а из всех уровней только у K3 доки обещают tool_choice: required. Проходят ли эти пофамильные поля через конкретный путь релея — ровно то, что надо проверять: один тестовый вызов, прежде чем привязывать клиент.

Нюансы именно для Kimi (Moonshot)#

• Три поведения, одно семейство. K2.6: thinking по умолчанию ВКЛ — шлите {"type": "disabled"} для обычного вывода. K2.7-code: thinking всегда включён, а disabled даёт ошибку. У K3 поля thinking нет вовсе — вместо него верхнеуровневый reasoning_effort. Проверьте, какой ID вы зафиксировали, прежде чем релизить клиент.
• Сэмплинг заблокирован на reasoning-ID. K2.6 фиксирует temperature на 1.0 (thinking) / 0.6 (non-thinking), K2.7-code и K3 — на 1.0; top_p 0.95, n 1 и штрафы тоже фиксированы — вендор пишет, что иные значения возвращают ошибку. Не передавайте temperature явно на этих ID.
• Смена effort у K3 ломает кэш. Переключение reasoning_effort посреди диалога инвалидирует prefix-cache — выбирайте уровень до начала разговора и держите его. K3, кроме того, накрывает контекст 1M токенов против 256K у K2.x.
• Round-trip reasoning_content. При включённом thinking возвращайте предыдущее сообщение ассистента как есть — включая reasoning_content — в многошаговом tool use, иначе запрос упадёт. Точные ID — всегда из GET /v1/models.

Сколько это стоит#

Убедитесь, что отдают настоящую модель#

Сначала проверьте эндпоинт, а не клиент — если это не работает, настройки не помогут:

export DAOXE_API_KEY="your_api_key"

# List the exact model IDs your account can call
curl --fail-with-body --show-error --silent \
  https://daoxe.com/v1/models \
  -H "Authorization: Bearer ${DAOXE_API_KEY}"

Подтвердите связь, затем сравните длинноконтекстный промпт с официальным API Moonshot при temperature 0 для проверки recall:

Частые вопросы#