"API Error: The response stopped arriving"का मतलब है कि जवाब आते-आते बीच में, कनेक्शन खुला रहने के बावजूद डेटा आना बंद हो गया, और Claude Code के अपने वॉचडॉग टाइमर ने उस कनेक्शन को काट दिया। तब तक पूरा हो चुका आउटपुट स्क्रीन पर बचा रहता है। इंटरैक्टिव सेशन में continue लिखकर भेजें, तो काम आख़िरी पूरी हुई जगह से आगे बढ़ जाता है।

API Error: The response stopped arriving. The response above may be incomplete.

v2.1.227 से पहले यही संदेश Response stalled mid-stream के रूप में दिखता था। आधिकारिक एरर रेफ़रेंस में इस नाम-बदलाव का साफ़ ज़िक्र है, और भीतर जो हो रहा है वह वही है। पुराने शब्दों में लिखी जानकारी या बग रिपोर्ट खोजते समय दोनों संदेशों से खोजें।

सबसे पहले "API Error:" के बाद के शब्द देखें

"रुक गया" और "कट गया" वाले संदेशों के शब्द कारण के हिसाब से अलग होते हैं

The response stopped arriving
आउटपुट शुरू होने के बाद, कनेक्शन खुला रहते हुए डेटा रुक गया
→ continue से आगे बढ़ाएँ
यह लेख इसी के बारे में है
Connection lost mid-response
आउटपुट शुरू होने के बाद कनेक्शन ही टूट गया
→ टूटने और चुप्पी का अंतर देखें
पुराना संदेश Connection closed
The response stalled before a response was produced
सोचना पूरा होने के बाद, कोई भी आउटपुट शुरू होने से पहले रुक गया
→ दोबारा भेजने का नियम अलग है
कोई आउटपुट नहीं बचता
Streaming response ended before any complete data was received
काम का कोई डेटा आए बिना जवाब ख़त्म हुआ, और स्ट्रीमिंग के बिना दोबारा भेजा गया
→ रास्ते की प्रॉक्सी पर शक करें
रुका नहीं, ख़ाली ख़त्म हुआ
आधिकारिक एरर रेफ़रेंस के विवरण के आधार पर, संदेश के शब्दों से जाँच की दिशा चुनने के लिए बनाया गया चित्र।

विषय-सूची

1. इस संदेश का मतलब——कनेक्शन टूटना नहीं, "चुप्पी"

Claude Code का आधिकारिक एरर रेफ़रेंस इस संदेश को यूँ समझाता है: "कनेक्शन खुला रहा, लेकिन उसने डेटा भेजना बंद कर दिया, इसलिए स्ट्रीमिंग के आइडल वॉचडॉग (idle watchdog) ने उसे काट दिया"। यह API की लौटाई गई एरर का टेक्स्ट नहीं है, बल्कि जवाब पा रहे Claude Code का ख़ुद जोड़ा गया नोट है।

"बीच में रुक गया" के मामलों में भी Claude Code कारण के हिसाब से अलग शब्द इस्तेमाल करता है। आधिकारिक दस्तावेज़ ये 4 संदेश गिनाते हैं, और आख़िर का "The response above may be incomplete. (ऊपर का जवाब अधूरा हो सकता है)" सब में एक जैसा है।

API Error: Server error mid-response. The response above may be incomplete.
API Error: Connection lost mid-response. The response above may be incomplete.
API Error: Your computer went to sleep mid-response. The response above may be incomplete.
API Error: The response stopped arriving. The response above may be incomplete.

पहली पंक्ति तब आती है जब जवाब के बीच सर्वर ओवरलोड या 5xx एरर लौटाए, दूसरी तब जब कनेक्शन टूट जाए, और तीसरी तब जब जवाब के बीच कंप्यूटर स्लीप में चला जाए। सिर्फ़ चौथी पंक्ति, यानी यह संदेश, बताता है कि न कोई एरर आई, न कनेक्शन टूटा, फिर भी डेटा आना बंद हो गया।

काटने वाले 4 वॉचडॉग टाइमर

आधिकारिक नेटवर्क कॉन्फ़िगरेशन दस्तावेज़ के अनुसार, Claude Code के पास चुप पड़ी स्ट्रीम को काटने वाले 4 टाइमर हैं। मक़सद यह है कि मरा हुआ कनेक्शन हमेशा के लिए अटका न रहे और उसे विफलता माना जा सके। जवाब बहना शुरू होने के बाद नीचे की तालिका के ऊपर वाले 3 टाइमर लागू होते हैं।

