OpenRouterでKimi K3が429を返す？2分でフェイルオーバーする方法（2026年版）

TL;DR。 OpenRouter経由のKimi K3への呼び出しが 429 を返し続けるなら、それはあなたのコードでもクォータでもありません。リリース時点でMoonshotの上流側のK3容量が制限されており、OpenRouterもモデルページ自体でそう明言しています。曰く “Upstream capacity is currently limited. This model may return frequent 429 errors.”（上流の容量が現在制限されています。このモデルは頻繁に429エラーを返す可能性があります）。そこでのK3は単一プロバイダーのルートなので、フェイルオーバーできるプロバイダーが存在しません。対処は2層です。最初の数回はバックオフし、次に同等モデル（GLM-5.2かDeepSeek V4）へ、単一のエンドポイントと単一のキーでフェイルオーバーします。ofoxを含め、どのゲートウェイも上流の429を消すことはできません。ゲートウェイができるのは、バックアップへの乗り換えを書き換えではなく設定1行にすることだけです。

K3の429は、あなたのアカウントが「使いすぎ」と言っているのではなく、上流が「空きがない」と言っている状態です。同じルートに強くリトライをかければ、まったく同じことをしている全員の後ろに並ぶだけ。効く一手は、別のモデルに切り替えることだけです。

K3か、OpenRouterか、それとも自分か？ 30秒の切り分け

順番に3つ確認します。最初の2つで原因が上流だと確定したら、自分のログを読むのはやめて対処へ飛んでください。

ステップ1と2が該当するなら、これはMoonshotの容量問題であって、あなたのアプリのバグではありません。個人開発者の@levelsio氏もまさにこれに遭遇し、OpenRouterが「即座に『rate limited upstream』と返した」ため、Moonshotに$19払って直接キーを取得し先に進みました。あなたは必ずしもそうする必要はありません。ただしフォールバックは必要です。

なぜK3の429はOpenRouterで特に起きるのか

事実が2つ重なっています。

第一に、K3は新しく、Moonshotが容量を配給制にしています。これはあらゆる再販業者が引き継ぐ上流側の現実で、OpenRouterもofoxもMoonshotの直接キーも、同じ日の午後に一斉に429を返しうる理由です。

第二に、そしてこれがOpenRouter固有の部分ですが、K3のリスティングは1つのプロバイダーによって提供されています。OpenRouterのページにもはっきり書かれています。曰く「This model is hosted by one provider. OpenRouter forwards every request to it directly — no routing decisions to make.（このモデルは1つのプロバイダーによってホストされています。OpenRouterはすべてのリクエストを直接そこへ転送します。ルーティングの判断はありません）」。OpenRouterの本来の強みはプロバイダールーティングです。モデルに複数のホストがあれば、健全なホストへトラフィックを振り分けます。単一プロバイダーのモデルでは、振り分ける先がありません。プロバイダーが1つしかないルートを、プロバイダールーティングは救えないのです。

それでもOpenRouter上で、自分でモデルをまたぐフォールバック配列を追加することはできますし、そうすべきです。ポイントは、K3ではそれが自動ではないこと、そしてフォールバックリストを書き始めた時点で、あなたは統合ゲートウェイが1か所でやってくれるのと同じ作業をしているということです。本記事が扱う判断は、まさにここに尽きます。

対処法、正直な2層構成

第1層 — 短くバックオフする

容量由来の429は一過性のことが多いです。最初の2〜3回はジッター付きの指数バックオフでリトライし、そこで打ち切ります。ジッターが重要です。これがないと、同じ瞬間に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

3回試したら諦めます。容量制限中の単一プロバイダールートに4回目のリトライをかけても、最初の3回で見つからなかった容量が見つかるわけではありません。キューに積み増すだけです。

第2層 — 別のモデルへフェイルオーバーする

リクエストを実際に回復させるのはこの層です。K3に空きがないとき、答えに最速で辿り着く道は、空きのある同等モデルです。ofoxでは、K3とそのバックアップ群が1つのOpenAI互換エンドポイントと1つのキーの背後に揃っているので、フォールバックチェーンは3つの統合ではなく短いループで済みます。

import os, httpx, time, random

OFOX = "https://api.ofox.ai/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.ai/v1 に向けて model 文字列を差し替えるだけでも動きます。プロンプトやメッセージ形式は何も変わりません。

正直な部分を、社内で誤った主張を出す人が出ないよう、もう一度だけ言っておきます。K3の429はMoonshotの上流から来るので、どのゲートウェイもそれを防げません。ofoxも例外ではありません。 ofoxは同じソースからK3を提供しており、Moonshotが満杯のときは429を返します。変わるのは回復時間です。上のフェイルオーバーは、ハードエラーを、ユーザーには見えないGLM-5.2への乗り換えに変えます。

K3に本当に見合うバックアップを選ぶ

仕事をこなせないモデルへフェイルオーバーしてはいけません。K3の典型的なコーディング・エージェント用途に対して、ofox上でモデルIDごとに挙げる同一ティアの代替はこちらです。

パイプラインに組み込む前に、各モデルのページで現在のトークン単価を確認してください。ティアやレートは変動し、3か月前に価格で選んだバックアップが今日も最安とは限りません。単一モデルではなくゲートウェイを選ぶ場合は、OpenRouterの代替候補比較や料金内訳、稼働率の実態といった観点も検討材料になります。

そもそも今、K3が必要か？

429と格闘する前に、手早い判断フレームを1つ。

• どうしてもK3の能力が必要な場合。 プライマリのまま維持し、5〜7秒のリトライ枠を確保して、使い切ったらフェイルオーバーします。一発目の成功率をログに残しておけば、容量警告がいつ解除されたか分かります。
• タスクが一般的なコーディングやエージェント作業の場合。 GLM-5.2やDeepSeek V4 Proのようなバックアップなら、今日でも429なしで十分に使えるかもしれません。それをプライマリに昇格させ、容量が空いたとき用にK3を選択肢として残しておきましょう。
• 厳格なレイテンシSLOがある場合。 K3は迷わずバックアップ枠に降格させます。「頻繁な429」の警告が常時出ているモデルは、リトライを吸収できない経路のデフォルトとしては安全ではありません。

ここでのより一般的なパターン——スパイク検知、上限付きのリトライ予算、そしてモデルをまたぐフェイルオーバー——は、どのプロバイダーの過負荷にも通用する同じ型です。Anthropic側のエラー529への対処や、AI APIのエラーハンドリング全般についても、同じ考え方がそのまま当てはまります。

K3とそのバックアップを1つのキーで

ゲートウェイがここで役立つ理由は、狭くて具体的です。429を消すからではなく、「K3＋3つのバックアップ」を1つのエンドポイント、1つのキー、1つのフォールバックリストにまとめてくれるからです。ofoxでは、K3（moonshotai/kimi-k3）もGLM-5.2、DeepSeek V4、Kimi K2.7 Codeも、すべて同じOpenAI互換APIで応答し、クレジット購入手数料も参加待ちのウェイトリストもありません。Moonshotの容量警告が解除されても、あなたは何も変えなくていい。再び逼迫しても、フォールバックがすでに受け止めています。