Claude APIやClaude Codeを仕事で使っているなら、10月7日の記録を一度だけ見てほしい。
Claudeの公式ステータスページには、2026年9月1日から10月25日までの55日間に、26件の障害が載っている。筆者が公開APIから全件を数えたところ、次の3つがそろうのは1件しかなかった。
- 原因はモデルでもサーバーでもなく、支出上限（spend limit）の誤判定
- Claude API、Claude.ai、Claude Code、Claude Security、Claude Coworkの5製品で要求が拒否された
- それなのに、記録は影響度「none」、対象コンポーネント0個
それが、10月7日21時23分（UTC、日本時間8日6時23分）に掲載された「Issue with spend limits」だ。本文はこれで全部だ。
We have identified an issue which resulted in some organizations to be incorrectly paused for having reached their spend limit, resulting in refused requests on the Claude API, Claude.ai, Claude Code, Claude Security, and Claude Cowork. This is now resolved.
一部の組織が、上限に達していないのに「上限に達した」と判定されて止められた。何組織が何分止まったのかは書かれていない。そして、ステータスAPIに残っている記録はこうだ。
"name": "Issue with spend limits",
"impact": "none",
"components": [],
止まった組織にとっては5製品の停止。記録の上では「影響なし」だ。
結論から言うと
1. 支出上限と課金のエラーを、ほかの400・429と分けて拾い、請求が別の経路へ逃がす仕組みを今日入れること。 「上限に届いていないのに止められた」ときの切り替えは、公式の自動回復機能には入っていない。自分で書くしかない。
2. 公式の自動回復4機能は、どれも支出上限の停止を直さない。 SDKの自動リトライ、Claude Codeのフォールバック、APIの fallbacks、拒否用のSDKミドルウェア。公式ドキュメントを読む限り、4つとも課金の停止は対象外か、再試行しても失敗する。
3. ステータスページの見張りでは気づけない。 55日間で影響度が「none」だったのは2件だけで、2件ともお金まわり、対象コンポーネントは0個だった。コンポーネントの状態で監視していると、10月7日の件は検知できない。
図: 10月7日の停止が起きた場所。Claude公式ステータスと公式ドキュメントをもとに筆者が作図した（判定の内部の構造は推測）
数字は、2026年10月25日（UTC）にClaudeの公式ステータスAPI（/api/v2/incidents.json）から筆者が数えたもの。期間は9月1日〜10月25日で、取得時点で対応中だった1件（10月25日8時17分UTCに掲載されたFable 5.1のエラー）を含む。「お金まわり」などの分類は、件名をもとに筆者が付けた。10月7日の件で何組織が何分止まったか、どのエラーが返ったか、Bedrockなど他社クラウド経由の利用に影響があったかは公表されていない。筆者は自分のアカウントで支出上限のエラーを再現していない。記事中のコードはすべて未実行。
数字で見るClaudeの55日
| 項目 | 値 |
|---|---|
| 集計期間 | 2026年9月1日〜10月25日（55日） |
| 公式ステータスに載った障害 | 26件（うち10月が13件） |
| モデル・APIのエラー | 16件（16件すべてに「Claude API」のコンポーネントが付く） |
| お金まわり（クレジット、利用量、支出上限、サブスク） | 5件（「Claude API」が付いたのは1件だけ） |
| 影響度「none」 | 2件（2件ともお金まわりで、コンポーネント0個） |
| 影響度「critical」 | 1件（10月23日23時28分〜59分UTC、Fable 5.1・Sonnet 5.5・Haiku 5.5） |
| いちばん長い記録 | 6日4時間35分（10月7日〜13日、Consoleのエラー） |
| 10月23日23時28分〜25日8時17分（UTC） | 約33時間でモデルのエラーが5件 |
| ステータスページのコンポーネント | 6個（Claude Securityの項目はない） |
| API組織の月間支出上限（ティア） | Start 500ドル、Build 1,000ドル、Scale 200,000ドル |
お金まわりの5件は、記録のされ方がモデルのエラーとまるで違う。モデル・APIのエラーは16件中14件が影響度majorかcriticalで、どれにも「Claude API」が付く。お金まわりは5件中2件が影響度noneでコンポーネント0個、残る3件のうち2件はConsoleしか付いていない。
ここまでは記録の話。面白いのは、止まり方のほうだ。
1つの判定が、なぜ5製品をまとめて止めるのか
モデルより手前に「財布の門番」がいる
Claudeへの要求は、モデルに届く前に組織ごとの判定を通る。レート制限のドキュメントは、制限を2種類に分けている。月にいくらまで使えるかを決める支出上限と、1分あたりの要求数などを決めるレート制限だ。API組織には、ティアごとの月間上限（Startなら500ドル）と、自分で決める上限がある。
利用量に応じて払うEnterpriseプランでは、ClaudeのアプリとClaude Codeが同じクレジットを使う。サポート記事はこう書いている。
Your credits draw down as your team uses Claude and Claude Code.
When the balance hits zero, usage stops for the whole organization until an Owner purchases more.
製品は5つでも、財布と門番は組織に1つ。門番が「この組織は上限に達した」と判断すれば、APIもアプリもClaude Codeも同時に止まる。10月7日に5製品がまとめて止まったのは、この構造と整合する。Anthropicは原因を公表していないので、ここは筆者の推測だ。
# 課金の門番の一般的な形（筆者の擬似コード。Anthropicの実装ではない・未実行）
def handle(request):
org = resolve_org(request.credential) # API鍵でもアプリのログインでも、最後は組織に行き着く
billing = billing_state.get(org.id) # 集計済みの利用額と「停止」フラグ
if billing.paused: # 10月7日は、ここが誤って立ったと考えられる
return spend_limit_error(org) # 400か429。モデルは呼ばれない
if not rate_limiter.allow(org, request.model):
return rate_limit_error() # 429。retry-afterが付く
return call_model(request) # 529や5xxが起きるのはここ
モデルが元気でも、門番が「止めろ」と言えばそこで終わる。
門番が見ている金額は「少し前の集計」
Claude Platform on AWSのドキュメントは、上限の判定についてこう書いている。
Spend is calculated at list prices and can take about 2 hours to reflect recent usage, so usage can exceed the cap or a limit before requests start failing.
門番は、要求のたびに請求額を数え直しているわけではない。別の仕組みが集計した利用額を見て判断している（これはAWS版の説明で、直接契約のAPIでも同じかは書かれていない）。集計が遅れたり数え間違えたりすれば、門番の答えも狂う。
10月7日には、門番の周りで3件の記録が並ぶ。
| 時刻（UTC） | 件名 | 書かれている影響 |
|---|---|---|
| 10月7日 0:00〜1:40 | Elevated errors loading usage data on platform.claude.com | 利用量のページと、Admin APIの利用量レポートがエラー |
| 10月7日 13:25掲載〜13日 18:00解決 | Elevated errors on platform.claude.com | Consoleのエラー（詳細の記載なし） |
| 10月7日 21:23掲載 | Issue with spend limits | 一部の組織を上限到達と誤って判定し、5製品で要求を拒否 |
3件が関係しているかどうかは、どこにも書かれていない。ただ、同じ日に「利用量の集計」「Console」「支出上限の判定」が続けて記録されている。あなたの予想もコメントで教えてほしい。
返ってくるエラーは主に2種類。どちらも「障害」に見えない
エラーの説明ページとレート制限のページによると、支出上限で止まったときの応答は、どの上限に当たったかで変わる。
| 当たった上限 | HTTP | error.type |
見分け方 | 戻るのは |
|---|---|---|---|---|
| ティアの月間上限 | 429 | rate_limit_error |
error.details.error_code が enforced_spend_limit_reached。retry-after は付かない |
翌月1日0時（UTC。日本時間は9時） |
| 自分で決めた上限（組織・ワークスペース） | 400 | invalid_request_error |
メッセージが You have reached your specified で始まる |
上限を上げたとき、またはメッセージに書かれた日時 |
| Claude Codeワークスペースの上限 | 429 | rate_limit_error |
retry-after が付く |
retry-after の秒数のあと |
ティア上限の429について、ドキュメントは念を押している。
Retrying, including the SDK's automatic retries, fails until access resumes.
レート制限と同じ型の429なのに、待っても戻らない。自分で決めた上限のほうは、リクエストの書き間違いと同じ400で返る。どちらも、監視の上では「障害」に見えない。
10月7日の組織にどちらが返ったのかは、公表されていない。
公式の自動回復4機能は、どれも門番を見ていない
| 機能 | 公式ドキュメントが書く対象 | 支出上限の停止には |
|---|---|---|
| SDKの自動リトライ | 接続エラー、レート制限、5xxなどを既定で2回まで再試行 | 400は対象に含まれない。ティア上限の429は再試行しても失敗 |
| Claude Codeのフォールバックモデル | 過負荷、利用不可、再試行できないサーバーエラー | 課金のエラーでは切り替わらない |
APIの fallbacks（サーバー側） |
安全分類器による拒否だけ | 対象外 |
| SDKの拒否用ミドルウェア | 拒否された要求だけ | 対象外 |
Claude Codeのモデル設定のドキュメントは、はっきり書いている。
Authentication, billing, rate-limit, request-size, and transport errors, and a denial by your organization's policy check, never trigger a switch; those follow their normal retry and error handling.
APIの fallbacks については、拒否とフォールバックのページにこうある。
Only a safety classifier decline triggers the fallback. A rate limit, overload, or server error on the requested model is returned to you as-is.
名前に「fallback」と付いていても、障害対策の機能ではない。
4つとも、門番に止められた要求を救う仕組みではない。
他社でも、お金まわりは止まる
これはAnthropicだけの話ではない。
| 時期 | どこで | 何が起きたか |
|---|---|---|
| 2025年6月12日 | Google Cloud | クォータと方針を確かめるService Controlに追加した方針チェックが、空欄のデータでnullポインタを踏み、クラッシュを繰り返した（約7時間半） |
| 2026年10月9日〜12日、14日〜16日 | OpenAI | Compliance APIのCostsデータが遅延（2件） |
| 2026年9月1日〜10月7日 | Anthropic | クレジットの購入・反映の遅延（2件）、利用量データのエラー、支出上限の誤判定 |
Googleの障害報告は、原因をこう書いている。
The issue with this change was that it did not have appropriate error handling nor was it feature flag protected.
上限やクォータの判定は、使いすぎから利用者を守るためにある。そして、全員の要求の通り道にある。だから壊れたときは、モデルが元気でも全部止まる。
なお、Anthropicは何組織が何分止まり、どのエラーが返ったかを公表していないので、この節の仕組みは公開文書から組み立てた推測だ。
今すぐやるべき4つのこと
1. 本番の鍵が、どのワークスペースで数えられるかを確かめる
エラーの説明ページにある curl -i の例を、安いモデルに変えて送る。応答ヘッダーの anthropic-workspace-id が、その鍵が数えられるワークスペースだ。
# 応答ヘッダーから、ワークスペースとレート制限の残りを見る（未実行）
curl -sS -i https://api.anthropic.com/v1/messages -H "x-api-key: $ANTHROPIC_API_KEY" -H "anthropic-version: 2023-06-01" -H "content-type: application/json" -d '{"model": "claude-haiku-5-5", "max_tokens": 16, "messages": [{"role": "user", "content": "ping"}]}' | grep -i -E "^(anthropic-workspace-id|anthropic-ratelimit|request-id)"
確かめたら、ConsoleのBilling（platform.claude.com/settings/billing）で支出上限を、Rate limits（platform.claude.com/usage/limits）でティアを見る。既定のワークスペースには支出上限を付けられないので、本番は専用のワークスペースに分けて、上限を個別に付けるのが基本だ。
ティア上限に当たると、戻るのは翌月1日の0時（UTC）、日本時間なら1日の9時だ。上のティアに上げてもらわない限り、月の前半に当たれば数週間止まる。
2. エラーを「名前」で分けて記録する
# 課金まわりのエラーを、ほかのエラーと分ける（未実行）
import anthropic
def classify(e: anthropic.APIStatusError) -> str:
body = e.body if isinstance(e.body, dict) else {}
err = body.get('error') or {}
msg = err.get('message') or ''
code = (err.get('details') or {}).get('error_code')
if e.status_code == 429 and code == 'enforced_spend_limit_reached':
return 'spend_cap' # ティアの月間上限。翌月1日0時(UTC)まで戻らない
if e.status_code == 400 and msg.startswith('You have reached your specified'):
return 'own_limit' # 自分で決めた上限（組織かワークスペース）
if e.status_code == 402:
return 'billing' # 支払い情報の問題
if e.status_code in (429, 529) or e.status_code >= 500:
return 'transient' # 待てば戻る可能性がある
return 'request_bug' # リクエスト側を直す
公式のエラーの説明ページは、メッセージの文字列ではなく、SDKの例外の型で捕まえるよう勧めている。ただし、自分で決めた上限の400をほかの400と見分ける手がかりは、ドキュメント上このメッセージの書き出ししかない。
3. Claude Codeの逃げ道を1本作っておく
Claude Code on Amazon Bedrockのドキュメントどおりに、Bedrock経由へ切り替えられるようにしておく。請求はAWSに移り、Anthropicの組織の支出上限は関係なくなる。
# 対話式のウィザードで切り替える
claude
# ログイン画面で「3rd-party platform」→「Amazon Bedrock」を選ぶ
# すでにログイン済みなら、Claude Codeの中で次を実行する
/setup-bedrock
# CIなどで、環境変数で切り替える場合
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1 # 自分のリージョンに変える
ウィザードは、自分のアカウントで呼べるモデルを確かめてから固定してくれる。Bedrock経由ではWebSearchツールが使えない点だけは覚えておくこと。Google Cloudなら CLAUDE_CODE_USE_VERTEX=1、Microsoft Foundryなら CLAUDE_CODE_USE_FOUNDRY=1 が入口になる。
4. ステータスは自分で数え、Atomで購読する
# 9月1日以降の障害を「日付・影響度・コンポーネント数・件名」で並べる（未実行）
curl -s https://status.claude.com/api/v2/incidents.json | jq -r '.incidents[] | select(.created_at >= "2026-09-01") | [.created_at[0:10], .impact, (.components | length), .name] | @tsv'
# 影響度ごとの件数
curl -s https://status.claude.com/api/v2/incidents.json | jq '[.incidents[] | select(.created_at >= "2026-09-01")] | group_by(.impact) | map({impact: .[0].impact, count: length})'
このAPIが返すのは直近の記録だけなので、長く集計したいなら自分で保存しておくこと。購読は https://status.claude.com/history.atom でできる。ただし、10月7日の件のようにコンポーネントが付かない記録もある。監視の本体は、自分のリクエストの成功率と、エラーの名前ごとの件数にすること。
知らないと損する5つの罠
罠1：支出上限の400を「自分のバグ」として捨てる
レート制限のページは、自分で決めた上限についてこう書く。
When usage reaches a spend limit you set, requests return HTTP 400 with error type
invalid_request_error.
400は、ふつう「送った側のバグ」として扱われる。再試行しない、予備に逃がさない、通知は当番ではなく開発者のチケットに回る。上限で止まっていても、誰も気づかないまま全件が失敗し続ける。
対策：400のうち、メッセージが You have reached your specified で始まるものだけは、課金の停止として当番に通知すること。
罠2：ティア上限の429を「待てば戻る」と思う
{
"type": "error",
"error": {
"type": "rate_limit_error",
"message": "You have reached your API usage limits: your organization has crossed its monthly API usage threshold, set based on your organization's API tier. You will regain access on 2026-09-01 at 00:00 UTC.",
"details": { "error_code": "enforced_spend_limit_reached" }
},
"request_id": "req_018EeWyXxfu5pfWkrYcMdjWG"
}
公式ドキュメントに載っている応答の例だ。型はレート制限と同じ rate_limit_error だが、retry-after は付かない。バックオフで待ち続けるジョブは、翌月1日まで詰まったままになる。
対策：enforced_spend_limit_reached を見たら再試行をやめ、予備の経路に切り替えるか、ティアの引き上げを頼むこと。
罠3：fallbacks を障害対策だと思う
APIの fallbacks が動くのは、安全分類器が要求を断ったときだけだ。しかも、Amazon Bedrock、Google Cloud（Google managed）、Microsoft Foundryは、この機能自体に対応していない。モデルが過負荷でも、支出上限で止まっても、fallbacks を入れたリクエストはそのまま失敗する。
モデルの過負荷に備えるなら、Claude Codeではドキュメントどおりにこう指定する。
# 主モデルが過負荷、利用不可、再試行できないサーバーエラーのとき順に切り替える（課金のエラーでは切り替わらない）
claude --fallback-model sonnet,haiku
対策：モデルの障害にはClaude Codeやクライアント側のフォールバック、課金の停止には請求が別の経路。役割を分けて用意すること。
罠4：ステータスページのコンポーネントで監視する
"components": []
10月7日の記録には、コンポーネントが1つも付いていない。ステータスページのコンポーネントは6個で、要求が拒否されたClaude Securityの項目はそもそもない。Bedrockなど他社クラウドの状態も載っていない。
対策：自分の組織の鍵で数分おきに小さな要求を送る合成監視と、エラーの名前ごとの件数で警報を出すこと。
罠5：クレジットを残高ぎりぎりで買い足す
支払いのサポート記事には「Purchased credits are available immediately.」とある。ところが、ステータスには55日で2件、クレジットの遅れが載っている。
| 件名 | 記録の作成〜解決（UTC） |
|---|---|
| Delays in credit purchases | 9月1日 23:26〜9月2日 1:24（約2時間） |
| Delayed credits on the Claude Platform | 10月1日 16:20〜22:36（約6時間16分） |
残高ゼロで買い足し、その反映が遅れれば、その間は止まる。前払いのEnterpriseプランなら、残高ゼロで組織全体が止まる。
対策：Billingの自動チャージ（auto-reload）を設定し、しきい値に余裕を持たせること。
請求が別の経路5選
公式ドキュメント（2026年10月25日時点）とOpenRouterのAPIから、Claude Sonnet 5.5を「Anthropicの請求」以外で呼べる経路をまとめた。
| 経路 | 推論を動かすのは | 請求 | 上限・クォータ | Sonnet 5.5のID | Claude Codeの切り替え |
|---|---|---|---|---|---|
| Amazon Bedrock | AWS | AWSの請求 | Bedrockのクォータ（既定は入力200万トークン/分） | anthropic.claude-sonnet-5-5 |
CLAUDE_CODE_USE_BEDROCK=1 |
| Google Cloud（Google managed） | Google Cloudの請求 | Google Cloudのクォータ | claude-sonnet-5-5 |
CLAUDE_CODE_USE_VERTEX=1 |
|
| Microsoft Foundry | Anthropic（Azure上かAnthropic上を選ぶ） | Azure Marketplace | Azure側で管理 |
claude-sonnet-5-5（デプロイ名） |
CLAUDE_CODE_USE_FOUNDRY=1 |
| Claude Platform on AWS | Anthropic | AWS Marketplace | Anthropicと同じティア上限 | claude-sonnet-5-5 |
CLAUDE_CODE_USE_ANTHROPIC_AWS=1 |
| OpenRouter | 8つのエンドポイントに振り分け | OpenRouterの残高 | OpenRouterの制限 | anthropic/claude-sonnet-5.5 |
未確認 |
表から読み取れること：
- 推論も請求も別の会社なのは、BedrockとGoogle managedの2つだけ。 どちらもAnthropicの組織や請求を通らない。ただし、モデル側の障害まで避けられるかは公表されていない。
- Claude Platform on AWSは、請求がAWSでも上限はAnthropicのティアと同じ。 ドキュメントは「The same monthly spend caps apply」と書く。Anthropic側の判定が誤作動したときの予備になるかは、わからない。
- 日本から使うなら、Bedrockの東京リージョン（ap-northeast-1）に、Global・JP・リージョン内の3種類の入口がある。 Google managedは、新しいモデルではリージョン指定ができず、globalかus・euのマルチリージョンだけだ。
- OpenRouterは、既定ではどのエラーでもフォールバックが動きうる。 ドキュメントは「By default, any error can trigger the use of a fallback model」と書く。課金のエラーも対象に入る。
-
予備の経路では使えない機能がある。 BedrockとGoogle managedは、どちらもFiles API、コード実行、web fetch、Agent Skills、Message Batches、Admin・利用量のAPI、
fallbacksに対応していない。予備に回すリクエストは、これらを使わない形にしておくこと。
OpenRouterのエンドポイントAPI（10月25日取得）に載っていたClaude Sonnet 5.5の提供元と単価はこうだ。
| 提供元（OpenRouterのタグ） | 入力 / 出力（100万トークンあたり） |
|---|---|
| Anthropic（anthropic） | 2ドル / 10ドル |
| Amazon Bedrock（amazon-bedrock） | 2ドル / 10ドル |
| Google（google-vertex/global） | 2ドル / 10ドル |
| Azure（azure/global） | 2ドル / 10ドル |
| Claude Platform on AWS（claude-on-aws） | 2ドル / 10ドル |
| Google（google-vertex/us、google-vertex/europe） | 2.2ドル / 11ドル |
| Azure（azure/us） | 2.2ドル / 11ドル |
globalで呼ぶ限り、どの財布でも単価は同じだ。地域を固定すると1割高くなる。これは、BedrockとGoogle Cloudのドキュメントにある「リージョン指定は10%増し」とも一致する。
コピペで使える「請求が別の経路」への切り替え
# 請求が別の経路へ逃がす例（擬似コードを含む・未実行）
import anthropic
primary = anthropic.Anthropic() # Claude API（Anthropicの請求）
backup = anthropic.AnthropicBedrockMantle(aws_region='us-east-1') # Bedrock（AWSの請求）
def create(**kw):
try:
return primary.messages.create(model='claude-sonnet-5-5', **kw)
except anthropic.APIStatusError as e:
kind = classify(e) # 「今すぐやるべきこと」2の関数
if kind in ('spend_cap', 'own_limit'):
# 本当に上限なのかを、自分の帳簿（応答のusage×定価の合計）で確かめる
if ledger.month_to_date_usd() >= MY_LIMIT_USD:
notify('本物の上限。予備には逃がさない')
raise
notify('上限に届いていないのに止められた。誤判定の可能性')
elif kind not in ('billing', 'transient'):
raise # リクエスト側の問題は逃がさない
return backup.messages.create(model='anthropic.claude-sonnet-5-5', **kw)
自分の帳簿を見るのには理由がある。Anthropicの集計は定価で計算され、最近の利用が反映されるまで時間がかかる（AWS版のドキュメントでは約2時間）。応答の usage を定価で足し上げた自分の帳簿のほうが、たいてい先に進んでいる。その帳簿で上限に届いていないのに「上限に達した」と返ってきたら、誤判定を疑う根拠になる。usage の形は、Claude API、Bedrock、Google Cloud、Foundryで共通だ。
教訓：モデルが元気でも、財布で止まる
✗ "ステータスページが緑なら、自分も大丈夫" → 10月7日の記録は impact: none、components: []
✗ "400はこちらのリクエストのバグ" → 自分で決めた支出上限も400で返る
✗ "429は待てば戻る" → ティア上限の429は翌月1日0時(UTC)まで戻らない
✗ "fallbacksを入れたから障害に強い" → 対象は安全分類器による拒否だけ
✗ "止まるのはモデルが落ちたときだけ" → 55日26件のうち5件はお金まわり
LLMの障害対策は、モデルが落ちることを前提に作られてきた。リトライ、フォールバック、別モデルへの切り替え。どれも門番を通ったあとの話だ。10月7日に止まった組織は、門番そのものに止められた。
上限は、使いすぎから会社のお金を守るためにある。だから本物の上限なら、止まるのが正しい。問題は、本物かどうかを自分で確かめる手段を持っていないことだ。今日のうちに、課金のエラーを名前で拾うコードと、請求が別の経路を1本だけ用意してほしい。
参考リンク
Issue with spend limits - Claude Status
Claude Status API（incidents.json）
Claude Status API（components.json）
Claude Status - Incident History（Atom）
Claude API errors - Claude Docs
Rate limits - Claude Docs
Refusals and fallback - Claude Docs
Claude Platform on AWS - Claude Docs
Claude in Amazon Bedrock - Claude Docs
Claude Models on Google Cloud (Google managed) - Claude Docs
Claude in Microsoft Foundry - Claude Docs
Models overview - Claude Docs
Usage-based Enterprise plans - Claude Help Center
How do I pay for my Claude API usage? - Claude Help Center
Claude Code on Amazon Bedrock - Claude Code Docs
Model configuration - Claude Code Docs
Environment variables - Claude Code Docs
Claude Sonnet 5.5 endpoints - OpenRouter API
Model Fallbacks - OpenRouter Docs
Google Cloud Service Health - 2025年6月12日の障害報告
OpenAI Status API（incidents.json）
この記事が役に立ったら、いいねと保存を！ 次に止まる前に、Claude APIやClaude Codeを本番で回しているチームにもシェアしてあげてほしい。
コメントで教えてほしい。
- 10月7日ごろ、上限に届いていないのにClaudeが止まった？ 返ってきたのは400？ それとも429？
- 本番のClaude、予備の経路はどこにしてる？ Bedrock、Google Cloud、Foundry、OpenRouter、それともなし？
- 上限のエラーが出たら、自動で逃がす派？ 止める派？