टाइमरकब काटता हैडिफ़ॉल्ट समय
बाइट-स्तर का वॉचडॉगलाइन पर एक भी बाइट नहीं आती (SSE का कीप-अलाइव भी नहीं)Anthropic API से सीधे जुड़ने पर 180 सेकंड, बाक़ी में 300 सेकंड
इवेंट-स्तर का वॉचडॉगजवाब का एक भी इवेंट पढ़ा नहीं जा सकता300 सेकंड (सभी प्रोवाइडर)
बॉडी का आइडल टाइमआउट5 मिनट तक कोई बाइट नहीं आती5 मिनट (सीधी Anthropic API और Claude Platform on AWS को छोड़कर)
पहली बाइट की समय-सीमाभेजने के बाद जवाब का एक भी हेडर नहीं आतासीधी API में 180 सेकंड, बाक़ी में 300 सेकंड (बॉडी के हर 32KB पर 1 सेकंड जुड़ता है)। यह संदेश नहीं, बल्कि No response from API दिखता है

अगर आप Anthropic API से सीधे जुड़े हैं, तो पैमाना बाइट-स्तर के वॉचडॉग के 180 सेकंड हैं। यानी यह संदेश आने से पहले स्क्रीन कुछ मिनट रुकी हुई दिखती है। आधिकारिक दस्तावेज़ों के अनुसार, अनुरोध ज़िंदा रहते हुए 20 सेकंड तक डेटा न आए, तो पहले नीचे वाला बैनर दिखता है। इसका मतलब है "अभी विफल नहीं हुआ", और उलटी गिनती काटे जाने के क्षण तक की होती है (v2.1.185 से पहले यह 10 सेकंड था, और शब्द भी अलग थे)।

Waiting for API response · will retry in … · check your network

डेटा लौट आए, तो बैनर अपने-आप हट जाता है। अगर बैनर नहीं हटता, बात काटे जाने तक पहुँचती है, और आउटपुट का कुछ हिस्सा पहले ही पूरा हो चुका होता है, तब इस लेख वाला संदेश दिखता है।

2. v2.1.227 में "Response stalled mid-stream" से नाम बदला

आधिकारिक एरर रेफ़रेंस 4 संदेशों के विवरण के ठीक बाद लिखता है कि "v2.1.227 से पहले Connection lost mid-response को Connection closed mid-response और The response stopped arriving को Response stalled mid-stream के रूप में दिखाया जाता था"। उसी वर्ज़न में आउटपुट शुरू होने से पहले वाला संदेश भी बदला गया।

v2.1.227 से पहले का संदेशअभी का संदेशइस साइट का लेख
Response stalled mid-streamThe response stopped arrivingयह लेख
Response stalled while thinking, before producing a responseThe response stalled before a response was producedइस लेख का अध्याय 3
Connection closed mid-responseConnection lost mid-responseclosed और lost के लेख (नीचे के पाठ में)

पुराना संदेश Response stalled mid-stream उस घटना के साथ दिखा था जिसमें मॉडल एक ही शब्द बार-बार दोहराता रहता है; उसके उदाहरण Response stalled mid-stream और "court" के अंतहीन लूप वाले लेख में हैं। कनेक्शन टूटने वाले संदेश के लिए, पुराने शब्दों के दौर की रिपोर्टें Connection closed mid-response वाले लेख में, और नाम बदलने के बाद के संदेश Connection lost mid-response वाले लेख में अलग-अलग समझाए गए हैं।

वर्ज़न का संकेत मिलता है

stopped arriving दिखे, तो वह Claude Code v2.1.227 या उसके बाद का है। stalled mid-stream दिखे, तो उससे पुराना वर्ज़न है।

CHANGELOG में दर्ज नहीं

22 सितंबर 2026 को आधिकारिक CHANGELOG में v2.1.227 की प्रविष्टि पढ़ी, पर शब्दों के बदलाव का ज़िक्र नहीं था। npm पर यह 10 अगस्त 2026 (UTC) को प्रकाशित हुआ।

रिपोर्ट दोनों संदेशों से खोजें

एक ही घटना दो नामों से रिपोर्ट हुई है। GitHub Issue खोजते समय नए और पुराने, दोनों शब्दों से खोजें।

v2.1.222 से पहले यह ग़लत चेतावनी भी हो सकती है

आधिकारिक दस्तावेज़ों के अनुसार, v2.1.222 से पहले के Claude Code में दो तरह की ग़लत चेतावनियाँ थीं। पहली: ANTHROPIC_BASE_URL या ANTHROPIC_AWS_BASE_URL से होकर जाने वाले गेटवे में, सर्वर का कीप-अलाइव पहुँचने के बावजूद केवल पढ़े गए इवेंट गिने जाते थे और कनेक्शन काट दिया जाता था। दूसरी: जवाब पूरा होने के बाद कनेक्शन रुकने पर भी यह नोट दिखता था, और पूरे जवाब को एरर मान लिया जाता था। अगर claude --version 2.1.222 से छोटा है, तो पहले अपडेट करें।

3. मिलते-जुलते संदेशों से अंतर

कौन-सा संदेश दिखेगा, यह इस पर निर्भर है कि जवाब कहाँ तक पहुँचकर रुका। आधिकारिक "Automatic retries" विवरण को जवाब के क्रम के हिसाब से लगाएँ, तो तस्वीर यह बनती है।

