Claude Code में DeepSeek का Input length exceeds maximum आने पर session कैसे बचाएँ

आप Claude Code में केवल एक छोटा निर्देश जोड़ते हैं और जवाब मिलता है: status_code=400, Input length 1048609 exceeds the maximum length 1048566. उसी request को बार-बार न भेजें और यह न मानें कि 43 characters हटाने से समस्या निश्चित रूप से हल हो जाएगी। सुरक्षित तरीका यह है: code और task state को model से बाहर बचाएँ, focused /compact आज़माएँ, compact भी fail हो तो checkpoint या clean session पर जाएँ, और उसके बाद पता लगाएँ कि request को model, Claude Code या बीच के gateway ने अस्वीकार किया।

इस message से केवल इतना साबित होता है कि किसी layer ने input को अपनी maximum length से 43 अनिर्दिष्ट units अधिक माना। यह नहीं बताया गया कि unit token है, character है या byte। यह भी सिद्ध नहीं होता कि request DeepSeek तक पहुँची थी। Actual model ID, Base URL, Claude Code version, proxy chain और raw response के बिना error को किसी खास model defect से जोड़ना सही नहीं होगा।

अगली model call से पहले अपना काम सुरक्षित करें

Over-limit conversation से retry करना पहले बंद करें। Code changes आम तौर पर disk पर लिखे जा चुके होते हैं। असली जोखिम उस जानकारी का है जो केवल chat में है: क्या बदला, क्या verify हुआ और अगला step क्या था।

दूसरा terminal खोलें और model से summary माँगे बिना state save करें:

claude --version
git status --short
git diff --stat
git diff > claude-context-recovery.patch
git diff --cached > claude-context-recovery-staged.patch

अगर project Git repository नहीं है, तो modified files की copy बनाएँ या editor के local history से snapshot लें। फिर हाथ से छोटा RECOVERY.md बनाएँ:

लक्ष्य:
बदली गई files:
क्या verify हो चुका है:
क्या अभी fail हो रहा है:
मुख्य फैसले:
अगला केवल एक step:
दोबारा load न करें: पूरे logs, पूरा repository, असंबंधित history

यह handoff सुंदर होना जरूरी नहीं है। इसका उद्देश्य clean session को कुछ paragraphs से काम शुरू करवाना है, न कि पुराने सैकड़ों हजार tokens फिर से लाना।

Diagnostic जानकारी में केवल non-secret values रखें: claude --version, model ID, Base URL का domain, proxy का नाम और exact error। API Key, authorization header, पूरा business prompt या credentials वाली environment variables को print न करें।

Fix चुनने से पहले limit का प्रकार पहचानें

एक जैसे दिखने वाले length errors अलग limits के कारण आ सकते हैं।

Error का रूप	संभावित अर्थ	पहला action
Input length X exceeds the maximum length Y	किसी layer ने input या request length पर cap लगाया; unit token होना जरूरी नहीं	History और tool output कम करें, फिर rejecting layer खोजें
input length and max_tokens exceed context limit: A + B > C	Input और reserved output मिलकर context budget से बाहर हैं	पहले compact करें; output budget तभी घटाएँ जब यही कारण confirm हो
HTTP 413 या request body too large	HTTP body या reverse proxy की byte limit	Upload, encoding और proxy body-size जाँचें
All target providers failed जैसा generic wrapper	Gateway ने upstream cause छिपा दिया हो सकता है	Raw attempt, gateway logs और request ID देखें

Claude Code #42 में एक user ने input और max_tokens के combined context limit से बाहर जाने वाला 400 report किया था। #8136 में दूसरे user ने बताया कि limit के करीब /compact खुद fail हो सकता है, क्योंकि compact request को भी output space चाहिए। ये independent user reports हैं, आपके environment के root cause का प्रमाण नहीं।

इसीलिए 43 का अंतर देखकर exactly 43 visible characters हटाना पर्याप्त नहीं है। Claude Code system instructions, conversation history, tool definitions, file contents और tool results भी भेजता है। Boundary पर टिकने की बजाय पर्याप्त headroom बनाएँ।

Branch A: /compact अभी भी सफल हो सकता है

अगर slash commands चल रहे हैं, तो usage देखें और compact को साफ निर्देश दें कि क्या बचाना है।

/context

फिर focused compact चलाएँ:

/compact मौजूदा लक्ष्य, बदली गई files, verified results, मुख्य फैसले, unresolved issue और अगला action रखें। पूरे logs, repeated file contents, छोड़े गए branches और असंबंधित discussion हटाएँ।

Compact के बाद तुरंत पूरा repository scan न करवाएँ। छोटी और observable task से recovery check करें:

केवल RECOVERY.md और src/auth/session.ts पढ़ें। बताएं कि अगली बार कौन-सा function बदलना है। दूसरे directories scan न करें और files edit न करें।

