Ошибки 429 у Kimi K3 на OpenRouter? Настраиваем failover за 2 минуты (2026)

TL;DR. Если ваши вызовы Kimi K3 на OpenRouter упорно возвращают 429, дело не в вашем коде и не в вашей квоте. На старте у Moonshot ограничена вышестоящая ёмкость под K3, и OpenRouter сам пишет об этом прямо на странице модели: “Upstream capacity is currently limited. This model may return frequent 429 errors.” K3 там — маршрут с единственным провайдером, так что переключаться на другого провайдера не на кого. Решение в два слоя: сделайте backoff на первые пару повторов, а затем переключитесь на сопоставимую модель — GLM-5.2 или DeepSeek V4 — на одном эндпоинте и одном ключе. Ни один шлюз, включая ofox, не заставляет вышестоящий 429 исчезнуть; шлюз лишь превращает переход на запасной вариант в одну строку конфигурации вместо переписывания.

429 на K3 — это сигнал сверху «места нет», а не сигнал вашего аккаунта «слишком много». Упорные повторы того же маршрута ставят вас в очередь за всеми, кто делает ровно то же самое. Единственный работающий ход — другая модель.

Это K3, OpenRouter или вы? Проверка за 30 секунд

Три проверки по порядку. Если первые две подтверждают, что проблема наверху, перестаньте читать собственные логи и переходите к решению.

Если пункты 1 и 2 загорелись — это ёмкость Moonshot, а не баг в вашем приложении. Инди-разработчик @levelsio столкнулся ровно с этим: OpenRouter «сразу выдал ‘rate limited upstream’», так что он заплатил Moonshot $19 за прямой ключ и двинулся дальше. Вам так делать не обязательно — но fallback вам нужен.

Почему K3 отдаёт 429 именно на OpenRouter

Складываются два факта.

Во-первых, K3 новая, и Moonshot нормирует ёмкость. Это вышестоящая реальность, которую наследует любой реселлер; именно поэтому OpenRouter, ofox и прямой ключ Moonshot могут все вернуть 429 в один и тот же день.

Во-вторых — и это уже специфика OpenRouter: листинг K3 обслуживается одним провайдером. Страница OpenRouter говорит об этом прямо — “This model is hosted by one provider. OpenRouter forwards every request to it directly — no routing decisions to make.” («Эта модель размещена у одного провайдера. OpenRouter пересылает каждый запрос ему напрямую — никаких решений по маршрутизации».) Обычная сила OpenRouter — это маршрутизация между провайдерами: когда у модели несколько хостов, трафик уводится на здоровый. У модели с единственным провайдером уводить некуда. Маршрутизация между провайдерами не спасёт маршрут, у которого провайдер всего один.

На OpenRouter вы всё ещё можете сами добавить fallback-массив между моделями, и это стоит сделать. Смысл в том, что для K3 это не происходит автоматически, и в тот момент, когда вы пишете список fallback, вы делаете ровно ту работу, которую единый шлюз делает за вас в одном месте. Именно об этом выборе и весь этот пост.

Решение в два честных слоя

Слой 1 — короткий backoff

Ёмкостные 429 часто временные. Повторите первые две-три попытки с экспоненциальным backoff и джиттером, а затем остановитесь. Джиттер важен: без него каждый клиент, получивший 429 в один и тот же момент, повторяет запрос в тот же момент — и вы заново устраиваете давку.

import time, random, httpx

def backoff_sleep(attempt: int) -> None:
    base = 2 ** attempt          # 1s, 2s, 4s
    time.sleep(base + random.uniform(0, base * 0.3))  # +0–30% jitter

Сдавайтесь после трёх попыток. Четвёртый повтор на ёмкостно-ограниченном маршруте с единственным провайдером не найдёт ёмкости, которой не нашли первые три, — он лишь добавит в очередь.

Слой 2 — failover на другую модель

Именно этот слой реально восстанавливает запрос. Когда у K3 нет места, самый быстрый путь к ответу — сопоставимая модель, у которой место есть. На ofox K3 и её запасные варианты стоят за одним OpenAI-совместимым эндпоинтом и одним ключом, так что цепочка fallback — это короткий цикл, а не три интеграции:

import os, httpx, time, random