जितनी देर से रुके, उतना ज़्यादा आउटपुट बचता है और उतना कम अपने-आप दोबारा भेजा जाता है

① हेडर के इंतज़ार में

समय-सीमा में जवाब का हेडर नहीं आता। अधिकतम 1 बार दोबारा भेजता है

No response from API

② कुछ भी पूरा होने से पहले

हेडर आया पर सामग्री नहीं, या सोचना पूरा करके आउटपुट से पहले रुक गया। सामान्य 10 बार से अलग अधिकतम 1 बार दोबारा भेजता है, और सोचने के बाद फिर रुके तो इस संदेश पर ख़त्म होता है

The response stalled before a response was produced

③ ब्लॉक पूरा होने के बाद

टेक्स्ट का एक हिस्सा या एक टूल कॉल पूरा होने के बाद रुका (सोचना पूरा करके लिखना शुरू करने के बाद भी)। दोबारा नहीं भेजता

The response stopped arriving (यह लेख)

④ जवाब पूरा होने के बाद

पूरा जवाब रखता है और टर्न सामान्य रूप से ख़त्म करता है। कोई नोट नहीं दिखता

कोई संदेश नहीं (v2.1.222 से)

स्रोत: Claude Code के आधिकारिक एरर रेफ़रेंस के "Automatic retries""No response from API""The response above may be incomplete" को चित्र के रूप में दिखाया गया।

③ में दोबारा न भेजने का कारण भी आधिकारिक रूप से लिखा है। टेक्स्ट या टूल कॉल का एक हिस्सा पूरा होने के बाद अनुरोध दोबारा भेजा जाए, तो एक ही टूल कॉल दो बार चल सकती है। इसलिए Claude Code पूरे हुए हिस्से को रखता है, और टर्न छोड़ने के बजाय नोट जोड़ देता है।

संदेशक्या हो रहा हैबचा आउटपुट और दोबारा भेजना
The response stopped arrivingकनेक्शन खुला रहा, डेटा रुक गयापूरा हुआ हिस्सा बचता है। दोबारा नहीं भेजता
Connection lost mid-responseकनेक्शन ही टूट गयापूरा हुआ हिस्सा बचता है। दोबारा नहीं भेजता
Server error mid-responseबीच में सर्वर ने ओवरलोड या 5xx लौटायापूरा हुआ हिस्सा बचता है (v2.1.199 से)। दोबारा नहीं भेजता
The response stalled before a response was producedसोचने के बाद, आउटपुट शुरू होने से पहले लगातार 2 बार रुकाकोई आउटपुट नहीं बचता। 1 बार दोबारा भेजने के बाद का संदेश
No response from APIसमय-सीमा में जवाब का एक भी हेडर नहीं आयाकोई आउटपुट नहीं बचता। 1 बार दोबारा भेजने के बाद का संदेश
Streaming response ended before any complete data was receivedजवाब बिना काम के डेटा के ख़त्म हुआस्ट्रीमिंग के बिना अपने-आप दोबारा भेजता है (सिर्फ़ चेतावनी)

Connection lost mid-response से अंतर: "टूटना या चुप्पी"

दोनों संदेश कुछ आउटपुट आने के बाद दिखते हैं, और दोनों में आउटपुट बचता है तथा continue से आगे बढ़ा जा सकता है। अंतर रुकने के तरीक़े में है। lost का मतलब है कि कनेक्शन खो गया; तब अपने इंटरनेट का पल भर का कटना, VPN का दोबारा जुड़ना, या बीच के किसी उपकरण का कनेक्शन काटना संदिग्ध है। stopped arriving का मतलब है कि कनेक्शन बना रहा पर सामग्री नहीं आई, और वॉचडॉग टाइमर का पूरा समय इंतज़ार करने के बाद काटा गया। इसलिए अध्याय 6 में बताए टाइमर समायोजन की गुंजाइश सिर्फ़ stopped arriving में है।

Streaming response ended… से अंतर: "रुका या ख़ाली ख़त्म हुआ"

आधिकारिक दस्तावेज़ों के अनुसार, Streaming response ended before any complete data was received वह चेतावनी है जो तब आती है जब जवाब काम का एक भी डेटा दिए बिना ख़त्म हो जाए। Claude Code स्ट्रीमिंग छोड़कर वही अनुरोध दोबारा भेजता है और टर्न जारी रखता है। इंटरैक्टिव सेशन में यह चेतावनी हर सेशन में सिर्फ़ 1 बार दिखती है (v2.1.239 से पहले चुपचाप दोबारा भेजा जाता था)। आधिकारिक दस्तावेज़ों के मुताबिक़, आम कारण यह है कि बीच की प्रॉक्सी या गेटवे जवाब की बॉडी को खपा लेता या बदल देता है। stopped arriving में जवाब कुछ दूर तक आकर रुकता है, और अपने-आप दोबारा नहीं भेजा जाता।