Recovery को सफल मानने के लिए चार संकेत साथ मिलने चाहिए:

1. /context में usage स्पष्ट रूप से कम हो;
2. छोटी request अब 400 न लौटाए;
3. model लक्ष्य, changed files और next action सही बता सके;
4. git diff और test results handoff से मेल खाएँ।

Compact कुछ details छोड़ सकता है। स्थायी project rules को root CLAUDE.md में रखें और critical task state को केवल लंबी conversation में न छोड़ें।

Branch B: /compact भी Conversation too long या वही 400 देता है

उसी oversized history पर /compact बार-बार न चलाएँ। Claude Code #26317 में एक user ने report किया कि normal request limit पर पहुँचने के बाद compact भी Conversation too long देने लगा। Issue का not planned के रूप में बंद होना यह साबित नहीं करता कि हर version और compatible endpoint में behavior खत्म हो गया।

बड़े log या tool output से पहले के checkpoint पर लौटें

Official checkpointing guide के अनुसार आप /rewind चला सकते हैं, या input खाली होने पर Esc दो बार दबा सकते हैं। उपलब्ध actions में शामिल हैं:

• Restore conversation: conversation पीछे जाए, current code बना रहे;
• Summarize from here: selected checkpoint के बाद के messages summarize हों;
• Summarize up to here: पहले की history compact हो और बाद के messages बने रहें।

पूरे log paste करने, बहुत बड़ी file पढ़ने या असामान्य रूप से बड़े tool result से पहले वाला checkpoint चुनें। Code रखते हुए conversation पीछे करना और फिर छोटी request देना, पहले से overflow हुई tail को दोबारा summarize करने से बेहतर हो सकता है।

Summarization के लिए भी model call लग सकती है। अगर upstream यह call भी reject करे, तो empty-context recovery पर जाएँ।

Rewind काम न करे तो /clear या नई session लें

/clear

Official commands reference के अनुसार /clear empty context के साथ नई conversation शुरू करता है और पिछली session को saved रखता है। यह disk की files या Git diff को undo नहीं करता।

Clean session की पहली instruction सीमित रखें:

RECOVERY.md, git diff --stat और उसमें लिखी दो files ही पढ़ें। पहले current state verify करें। पूरा repository scan न करें। केवल अगला step सुझाएँ और edit से पहले approval का इंतज़ार करें।

तुरंत claude --continue, claude --resume या /resume न चलाएँ। Official session guide बताती है कि resume पूरी history और tool results वापस लाता है। अगर वही history overflow का कारण थी, तो अगली model call फिर fail हो सकती है।

चार low-cost tests से rejecting layer खोजें

काम सुरक्षित होने के बाद हर test में केवल एक variable बदलें और वही छोटी read-only task control के रूप में रखें।

Test	Result	सबसे उपयोगी interpretation
Same endpoint और model, clean session, tiny task	सफल	पुरानी session की accumulated history या बड़ा tool output अधिक संभावित
वही tiny task clean session में भी fail	विफल	model mapping, request envelope, client version या server-side cap जाँचें
जहाँ allowed हो, official endpoint और gateway compare करें	Direct सफल, gateway fail	Gateway limits, conversion और error aggregation जाँचें
/compact fail, लेकिन /clear के बाद tiny task सफल	सफल	Compact request वास्तविक window से बड़ी थी या client ने गलत window मानी

Secrets दिखाए बिना routing values record करें:

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 नहीं दिखाती। यह भी लिखें कि request Claude Code Router, switcher, corporate gateway, reverse proxy या multi-provider fallback से गुजरती है या नहीं।

Claude Code Router #1799 में एक user ने report किया कि gateway ने upstream context error को All target providers failed में बदल दिया। Reporter का local patch universal production fix नहीं है, लेकिन यह दिखाता है कि support logs को upstream status, body और request ID बचानी चाहिए।

केवल [1m] label नहीं, वास्तविक DeepSeek route जाँचें

30 सितंबर 2026 तक, DeepSeek की official Claude Code integration page के client environment-variable example में यह configuration है:

• ANTHROPIC_MODEL, ANTHROPIC_DEFAULT_OPUS_MODEL और ANTHROPIC_DEFAULT_SONNET_MODEL: deepseek-flash[1m]
• ANTHROPIC_DEFAULT_HAIKU_MODEL और CLAUDE_CODE_SUBAGENT_MODEL: deepseek-flash
• CLAUDE_CODE_AUTO_COMPACT_WINDOW=786432

उसी page का अलग mapping section बताता है कि Claude-style model name भेजे जाने पर DeepSeek service claude-opus से शुरू होने वाले नामों को deepseek-v4-pro और claude-haiku या claude-sonnet से शुरू होने वाले नामों को deepseek-flash पर map करती है। यह service-side mapping और ऊपर दिए client example की explicit values अलग facts हैं; इन्हें actual route का एक ही proof न मानें।

