Claude CodeでDeepSeekのInput length exceeds maximumが出たときの復旧手順
まずdiffと作業状況をモデルの外に保存し、目的を絞った/compactを試します。それも失敗する場合はcheckpointか空のセッションで復旧し、実際のモデル、gateway、早期compactの設定を確認します。
目次
Claude Codeで短い指示を追加しただけなのに、status_code=400, Input length 1048609 exceeds the maximum length 1048566. と返ってくることがあります。同じリクエストを繰り返したり、「43文字だけ削れば直る」と考えたりしないでください。安全な順序は、コードと作業状況をモデルの外に保存し、目的を絞った /compact を試し、compact自体が失敗するならcheckpointまたは空のセッションへ移り、その後でモデル・Claude Code・中間gatewayのどこが拒否したかを切り分けることです。
このエラーから分かるのは、どこかの層が入力を上限より43単位大きいと判断したことだけです。単位がtoken、文字、byteのどれかは示されていません。また、リクエストがDeepSeekまで到達した証拠にもなりません。実際のmodel ID、Base URL、Claude Codeのバージョン、proxy経路、元のresponse headerがなければ、特定のモデル障害とは断定できません。
次のモデル呼び出しより先に作業を保全する
まず、上限を超えた会話からの再送を止めます。 コード変更は通常すでにディスクへ書き込まれています。失いやすいのは、「どこまで変更したか」「何を確認したか」「次に何をする予定だったか」という会話内だけの情報です。
別のterminalを開き、モデルに要約させずに現在の状態を保存します。
claude --version
git status --short
git diff --stat
git diff > claude-context-recovery.patch
git diff --cached > claude-context-recovery-staged.patchGitを使っていない場合は、変更済みファイルをコピーするか、editorのlocal historyでsnapshotを作ってください。続いて、短い RECOVERY.md を手作業で作ります。
目的：
変更したファイル：
確認済み：
未解決：
重要な判断：
次に行う一つの作業：
再読込しないもの：完全なlog、repository全体、無関係な履歴きれいな文書である必要はありません。新しいセッションが数段落だけで作業を再開できれば十分です。数十万tokenの履歴を戻すことが目的ではありません。
診断情報を共有するときは、claude --version、model ID、Base URLのdomain、proxy名、正確なerrorだけに絞ります。API Key、認証header、業務prompt全文、credentialを含む環境変数は表示しないでください。
似たエラーでも上限の種類は違う
最初に元のerror文を確認します。上限の種類が違えば対処も変わります。
| エラーの形 | 考えられる意味 | 最初の対応 |
|---|---|---|
Input length X exceeds the maximum length Y | ある層が入力またはrequest長を制限している。単位はtokenとは限らない | 履歴とtool outputを減らし、拒否した層を特定する |
input length and max_tokens exceed context limit: A + B > C | 入力と予約された出力を合わせてcontext budgetを超えた | 早めにcompactする。原因が確認できた場合だけ出力予算も見直す |
HTTP 413、request body too large | HTTP bodyまたはreverse proxyのbyte上限 | upload、encoding、proxyのbody-sizeを確認する |
All target providers failed などの一般化されたerror | gatewayがupstreamの具体的な原因を隠した可能性 | raw attempt、gateway log、request IDを調べる |
Claude Code #42 には、inputと max_tokens の合計がwindowを超えたという利用者報告があります。#8136 には、上限付近ではcompact要求自身の出力領域が必要なため /compact も失敗し得るという報告があります。どちらも個別の利用者報告であり、今回の環境の原因を証明するものではありません。
したがって、差が43だからといってvisible textを43文字だけ削るのは危険です。Claude Codeはsystem instruction、会話履歴、tool definition、ファイル内容、tool resultも送ります。境界ぎりぎりを狙わず、十分な余白を作ってください。
分岐A：/compact がまだ実行できる場合
slash commandが動くなら、まず使用量を見て、残す情報を指定してcompactします。
/context次に、compactの対象を明確にします。
/compact 現在の目的、変更済みファイル、確認済み結果、重要な判断、未解決事項、次の作業を残す。完全なlog、重複したファイル内容、破棄した方針、無関係な議論は削除する。compact後にrepository全体をすぐ読み直してはいけません。小さく、結果を確認できる依頼で復旧状態を確かめます。
RECOVERY.mdとsrc/auth/session.tsだけを読む。次に変更すべき関数を説明する。他のdirectoryは探索せず、ファイルも変更しない。復旧できたと判断する目安は次の4点です。
/contextの使用量が明確に下がっている。- 小さなrequestが400を返さない。
- モデルが目的、変更ファイル、次の作業を正しく説明できる。
git diffとtest結果がRECOVERY.mdの内容と一致している。
compactでは細部が落ちることがあります。長期的なproject ruleはrootの CLAUDE.md に置き、重要な作業状態は会話だけでなくファイルにも残してください。
分岐B：/compact もConversation too longまたは同じ400になる場合
同じ巨大な履歴に対して /compact を繰り返さないでください。 Claude Code #26317 には、通常requestが上限に達した後、compactも Conversation too long になったという利用者報告があります。issueがnot plannedで閉じていることは、すべてのversionや互換endpointで解消済みという意味ではありません。
大きなlogやtool outputを入れる前まで戻す
公式の checkpointingガイド では、/rewind を実行するか、入力欄が空の状態で Esc を2回押してcheckpointを選べます。主な選択肢は次のとおりです。
- Restore conversation：会話だけを戻し、現在のcodeは維持する。
- Summarize from here：選択地点より後のmessageを要約する。
- Summarize up to here：選択地点より前を圧縮し、後のmessageを残す。
完全なlogを貼る前、大きなファイルを読む前、異常に大きいtool resultが入る前のcheckpointを選びます。codeを維持したまま会話を戻し、より狭いtaskを送る方が、すでにoverflowした末尾をさらに要約するより安全です。
ただし、summary作成もmodel callを必要とする場合があります。upstreamがそのcallも拒否するなら、空のcontextへ移ります。
rewindでも戻れない場合は /clear または新規セッションを使う
/clear公式の command reference によると、/clear は空のcontextで新しい会話を始め、以前のsessionは保存したままにします。ディスク上のファイルやGit diffは消えません。
新しいsessionの最初の指示は小さく限定します。
RECOVERY.md、git diff --stat、そこに記載された2ファイルだけを読む。まず現在の状態を確認する。repository全体は探索しない。次の一手だけを提案し、承認されるまで変更しない。すぐに claude --continue、claude --resume、/resume を使わないでください。公式の sessionガイド では、resumeは履歴とtool resultを完全に復元します。その履歴がoverflowの原因なら、次のmodel requestも再び失敗します。
4つの低コストテストで拒否した層を特定する
作業を保全した後は、1回のテストで1つの条件だけを変えます。同じ小さなread-only taskをcontrolとして使ってください。
| テスト | 結果 | 有力な解釈 |
|---|---|---|
| 同じendpointとmodel、空のsession、小さなtask | 成功 | 古いsessionの累積履歴または大きなtool outputが原因の可能性が高い |
| 空のsessionでも同じ小さなtaskが失敗 | 失敗 | model mapping、request envelope、client version、server-side capを確認する |
| 許可されている場合、公式endpointとgatewayを比較 | 直接は成功、gatewayは失敗 | gatewayのlimit、変換、error aggregationを調べる |
/compact は失敗するが /clear 後の小さなtaskは成功 | 成功 | compact要求が実windowを超えた、またはclientがwindowを誤認した可能性 |
secretを出さずにrouting値を記録します。
printf 'BASE_URL=%s\nMODEL=%s\nOPUS=%s\nSONNET=%s\nHAIKU=%s\nSUBAGENT=%s\n' \
"${ANTHROPIC_BASE_URL:-<unset>}" \
"${ANTHROPIC_MODEL:-<unset>}" \
"${ANTHROPIC_DEFAULT_OPUS_MODEL:-<unset>}" \
"${ANTHROPIC_DEFAULT_SONNET_MODEL:-<unset>}" \
"${ANTHROPIC_DEFAULT_HAIKU_MODEL:-<unset>}" \
"${CLAUDE_CODE_SUBAGENT_MODEL:-<unset>}"このcommandは意図的に ANTHROPIC_AUTH_TOKEN を表示しません。Claude Code Router、switcher、社内gateway、reverse proxy、multi-provider fallbackを経由しているかも記録してください。
Claude Code Router #1799 では、gatewayがupstreamのcontext errorを All target providers failed に置き換えたという利用者報告があります。報告者のlocal patchは一般的なproduction fixではありません。ただし、support logにupstream status、body、request IDを残す必要性は分かります。
[1m] 表記ではなく実際のDeepSeek routeを確認する
2026年9月30日時点で、DeepSeek公式の Claude Code連携ページ にあるクライアント側の環境変数例は、次の値を設定しています。
ANTHROPIC_MODEL、ANTHROPIC_DEFAULT_OPUS_MODEL、ANTHROPIC_DEFAULT_SONNET_MODEL：deepseek-flash[1m]ANTHROPIC_DEFAULT_HAIKU_MODEL、CLAUDE_CODE_SUBAGENT_MODEL：deepseek-flashCLAUDE_CODE_AUTO_COMPACT_WINDOW=786432
同じページは別項目で、Claude形式のmodel名を渡した場合のサービス側mappingも説明しています。claude-opus で始まる名前は deepseek-v4-pro に、claude-haiku または claude-sonnet で始まる名前は deepseek-flash にmapされます。このサービス側の規則と、上のクライアント例に明記された値は別の事実であり、実際のrouteに関する一つの結論として混同できません。
どちらの記述からも、今回のcustomer requestを最終的に処理したmodelやcontext windowは確定できません。利用可能なrequest/usage記録、元の model field、選択されたprovider/route、upstream request IDを確認し、UIや古いtutorialだけから推測しないでください。
[1m] というlabelも、経路上のすべての層が100万tokenを受け付ける保証ではありません。client、compatibility API、gateway、fallback provider、最終modelはそれぞれ別のlimitを持ち得ます。予約されたoutputもcontextを使用します。
windowを大きく見せるのではなく早めにcompactする
現在のDeepSeek例には次の値があります。
export CLAUDE_CODE_AUTO_COMPACT_WINDOW="786432"これはclient側でcompactを始めるthresholdであり、providerのhard limitを拡張する設定ではありません。Claude Code公式の environment variable reference では、plain integerを指定し、model context window以下に制限され、/autocompact、launch flag、settingsより優先されると説明されています。
実際のmodelまたはgatewayがもっと小さいなら、確認済みの小さな値を設定してください。CLAUDE_AUTOCOMPACT_PCT_OVERRIDE はcompactを早めるためのもので、windowを広げるものではありません。
CLAUDE_CODE_MAX_CONTEXT_TOKENS も「contextを解放するswitch」ではありません。custom routeや未認識modelの実際に確認済みのwindowをClaude Codeへ伝える設定です。serverのcapより大きい値を入れるとcompactが遅れ、upstream 400を起こしやすくなります。
日常的には次の対策が有効です。
- 大きなlogは
grep、rg、tail、scriptで絞ってから渡す。 - 大きなファイルは関数単位またはline rangeで読む。
- 無関係なtaskの間では
/clearを使う。 - 広い調査はsubagentへ渡し、main sessionには要約だけ戻す。
- 新しいphaseへ入る前に目的を指定した
/compactを実行する。 - 同じschema、完全なbuild log、全diffを何度も貼らない。
小さな実taskで復旧を確認する
復旧または設定変更後は、次の順序で再テストします。
- 空のsessionを開始する。
RECOVERY.mdと小さな1ファイルだけ読む。- 短く上限を決めた回答を求める。
- 400が消えたことを確認する。
- ファイルとtool callを少しずつ追加する。
小さなrequestでも失敗するなら、古い会話を削る作業は止め、endpoint、model mapping、proxy behavior、request formatを調査します。長いsessionだけ失敗するなら、compactのタイミング、tool outputの大きさ、task間のsession分離を見直してください。
よくある質問
Claude Codeを再起動しても直らないのはなぜですか
再起動が空の履歴を意味するとは限りません。--continue、--resume、session pickerは古い会話を戻します。原因を切り分けるには、本当に新しいsessionと小さなcontrol requestが必要です。
output tokenを減らせば直りますか
errorがinputと max_tokens の合計超過を明示している場合に限って有効です。input単体の独立limitなら、outputを減らしても保証はありません。
gatewayを変えれば必ず解決しますか
いいえ。現在のgatewayが小さいbody limitを設定している、またはupstream errorを隠している場合には改善し得ます。しかし最終modelのhard context limitを超えることはできません。
/clear でcodeは消えますか
消えません。消えるのは会話contextであり、ディスクへ書かれたfileではありません。ただし実行前に git status、patch、commit、editor snapshotで確認してください。
なぜ43文字だけ消してはいけないのですか
単位が不明で、requestにはsystem content、tools、historyなどvisibleでない情報も含まれるからです。十分な余白を作る方が、境界ぴったりを狙うより確実です。
覚えておく復旧順序
Input length exceeds maximum が出たら、別terminalでdiffと手動handoffを保存 → /context → 目的を絞った /compact → 失敗したら大きなoutputより前へ /rewind → それでも失敗するなら /clear または新規session → 小さなcontrol taskでlimitの層を特定 → 確認済みserver windowより低い位置でauto compact、の順で進めます。
この方法は43という数字の単位を推測せず、proxyがmodelのhard limitを突破できるとも主張しません。まず既存の作業を守り、その後で曖昧な400を層ごとの再現可能な診断へ変えます。