4. अधूरे काम का क्या होता है

आधिकारिक विवरण के अनुसार, Claude Code सभी पूरे हुए ब्लॉक रखता है, और टर्न के अंत में अधूरे आख़िरी ब्लॉक को छोड़ देता है। इसीलिए स्क्रीन के आख़िरी कुछ वाक्य या आख़िरी टूल कॉल गायब हो सकते हैं। पूरी हो चुकी टूल कॉल चलती हैं, और उनके नतीजों से टर्न आगे बढ़ता है। रुकने के बाद क्या होता है, यह चलाने के माहौल पर निर्भर है।

इंटरैक्टिव सेशन

स्क्रीन पर बचा जवाब पढ़ें और continue भेजें, तो आख़िरी पूरे हुए ब्लॉक से आगे बढ़ता है। शुरू से निर्देश दोबारा देने पर पहले से हो चुके काम दोहराए जा सकते हैं।

-p, Agent SDK, क्लाउड सेशन

अगर बीच में रुका जवाब सिर्फ़ टेक्स्ट है और उसमें टूल कॉल नहीं है, तो Claude Code ख़ुद आगे बढ़ने का संकेत देता है। लगातार 3 बार तक कोशिश करता है, और सब ख़त्म होने पर ही नोट दिखता है (v2.1.246 से)।

सबएजेंट

इंटरैक्टिव हो या नहीं, सिर्फ़ टेक्स्ट वाले जवाब पर सबएजेंट को आगे बढ़ने का संकेत दिया जाता है। संकेत ख़त्म होने पर यह नोट सबएजेंट का आख़िरी संदेश बन जाता है (v2.1.257 से)।

हुक

आधिकारिक हुक विवरण के अनुसार, API एरर पर ख़त्म हुए टर्न में Stop नहीं, बल्कि StopFailure चलता है। इसका आउटपुट और एग्ज़िट कोड दोनों अनदेखे किए जाते हैं, इसलिए हुक से अपने-आप continue नहीं करवाया जा सकता।

-p में रुकने पर आउटपुट, और आगे कैसे बढ़ें

नॉन-इंटरैक्टिव मोड के डिफ़ॉल्ट टेक्स्ट आउटपुट में, Claude Code उस टर्न का आख़िरी पूरा हुआ टेक्स्ट ब्लॉक दिखाता है और उसके बाद यह संदेश जोड़ता है (v2.1.219 से पहले सिर्फ़ संदेश दिखता था और जवाब छोड़ दिया जाता था)। लेकिन अगर पास में कोई पूरा हुआ टेक्स्ट न बचा हो, जैसे टर्न के बीच बातचीत संक्षिप्त (compact) होने से वह टेक्स्ट हट गया हो, तो सिर्फ़ संदेश दिखता है (26 सितंबर 2026 को आधिकारिक एरर रेफ़रेंस में जाँचकर जोड़ा गया)। --output-format json या stream-json में यह संदेश result फ़ील्ड में आता है। आधिकारिक तरीक़ा यह है कि कनेक्शन स्थिर होने के बाद सेशन फिर से शुरू करके continue भेजें।

# पिछली बातचीत जारी रखें
claude -p "continue" --continue

# सेशन ID बताकर जारी रखें
claude -p "continue" --resume "$session_id"

हुक से अपने-आप फिर शुरू करने के बारे में, Issue #87972 के रिपोर्टर ने लिखा है कि "पुराने संदेश के दौर में Stop हुक चलता था और अपने-आप आगे बढ़ाया जा सकता था, लेकिन नाम बदलने के आसपास से यह बंद हो गया"। यह रिपोर्टर का अवलोकन है, और आधिकारिक रूप से नहीं लिखा कि पहले वाला व्यवहार जान-बूझकर था या नहीं। आज के आधिकारिक दस्तावेज़ों के हिसाब से, हुक से लॉग या सूचना तो भेजी जा सकती है, पर टर्न फिर शुरू नहीं करवाया जा सकता।

5. कारण——आधिकारिक रूप से लिखा हुआ, और रिपोर्ट किया हुआ

यह संदेश सिर्फ़ नतीजा बताता है कि "डेटा आना बंद हो गया"; क्यों रुका, यह संदेश से पता नहीं चलता। नीचे भरोसे के स्तर के हिसाब से बाँटा गया है।