इनमें से कोई भी section यह साबित नहीं करता कि इस customer request को अंत में किस model या context window ने handle किया। Available request/usage records, raw model field, चुना गया provider/route और upstream request ID देखें; UI या पुराने tutorial से अनुमान न लगाएँ।

[1m] label भी यह guarantee नहीं करता कि route की हर layer एक million tokens स्वीकार करेगी। Client, compatibility API, gateway, fallback provider और final model अलग limits लगा सकते हैं। Reserved output भी context लेता है।

Window बढ़ा हुआ दिखाने के बजाय पहले compact करें

DeepSeek के current example में यह value है:

export CLAUDE_CODE_AUTO_COMPACT_WINDOW="786432"

यह client-side early-compaction threshold है, provider की hard limit बढ़ाने का तरीका नहीं। Claude Code की official environment-variable reference के अनुसार value plain integer होनी चाहिए, model context window से capped रहती है और /autocompact, launch flags तथा settings पर priority लेती है।

अगर actual model या gateway कम स्वीकार करता है, तो verified lower value रखें। CLAUDE_AUTOCOMPACT_PCT_OVERRIDE compaction को जल्दी शुरू करा सकता है; limit बढ़ा नहीं सकता।

CLAUDE_CODE_MAX_CONTEXT_TOKENS को “context unlock” switch न समझें। यह custom या unrecognized model route की verified real window Claude Code को बताता है। Server cap से बड़ी value compaction देर से शुरू कराएगी और upstream 400 की संभावना बढ़ाएगी।

रोज़मर्रा में ये आदतें अधिक मदद करती हैं:

• बड़े logs को grep, rg, tail या script से filter करें;
• बड़ी files को function या line range के अनुसार पढ़ें;
• unrelated tasks के बीच /clear चलाएँ;
• broad repository search subagent को दें और main session में केवल summary लाएँ;
• नई phase से पहले focused /compact करें, आखिरी tokens तक न रुकें;
• वही schemas, full build logs और complete diffs बार-बार न भेजें।

छोटी वास्तविक task से fix को दोबारा जाँचें

Recovery या configuration change के बाद:

1. clean session शुरू करें;
2. केवल RECOVERY.md और एक छोटी file पढ़ें;
3. short, bounded answer माँगें;
4. confirm करें कि 400 चला गया;
5. files और tool calls धीरे-धीरे बढ़ाएँ।

अगर tiny request भी fail हो, तो पुरानी conversation काटते रहने के बजाय endpoint, model mapping, proxy behavior और request format जाँचें। अगर केवल लंबी session fail हो, तो compaction timing, tool-output size और session boundaries पर ध्यान दें।

सामान्य प्रश्न

Claude Code restart करने से समस्या क्यों नहीं गई?

Restart हमेशा empty history नहीं बनाता। --continue, --resume और session picker पुरानी conversation वापस लाते हैं। Cause isolate करने के लिए सच में नई session और tiny control request चाहिए।

Output tokens घटाने से काम बनेगा?

केवल तब, जब error साफ कहे कि input और max_tokens मिलकर combined context budget पार कर रहे हैं। Input की अलग limit हो तो output घटाना guaranteed fix नहीं है।

Gateway बदलने से हमेशा समाधान होगा?

नहीं। Current gateway छोटा body limit लगाता हो या upstream error छिपाता हो तो दूसरी route मदद कर सकती है। कोई gateway final model की hard context limit पार नहीं कर सकता।

क्या /clear code मिटा देता है?

नहीं। यह conversation context साफ करता है, disk पर लिखी files नहीं। फिर भी पहले git status verify करें और patch, commit या editor snapshot रखें।

ठीक 43 characters क्यों न हटाएँ?

Unit मालूम नहीं है और request में अदृश्य system content, tools और history भी शामिल होते हैं। Boundary को ठीक-ठीक छूने से बेहतर पर्याप्त headroom बनाना है।

याद रखने वाली recovery sequence

Input length exceeds maximum आने पर यह क्रम रखें: दूसरे terminal में diff और manual handoff save करें → /context चलाएँ → focused /compact आज़माएँ → fail होने पर बड़े output से पहले /rewind करें → फिर भी fail हो तो /clear या नई session लें → tiny control task से limiting layer खोजें → auto compact को verified server window से नीचे रखें।

यह तरीका 43 की unit का अनुमान नहीं लगाता और यह दावा भी नहीं करता कि proxy model की hard limit को bypass कर सकता है। पहले काम बचता है, फिर अस्पष्ट 400 को layer-by-layer दोहराए जा सकने वाले diagnosis में बदला जाता है।