本サイトが返すすべての失敗を、2026-09-01 に実際のエンドポイントへ 1 件ずつ投げて確認したものです。返ってくる 8 件のうち 5 件はステータスコードが本当の原因を指しておらず、そのうち 2 件は公式 SDK が黙って再試行するため、プログラムに届くのはさらに後になります。
2026-09-01 検証
ステータスコードが実際の原因と異なる
モデル名の誤りは 503、messages フィールドの欠落は 500 で返ってきます。どちらもリクエスト自体の誤りで、何度再試行しても結果は変わりません。ところが openai-python、openai-node、Anthropic の各 SDK はいずれも 408・409・429 と 5xx 全般を既定で 2 回、指数バックオフ付きで再試行します。つまり 1 か所のタイプミスが 3 往復と数十秒の待ち時間に変わり、そのあとで最初から確定していた原因がようやく表示されます。本当の原因は最初からレスポンスボディの error.code にあり、嘘をついているのはステータスコードの側です。
一覧
数値順ではなく、実際に遭遇する頻度の順に並べています。
空文字列Invalid tokenmodel_not_foundステータスコードが実際の原因と異なるNo available channel for model gpt-4o under group y-api (distributor)insufficient_user_quotaステータスコードが実際の原因と異なる用户额度不足, 剩余额度: ＄0.00pre_consume_token_quota_failedステータスコードが実際の原因と異なるtoken quota is not enough, token remain quota: ＄0.000002, need quota: ＄0.000074invalid_requestステータスコードが実際の原因と異なるfield messages is requiredinvalid_request_errorステータスコードが実際の原因と異なる`messages` is required and must be a non-empty array.空文字列Invalid request: Invalid request: invalid JSON request body空文字列Invalid URL (POST /v1/messages/count_tokens)静かな失敗
200 を返し、例外も投げず、プログラムがそのまま進んでしまう失敗が 3 つあります。おかしいのは内容か請求額です。だからこそ自力では見つけにくいのです。
上流は 5 つのモデルに image_ratio を付けています。あれは課金係数であって、視覚能力を意味しません。5 つとも data URL の画像を受け取り 200 を返し、見ていない画像について自信たっぷりに答えます——プローブが送ったのは純緑色の PNG ですが、色を当てたモデルは 1 つもありませんでした。推奨モデルはむしろ 400 で拒否します。2 つの失敗のうち、そちらのほうが安全です。
クライアント互換性マトリクスより
上限を 12 にしても moonshotai/kimi-k2.5 の課金は 261、21.8 倍でした。切り詰め自体は効いています（finish_reason=length）。超過分は推論トークンで、課金されるのに content には現れません。この上限から算出したコスト見積もりは、同じ倍率で過小になります。
クライアント互換性マトリクスより
POST /v1/messages は接頭辞なしの 16 進数 id を返します。msg_ 接頭辞を前提にアサートしたり、id を解析してレスポンスを振り分けるコードは一致しません——ボディのそれ以外は仕様どおりであるにもかかわらず。
クライアント互換性マトリクスより
パース
外側は必ず {"error": {...}} ですが、フィールドの集合は一定ではありません。param があるエラーとないエラーがあり、code は空文字列であることが多いです。すべてのフィールドを省略可能として扱ってください。
{"error":{"code":"","message":"Invalid token (request id: 2026090114474514374…)","type":"new_api_error"}}{"error":{"message":"Invalid URL (POST /v1/messages/count_tokens)","type":"invalid_request_error","param":"","code":""}}どのメッセージも末尾に request id が付き、リクエストごとに異なります。このページと見比べる前に取り除いてください。逆に、問題を報告するときは必ず添えてください——ログでそのリクエストを特定できる唯一の手がかりです。
切り分け
この順番で。1 つずつ層を除外していくので、手が止まったところが答えです。
GET /v1/models はクレジットを消費せず、同じキーを使います。200 とモデル一覧が返れば、キー・ネットワーク・CDN エッジのすべてに問題がないことが分かります。つまり原因は認証ではなくリクエストボディです。
curl -s https://api.y-api.bestvirtualgoods.com/v1/models -H "Authorization: Bearer $YAPI_KEY" | head -c 200これで SDK を切り離せます。curl が成功して自分のコードが失敗するなら、差はそのライブラリのリクエストの組み立て方にあり、本サイト側ではありません。
curl -i https://api.y-api.bestvirtualgoods.com/v1/chat/completions \
-H "Authorization: Bearer $YAPI_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"deepseek/deepseek-v4-flash","messages":[{"role":"user","content":"hi"}]}'再試行を切れば、自分のリクエストが原因の 500 や 503 が 1 回目で表に出ます。2 回の無駄な待ちが挟まりません。終わったら戻してください——本物の一時障害に対しては再試行に意味があります。
client = OpenAI(
base_url="https://api.y-api.bestvirtualgoods.com/v1",
api_key=os.environ["YAPI_KEY"],
max_retries=0, # 切り分け時のみ
)ステータスページでは本サイト自体が劣化しているかどうかを、過去 90 日分の記録とともに確認できます。そこが緑のままで解決しないときは、エラーボディの request id を送っていただくのが最も有効です。