✅ आधिकारिक दस्तावेज़ों और CHANGELOG में लिखे, स्ट्रीम के चुप होने या काटे जाने के कारण

  • तंत्र: कनेक्शन खुला रहते हुए डेटा रुका और वॉचडॉग टाइमर ने काट दिया। सीधी API में कीप-अलाइव समेत 180 सेकंड तक कोई बाइट न आए, तो काट दिया जाता है
  • गेटवे में ग़लत चेतावनी: v2.1.222 से पहले, ANTHROPIC_BASE_URL आदि से होकर जाने वाले गेटवे में कीप-अलाइव पहुँचने पर भी कनेक्शन काटा जा सकता था। ANTHROPIC_BEDROCK_BASE_URL जैसे प्रोवाइडर के बेस URL वाले गेटवे बाइट-स्तर के वॉचडॉग के दायरे से बाहर हैं
  • लंबे सोच-विचार के दौरान की चुप्पी: CHANGELOG के v2.1.229 में लिखा है "लंबे सोच-विचार के दौरान भी गेटवे के स्ट्रीमिंग जवाब में SSE कीप-अलाइव भेजा जाता है, ताकि Vertex या Bedrock ऊपर (upstream) होने पर आइडल कटाव न हो", और v2.1.257 में "Opus 4.7 और उसके बाद के मॉडलों में Bedrock और Bedrock Mantle पर, न दिखने वाले लंबे सोच-विचार के दौरान अनुरोध चुप हो जाता था और आइडल टाइमआउट से कनेक्शन कट जाता था, यह समस्या ठीक की गई"
  • कटाव से उबरना: v2.1.232 में "Bedrock, Vertex, गेटवे वाले सेटअप में स्ट्रीम का आइडल टाइमआउट उबर नहीं पाता था और अनुरोध विफल कर देता था" वाली समस्या ठीक हुई
  • प्रॉक्सी की बफ़रिंग: आधिकारिक एनवायरनमेंट वेरिएबल विवरण CLAUDE_STREAM_IDLE_TIMEOUT_MS की न्यूनतम सीमा 5 मिनट रखने का कारण बताता है: "लंबे सोच-विचार और प्रॉक्सी की बफ़रिंग को समाहित करने के लिए"

आधिकारिक दस्तावेज़ इस संदेश को एरर रेफ़रेंस के "Server errors" खंड में रखते हैं। खंड की शुरुआत में लिखा है कि "ज़्यादातर Anthropic की सेवा जैसे इन्फ़रेंस प्रोवाइडर की ओर से आती हैं", लेकिन इस संदेश के बारे में आधिकारिक व्याख्या ऊपर के तंत्र तक ही है। अपना इंटरनेट, बीच के उपकरण या सर्वर——इनमें से कहाँ रुका, यह आधिकारिक रूप से तय नहीं किया गया है।

🟡 GitHub पर रिपोर्ट हुए, पर कारण तय न हुए मामले

22 सितंबर 2026 को इस संदेश वाले नीचे दिए Issue खोलकर पढ़े। सभी उपयोगकर्ताओं की रिपोर्ट या अनुमान हैं, और जितना पढ़ा उसमें Anthropic का कोई सार्वजनिक जवाब नहीं है।

  • #88900 (Linux, 2.1.240, न प्रॉक्सी न गेटवे): जवाब के लगभग 0.5–2.7KB आने पर रुकने और 180 सेकंड बाद बाइट-स्तर के वॉचडॉग के काटने की रिपोर्ट। रिपोर्टर का कहना है कि एक ही मिनट में अलग-अलग सेशन एक साथ रुके, और उसने सर्वर-साइड लॉग जाँचने का अनुरोध किया है
  • #90005 (Windows 11, 2.1.246): एक दिन में 33 बार दिखने, जबकि उससे पहले के दिनों में 0 बार होने की रिपोर्ट। रिपोर्टर ने बैंडविड्थ, पैकेट लॉस, प्रॉक्सी मापकर उन्हें ठीक पाया, पर यह स्पष्ट करते हुए कि यह लंबे समय तक खुले कनेक्शन को मापने वाला परीक्षण नहीं था, लिखा है कि कैरियर-ग्रेड NAT के आइडल कटाव को ख़ारिज नहीं किया जा सका
  • #89027 (macOS, VS Code एक्सटेंशन 2.1.238–2.1.241): लॉग में "byte-level" कटाव और 180000ms की चुप्पी दर्ज होने की रिपोर्ट। यह सबएजेंट के WebFetch के बीच हुआ था
  • #87246 (macOS, 2.1.232): सिर्फ़ यह संदेश चिपकाई गई रिपोर्ट, जो "not planned" (कोई योजना नहीं) कहकर बंद की गई। बाद की टिप्पणी में यह अवलोकन है कि बैकग्राउंड सबएजेंट एक के बाद एक इसी संदेश पर रुके

#88900 और #90005 में लिखा है कि अपने इंटरनेट में कोई गड़बड़ी न मिलने पर भी रुकावट आई। फिर भी, सिर्फ़ इससे सर्वर को कारण नहीं ठहराया जा सकता। जैसा #90005 के रिपोर्टर ने भी लिखा है, छोटे नेटवर्क परीक्षण "कुछ मिनट खुला रहा कनेक्शन बीच में चुप हो जाना" वाली स्थिति दोहराते नहीं।

