Ошибки и режимы отказа Kimi K3

Как устроена ошибка

Ошибки приходят единым объектом error с полями message, type и code:

{
  "error": {
    "message": "API key is missing or invalid",
    "type": "invalid_authentication_error",
    "code": null
  }
}

Не ветвитесь по code. Поле допускает null, и во всех ошибках, которые мы спровоцировали напрямую у Moonshot, его не было вовсе. Всегда заполненным оказывалось поле type — сопоставляйте по нему.

Через шлюз тела ошибок авторизации и «модель не найдена» ниже не совпадут байт в байт. Неверный ключ отбивает собственный слой авторизации шлюза, и до Moonshot запрос не доходит — вы получите его формулировку, а не формулировку Moonshot. Симптомы, причины и способы починки от этого не меняются. Поведенческие находки на этой странице — ловушка с пустым content, параметры без валидации — свойства самой модели и действуют везде, где отдают K3.

{
  "error": {
    "message": "Invalid Authentication",
    "type": "invalid_authentication_error"
  }
}

Ошибки по симптомам

{"error": {
  "message": "Invalid Authentication",
  "type": "invalid_authentication_error"
}}

{"error": {
  "message": "Not found the model kimi-k3-chat
              or Permission denied",
  "type": "resource_not_found_error"
}}

{"error": {
  "message": "Invalid request: messages
              must not be empty",
  "type": "invalid_request_error"
}}

{"error": {
  "message": "Rate limit exceeded",
  "type": "...",
  "code": null
}}

Сбои, которые не возвращают ошибку

Эту категорию стоит усвоить. K3 не валидирует ваши параметры — мы нашли два случая, когда очевидно некорректный запрос возвращает чистый HTTP 200:

Урок шире этих двух случаев: 200 от K3 не означает, что запрос понят так, как вы задумали. Если вы рассчитываете, что параметр меняет поведение, — проверьте, что поведение действительно изменилось, а не выводите это из отсутствия ошибки. Вместе с ловушкой пустого content правило простое: проверяйте сам ответ, а не код статуса.

Чек-лист перед релизом

1. model в ответе повторяет kimi-k3 — шлюз ничего молча не подменил.
2. finish_reason == "stop", а не "length".
3. content непустой.
4. usage.total_tokens ненулевой, и вы логируете reasoning_tokens.
5. Клиентский таймаут в минутах, если работаете с длинным контекстом.
6. Каждый параметр, на который вы полагаетесь, проверен по наблюдаемому поведению, а не по коду 200.

Готовая проверка для вашего кода — в руководстве по API.