OFOX = "https://api.ofox.io/v1/chat/completions"
OFOX_API_KEY = os.environ["OFOX_API_KEY"]
HEADERS = {"Authorization": f"Bearer {OFOX_API_KEY}", "Content-Type": "application/json"}

# Primary first, then same-tier backups on separate upstreams.
CHAIN = ["moonshotai/kimi-k3", "z-ai/glm-5.2", "deepseek/deepseek-v4-pro"]

def complete(messages, chain=CHAIN):
    for model in chain:
        for attempt in range(3):
            r = httpx.post(OFOX, headers=HEADERS,
                           json={"model": model, "messages": messages}, timeout=60)
            if r.status_code == 429:
                if attempt == 2:
                    break         # third 429 -> fail over now, don't sleep
                base = 2 ** attempt
                time.sleep(base + random.uniform(0, base * 0.3))
                continue          # retry same model, up to 3x
            r.raise_for_status()
            return model, r.json()
        # three 429s on this model -> drop to the next model in the chain
    raise RuntimeError("all models in the fallback chain are capacity-limited")

Та же схема работает из Node или из OpenAI SDK — достаточно нацелить base_url на https://api.ofox.io/v1 и поменять строку model. Ни в промптах, ни в формате сообщений ничего не меняется.

И ещё раз честно, чтобы никто внутри команды не пустил в оборот ложное утверждение: 429 на K3 идёт от вышестоящего Moonshot, поэтому ни один шлюз его не предотвращает — ofox в том числе. ofox отдаёт K3 из того же источника и вернёт 429, когда у Moonshot заполнено. Меняется время восстановления: failover выше превращает жёсткую ошибку в переход на GLM-5.2, которого ваши пользователи вообще не видят.

Выбирайте запасной вариант, который действительно заменяет K3

Не переключайтесь на модель, которая не справится с задачей. Для типичных для K3 задач по коду и агентных нагрузок вот замены того же уровня на ofox, по ID модели:

Прежде чем встраивать модель в пайплайн, сверьте актуальную цену за токен на странице каждой из них — уровни и ставки меняются, и запасной вариант, выбранный по цене три месяца назад, сегодня может оказаться не самым дешёвым. Если вы выбираете шлюз, а не отдельную модель, отдельно стоит разобраться с математикой комиссий разных шлюзов и с их надёжностью по аптайму.

А нужна ли вам K3 прямо сейчас?

Быстрая схема для принятия решения, прежде чем сражаться с 429:

• Вам нужны именно возможности K3. Оставьте её основной, заложите окно повторов в 5–7 секунд и переключайтесь при исчерпании. Логируйте долю успеха с первой попытки, чтобы понять, когда снимут предупреждение о нехватке ёмкости.
• Задача — обычный код или агентная работа. Запасной вариант вроде GLM-5.2 или DeepSeek V4 Pro вполне может уже сегодня обслуживать вас без всяких 429. Повысьте его до основного, а K3 держите как вариант на случай, когда ёмкость освободится.
• У вас жёсткий SLO по задержке. Сразу опустите K3 в запасной слот. Модель с постоянным предупреждением о «частых 429» — небезопасный вариант по умолчанию для пути, который не может позволить себе повторы.

Более широкий паттерн здесь — детект всплеска, ограниченный бюджет повторов, затем failover между моделями — тот же, что справляется с перегрузкой любого провайдера. Мы разбирали его на стороне Anthropic применительно к ошибке 529 при перегрузке, и есть общая версия в нашем руководстве по обработке ошибок AI API.

Один ключ для K3 и её запасных вариантов

Причина, по которой шлюз здесь помогает, узкая и реальная: не в том, что он убирает 429, а в том, что он схлопывает «K3 плюс три запасных» в один эндпоинт, один ключ и один список fallback. На ofox это значит, что K3 (moonshotai/kimi-k3) и GLM-5.2, DeepSeek V4 и Kimi K2.7 Code — все отвечают на одном OpenAI-совместимом API, без комиссии за покупку кредитов и без листа ожидания на вход. Когда предупреждение Moonshot о нехватке ёмкости снимут, вы не меняете ничего; когда оно снова ужесточится — ваш fallback уже это перехватил.