6. रुकने पर समाधान के कदम

ऊपर से क्रम में, कम मेहनत और ज़्यादा असर वाले कदम पहले रखे गए हैं। एक बार ही हुआ हो, तो कदम 2 पर बात ख़त्म।

01

बचा आउटपुट और काम की असली स्थिति जाँचें

पूरी हो चुकी टूल कॉल चल चुकी हैं। अगर फ़ाइल बदलने या कमांड के बीच रुका, तो पहले git status या git diff से देखें कि कितना बदला।

02

continue भेजें

यह आधिकारिक वापसी का तरीक़ा है। काम आख़िरी पूरे हुए ब्लॉक से आगे बढ़ता है। मूल निर्देश शुरू से दोबारा चिपकाने पर, हो चुके काम फिर से चल जाएँगे।

03

वर्ज़न जाँचें और अपडेट करें

claude --version से वर्ज़न देखें और claude update से अपडेट करें। 2.1.222 से पुराना हो, तो अध्याय 2 वाली ग़लत चेतावनी की संभावना है। Bedrock, Vertex या गेटवे इस्तेमाल करते हों, तो 2.1.229, 2.1.232, 2.1.257 में भी संबंधित सुधार हैं (अध्याय 5)।

04

नेटवर्क का रास्ता अलग-अलग करके जाँचें

/status की Proxy पंक्ति में देखें कि कौन-सी प्रॉक्सी लगी है। VPN या प्रॉक्सी हटाना, दूसरे नेटवर्क से जुड़ना, या गेटवे (ANTHROPIC_BASE_URL) हटाकर सीधे जुड़ना——इनमें से किसी से रुकावट बंद हो जाए, तो कारण हटाई गई चीज़ों में है।

05

एक जवाब को छोटा रखें

बहुत सारी फ़ाइलें पढ़कर लंबी रिपोर्ट लिखने जैसे निर्देश को पढ़ने और लिखने में बाँट दें। आधिकारिक दस्तावेज़ इसे इस संदेश का समाधान नहीं बताते, पर "Request timed out" वाले हिस्से में लंबे काम को छोटे निर्देशों में बाँटने की सलाह देते हैं। #87972 में भी एक उपयोगकर्ता का तरीक़ा बताया गया है कि एक जवाब छोटा रखने से रुकावट कम होती है।

06

आउटेज की जानकारी देखें

status.claude.com पर देखें कि कोई चल रहा आउटेज तो नहीं। लेकिन #90005 के रिपोर्टर ने लिखा है कि लगातार रुकावट के समय स्टेटस "सब सामान्य" था। हरा दिखने भर से इसे अपनी तरफ़ की समस्या मान न लें।

07

रास्ता देर तक चुप रहता हो, तो वॉचडॉग का समय बढ़ाएँ

जहाँ प्रॉक्सी या गेटवे जवाब जमा करके रखते हैं, वहाँ बाइट-स्तर का वॉचडॉग बढ़ाने से कटाव कम होता है। नीचे की तरह सेटिंग फ़ाइल के env में रखें। बैकग्राउंड एजेंट तक शेल के एनवायरनमेंट वेरिएबल नहीं पहुँच पाते, इसलिए आधिकारिक दस्तावेज़ शेल में export करने के बजाय सेटिंग फ़ाइल की सलाह देते हैं।

~/.claude/settings.json में लिखने का उदाहरण (बाइट-स्तर का वॉचडॉग 10 मिनट करना)।

{
  "env": {
    "CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS": "600000"
  }
}
एनवायरनमेंट वेरिएबलआधिकारिक विवरण
CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MSसिर्फ़ बाइट-स्तर के वॉचडॉग का समय। 10 सेकंड–30 मिनट के बीच सीमित किया जाता है। v2.1.210 से
CLAUDE_STREAM_IDLE_TIMEOUT_MSबाइट-स्तर और इवेंट-स्तर, दोनों का समय। 5 मिनट से कम को 5 मिनट कर दिया जाता है, और बाइट-स्तर में 30 मिनट ऊपरी सीमा है
API_FORCE_IDLE_TIMEOUT5 मिनट वाले बॉडी आइडल टाइमआउट को 0 से बंद करता है, और 1 से सभी प्रोवाइडर पर लागू करता है। वॉचडॉग टाइमर से स्वतंत्र
CLAUDE_CODE_MAX_RETRIESदोबारा कोशिश की संख्या (डिफ़ॉल्ट 10)। इस संदेश वाली स्थिति में शुरू से ही दोबारा न भेजने का डिज़ाइन है, इसलिए बढ़ाने से यह कम नहीं होता

वॉचडॉग बंद करने की सलाह नहीं

CLAUDE_ENABLE_BYTE_WATCHDOG या CLAUDE_ENABLE_STREAM_WATCHDOG को 0 करने से वॉचडॉग ही बंद हो जाता है। आधिकारिक दस्तावेज़ इन टाइमरों को "मरे हुए कनेक्शन अटके न रहें, बल्कि विफल होकर दोबारा कोशिश में जाएँ" इसके लिए बताते हैं। इन्हें बंद करने से संदेश तो ग़ायब हो जाएगा, पर सचमुच रुके कनेक्शन का अंतहीन इंतज़ार करना पड़ेगा। और अगर सर्वर से डेटा सच में रुका है, तो समय बढ़ाने से सिर्फ़ विफलता देर से आएगी।

7. ठीक हुआ या नहीं, कैसे जाँचें

एक बार न दिखने को ही ठीक होना न मानें। उसी आकार का काम चलाकर नीचे की 4 बातें देखें।

वर्ज़न

claude --version से देखें कि अपडेट लागू हुआ या नहीं। IDE एक्सटेंशन या डेस्कटॉप ऐप के साथ आने वाला वर्ज़न CLI से अलग अपडेट हो सकता है

इंतज़ार का बैनर

Waiting for API response दिखकर अपने-आप हट जाए, तो चुप्पी छोटी रही। आधिकारिक दस्तावेज़ कहते हैं कि हर कोशिश में दिखे, तो इसे नेटवर्क की समस्या मानें

डीबग लॉग

claude --debug से शुरू करने पर लॉग ~/.claude/debug/<session-id>.txt में बनता है। #88900 और #89027 के रिपोर्टरों ने कटाव के समय "Streaming idle timeout (byte-level)" से शुरू होने वाली पंक्ति देखी (यह पंक्ति आधिकारिक दस्तावेज़ों में नहीं है)

बातचीत लॉग में गिनती

बातचीत ~/.claude/projects/ के नीचे JSONL में सहेजी जाती है। अपडेट या सेटिंग बदलने से पहले और बाद में यह संदेश कितनी बार आया, गिनकर तुलना करें। आधिकारिक दस्तावेज़ सावधान करते हैं कि यह फ़ॉर्मैट आंतरिक है और वर्ज़न के साथ बदलता है

# वर्ज़न जाँचें
claude --version

# डीबग लॉग के साथ शुरू करें
claude --debug

# यह संदेश वाली बातचीत लॉग फ़ाइलें गिनें (macOS, Linux)
grep -rl "The response stopped arriving" ~/.claude/projects/ | wc -l

# इसी तरह, यह संदेश वाली पंक्तियाँ गिनें (PowerShell)
Get-ChildItem "$HOME\.claude\projects" -Recurse -Filter *.jsonl | Select-String -SimpleMatch "The response stopped arriving" | Measure-Object

गिनती को सिर्फ़ अंदाज़े के रूप में लें। #90005 के रिपोर्टर ने लिखा है कि 85 मिनट में स्क्रीन पर 15 बार रुकावट आई, पर बातचीत लॉग में सिर्फ़ 1 प्रविष्टि बची। बातचीत लॉग में 0 हो तब भी, स्क्रीन पर कितनी बार रुका यह ख़ुद भी लिखते रहें, तो भरोसेमंद रहेगा।

8. रिपोर्ट करते समय कौन-सी जानकारी रखें

आधिकारिक एरर रेफ़रेंस, समस्या न सुलझने पर ये 4 रास्ते बताता है।

  • Claude Code के अंदर /feedback चलाएँ। बातचीत का रिकॉर्ड और विवरण Anthropic को भेजा जाता है, और भरी हुई सामग्री के साथ GitHub Issue भी खोला जा सकता है। Bedrock या Vertex जैसे प्रोवाइडर पर यह भेजने के बजाय स्थानीय रूप से सहेजा जाता है
  • शेल में claude doctor चलाकर इंस्टॉलेशन का केवल-पढ़ने वाला निदान देखें
  • status.claude.com पर आउटेज जाँचें
  • GitHub के मौजूदा Issue खोजें। नए और पुराने, दोनों संदेशों से खोजें

रिपोर्ट नोट का ढाँचा

माहौल
claude --version का नतीजा / OS / कहाँ इस्तेमाल कर रहे हैं (टर्मिनल का CLI, VS Code एक्सटेंशन, डेस्कटॉप ऐप)
रास्ता
सीधी API, या Bedrock, Vertex, गेटवे (ANTHROPIC_BASE_URL) / प्रॉक्सी और VPN हैं या नहीं
संदेश
एरर का पूरा पाठ / समय और टाइमज़ोन / ठीक पहले Waiting for API response दिखा था या नहीं / मुख्य बातचीत में या सबएजेंट में
आवृत्ति
दिन में कितनी बार, और किस दिन से शुरू हुआ / उस दिन अपडेट या सेटिंग बदली थी या नहीं
क्या आज़माया
अपडेट, VPN या प्रॉक्सी हटाना, दूसरा नेटवर्क, टर्न बाँटना——इनसे पहले और बाद में क्या बदला

9. क्या पक्का है / क्या नहीं

✅ आधिकारिक रूप से पुष्ट

  • अर्थ: "कनेक्शन खुला रहा, डेटा रुका, और वॉचडॉग टाइमर ने काट दिया"
  • v2.1.227 से पहले Response stalled mid-stream दिखता था
  • पूरा हुआ आउटपुट बचता है, और वापसी continue से
  • एक ही टूल कॉल दो बार न चले, इसलिए दोबारा नहीं भेजता
  • v2.1.222 से पहले गेटवे और पूरा होने के बाद के रुकाव में ग़लत चेतावनी थी

🟡 रिपोर्ट हैं, पर पक्का नहीं

  • अपना इंटरनेट ठीक होने पर भी रुकता है (#88900, #90005)
  • कुछ KB आने पर रुकता है, और कई सेशन में एक साथ होता है (#88900)
  • बातचीत लॉग में दर्ज गिनती स्क्रीन से कम होती है (#90005)
  • पुराने संदेश के दौर में Stop हुक से अपने-आप फिर शुरू हो जाता था (#87972)

🔴 सार्वजनिक नहीं

  • डेटा रुकने के कारण की आधिकारिक व्याख्या (ऊपर के Issue में कोई सार्वजनिक जवाब नहीं)
  • रुकावट अपनी तरफ़, रास्ते में या सर्वर पर——कहाँ है
  • नाम बदलने का कारण (CHANGELOG में ज़िक्र नहीं)

10. सारांश

"API Error: The response stopped arriving" बताता है कि जवाब कुछ दूर तक आने के बाद, कनेक्शन खुला रहते हुए डेटा रुक गया, और Claude Code के वॉचडॉग टाइमर ने उसे काट दिया। यह v2.1.227 से पहले के Response stalled mid-stream जैसा ही है, और पूरा हुआ आउटपुट बचा रहता है। पहले काम की स्थिति जाँचें, फिर continue भेजें।

बार-बार दिखे, तो इस क्रम में आज़माएँ: वर्ज़न अपडेट, VPN, प्रॉक्सी, गेटवे को अलग करके जाँच, और एक जवाब को छोटा रखने का उपाय। जहाँ रास्ता देर तक चुप रहता हो, सिर्फ़ वहीं बाइट-स्तर के वॉचडॉग का समय बढ़ाने का विकल्प है। कनेक्शन ही टूटने वाले Connection lost mid-response में शक की जगह अलग है, इसलिए सबसे पहले संदेश के शब्द मिलाकर देखें। दूसरी एरर के लिए Claude Code की आम एरर और उनके समाधान देखें।

FAQ

Q. "API Error: The response stopped arriving" का क्या मतलब है?
A. इसका मतलब है कि जवाब आते-आते बीच में, कनेक्शन खुला रहते हुए डेटा आना बंद हो गया, और Claude Code के वॉचडॉग टाइमर ने उस कनेक्शन को काट दिया। यह संदेश टेक्स्ट या टूल कॉल का एक हिस्सा पूरा होने के बाद रुकने पर दिखता है, और तब तक का आउटपुट बचा रहता है।

Q. क्या यह "Response stalled mid-stream" से अलग एरर है?
A. नहीं, दोनों एक ही हैं। आधिकारिक एरर रेफ़रेंस साफ़ लिखता है कि v2.1.227 से पहले यह संदेश Response stalled mid-stream था। सिर्फ़ संदेश बदला है, कोई नई तरह की गड़बड़ी शुरू नहीं हुई।

Q. आगे बढ़ाने के लिए क्या लिखकर भेजूँ?
A. continue भेजें। काम आख़िरी पूरे हुए ब्लॉक से आगे बढ़ेगा। अगर फ़ाइल ऑपरेशन या कमांड के बीच रुका हो, तो पहले git status जैसी कमांड से असली स्थिति देखकर भेजना सुरक्षित है।

Q. दोबारा कोशिश की संख्या बढ़ाने से क्या यह बंद हो जाएगा?
A. नहीं। इस स्थिति में Claude Code शुरू से ही दोबारा नहीं भेजता, ताकि एक ही टूल कॉल दो बार न चले। CLAUDE_CODE_MAX_RETRIES सिर्फ़ आउटपुट शुरू होने से पहले की विफलताओं पर लागू होता है।

Q. "Connection lost mid-response" से क्या अंतर है?
A. lost का मतलब है कि कनेक्शन ही टूट गया, जबकि stopped arriving का मतलब है कि कनेक्शन बना रहा पर डेटा आना बंद हो गया। दोनों में पूरा हुआ आउटपुट बचता है और continue से आगे बढ़ा जा सकता है, लेकिन वॉचडॉग का समय बदलने की गुंजाइश सिर्फ़ stopped arriving में है।

संदर्भ के लिए प्राथमिक स्रोत