विषय-सूची
- 1. क्या हो रहा है——दो अलग परिघटनाएँ श्रृंखला में
- 2. «court» अनंत लूप की असल वजह——पुनरावृत्ति (डिजेनरेशन)
- 3. «Response stalled mid-stream» की असल वजह——स्ट्रीम रुकना
- 4. «court/invoke टैग लीक» से अलग——कैसे पहचानें
- 5. उकसाने वाली स्थितियाँ
- 6. अभी ठीक करें (उपयोगकर्ताओं के लिए)
- 7. डेवलपर्स के लिए——API/SDK से रोकें
- 8. मिलती-जुलती त्रुटियों से अंतर
- 9. आधिकारिक स्थिति
- FAQ
Claude Code में लंबे समय तक काम करते हुए, अचानक जवाब में «court court court court…» यही एक शब्द दर्जनों से सैकड़ों बार दोहराया जाए, और अंत में «API Error: Response stalled mid-stream. The response above may be incomplete.» दिखाकर रुक जाए——क्या आपने कभी ऐसी घटना का सामना किया है?
यह आपकी प्रॉम्प्ट या आपके एनवायरनमेंट की गलती नहीं है, बल्कि अक्सर दो अलग-अलग bug श्रृंखला में मिलकर होते हैं। ① मॉडल का एक ही टोकन उगलते रहना——पुनरावृत्ति लूप (डिजेनरेशन), और ② उस भारी आउटपुट या कनेक्शन की समस्या से स्ट्रीम का रुक जाना——«Response stalled mid-stream»। दोनों ही Anthropic के आधिकारिक रिपॉज़िटरी पर कई Issue वाले ज्ञात bug हैं। इस लेख में हम इन दो परतों की असल वजह, उकसाने वाली स्थितियाँ, तुरंत रोकने का तरीका, डेवलपर्स के लिए बचाव और मिलती-जुलती त्रुटियों से अंतर को——आधिकारिक दस्तावेज़ों और असली Issue के आधार पर व्यवस्थित करते हैं।
एक ही टोकन को लगातार दोहराने वाली पुनरावृत्ति (डिजेनरेशन)। आउटपुट टोकन को चट कर जाती है।
जवाब की स्ट्रीम डेटा भेजना बंद कर देती है और रुक जाती है। «बीच में कट गया» वाली स्थिति।
※ कभी-कभी इनमें से केवल एक ही होता है। court का बेकाबू होना भारी आउटपुट पैदा करता है और स्ट्रीम रुकने को उकसाता है——यह सबसे आम केस है।
1. क्या हो रहा है——दो अलग परिघटनाएँ श्रृंखला में
सबसे पहले इन्हें अलग करके देखना ज़रूरी है। स्क्रीन पर दिखता है «court का दोहराव» और «Response stalled mid-stream», लेकिन ये अलग-अलग परतों की दो समस्याएँ हैं।
- ① «court» अनंत लूप：Claude (मॉडल स्वयं) अपेक्षित जवाब या टूल कॉल के बजाय एक ही टोकन को बार-बार जनरेट करता रहता है——यह पुनरावृत्ति परिघटना है। GitHub Issue #68740（Output enters an infinite loop repeating the token "court"）और #65823（एक निश्चित स्ट्रिंग को हज़ारों बार दोहराकर आउटपुट टोकन खत्म कर देना）इसी के उदाहरण हैं।
- ② «Response stalled mid-stream»：जवाब की स्ट्रीम (क्रमिक ट्रांसमिशन) बीच में रुक जाती है——यह ट्रांसफर-साइड की त्रुटि है। Claude Code की आधिकारिक एरर रेफरेंस में भी इसका उल्लेख है, और Issue #70840 में भी रिपोर्ट किया गया है।
जब ① बेकाबू होता है तो भारी मात्रा में आउटपुट बनता है, और वही ② स्ट्रीम रुकने को उकसाता है——यह श्रृंखला उपयोगकर्ता की स्क्रीन पर एक ही परिघटना जैसी दिखती है। लेकिन कारण और उपाय दोनों अलग हैं, इसलिए इन्हें अलग-अलग समझना ही तेज़ रास्ता है।
2. «court» अनंत लूप की असल वजह——पुनरावृत्ति (डिजेनरेशन)
«court» का कोई मतलब नहीं है। यह भाषा मॉडल का एक ही आउटपुट पर अटक जाना यानी «पुनरावृत्ति (repetition／degeneration)»——एक पुरानी जानी-मानी विफलता का रूप है, और संयोग से यह अटकाव «court» टोकन पर हुआ है, बस इतना ही। यह किसी दूसरे शब्द या चिह्नों की शृंखला पर भी हो सकता है।
रिपोर्ट की गई विशेषताएँ（#68740 आदि）:
- मॉडल claude-opus-4-8 जैसे मॉडलों के साथ, Claude Code के VS Code एक्सटेंशन／CLI में होता है।
- सेशन के बीच से शुरू होता है और उसी सेशन में बार-बार दोबारा होता है (स्थिति-निर्भर)।
- टूल कॉल (जैसे Edit) से ठीक पहले जब जापानी आदि में कोई वाक्य जनरेट होता है, उस मौके पर यह ज़्यादा उकसाया जाता है——ऐसी रिपोर्ट है।
- बेकाबू होने पर आउटपुट टोकन का भारी उपभोग होता है（#65823），और सेशन के लॉक हो जाने के मामले भी हैं（#66950）।
इस पर area:model（मॉडल व्यवहार）लेबल लगा है, यानी इसे हार्नेस (Claude Code) की नहीं बल्कि मॉडल की ओर से जनरेशन की समस्या माना गया है। मतलब कमांड या सेटिंग्स ठीक करने से इसे जड़ से नहीं मिटाया जा सकता, और «हो जाए तो रोको और भाग निकलो» वाला उपाय ही मूल तरीका है।
3. «Response stalled mid-stream» की असल वजह——स्ट्रीम रुकना
दूसरी ओर «API Error: Response stalled mid-stream. The response above may be incomplete.», तब आती है जब जवाब की स्ट्रीम बीच में डेटा भेजना बंद कर देती है——यह ट्रांसफर-साइड की त्रुटि है। «ऊपर वाला जवाब अधूरा हो सकता है» चेतावनी के अनुसार, वहाँ तक स्ट्रीम हो चुका हिस्सा नहीं खोता——बस अंतिम कुछ वाक्य या टूल कॉल गायब रहते हैं।
मुख्य कारण जो रिपोर्ट और समझाए गए हैं:
- लंबा जवाब：कई बड़ी फाइलें पढ़कर संरचित रिपोर्ट बनाने जैसे काम में जनरेशन लंबा खिंचने पर यह ज़्यादा होता है। court के बेकाबू होने से बना भारी आउटपुट भी इसी में आता है।
- नेटवर्क/कनेक्शन की अस्थिरता：सीमा-पार कनेक्शन, घरेलू लाइन, tmux सेशन के ज़रिए आदि में संभावना बढ़ जाती है।
- रीड टाइमआउट की कमी：अपस्ट्रीम API पैकेट भेजना रोक देता है और क्लाइंट इंतज़ार करता रह जाता है——ऐसी स्थिति की ओर इशारा है（Issue #70840）।
वैसे, इससे मिलती-जुलती «Connection closed mid-response（जवाब के बीच में कनेक्शन बंद हो गया）»（#69415）एक अलग त्रुटि है, जिसमें स्ट्रीम «रुकती» नहीं बल्कि «कट» जाती है। लक्षण मिलते-जुलते हैं, पर यह कनेक्शन के टूटने की ओर ज़्यादा झुकी हुई है।
4. «court/invoke टैग लीक» से अलग——कैसे पहचानें
ये अक्सर आपस में गड़बड़ा दिए जाते हैं, पर इस लेख की «court के अनंत लूप» वाली परिघटना और «court का invoke टैग के साथ स्क्रीन पर लीक होना» वाली परिघटना अलग-अलग चीज़ें हैं। दूसरी वाली को हमारी साइट के एक अलग लेख में विस्तार से समझाया गया है।
| पहलू | यह लेख：court अनंत लूप → stall | अलग लेख：court/invoke टैग लीक |
|---|---|---|
| दिखने वाला लक्षण | «court» को दर्जनों से सैकड़ों बार दोहराना／अंत में stalled | «court» या कच्चा <invoke> टैग कुछ ही बार लीक होना |
| असल वजह | पुनरावृत्ति (डिजेनरेशन) ＋ स्ट्रीम रुकना | टूल कॉल के कंट्रोल टैग की जनरेशन बिगड़ना |
| टूल कॉल | जनरेशन पर ही अटककर आगे नहीं बढ़ता | टैग बिगड़कर विफल हो जाता है |
| अंत | Response stalled mid-stream／हैंग | टैग टेक्स्ट के रूप में दिखकर रुक जाना |
वह प्रकार जिसमें «court» टैग के साथ लीक होता है और टूल कॉल विफल हो जाता है, उसके लिए Claude Code में «court» या invoke टैग आउटपुट होने वाली त्रुटि के कारण और उपाय देखें। कारण और उपाय दोनों कुछ हद तक अलग हैं।
5. उकसाने वाली स्थितियाँ
दोनों परिघटनाओं के लिए «हमेशा होने वाली» पुनरुत्पादन-स्थिति तय नहीं है, पर रिपोर्ट्स से संभावना बढ़ाने वाले साझा कारण साफ़ दिखते हैं।
कई घंटों से कई दिनों तक चलने वाला सतत सेशन, लाखों टोकन तक का भारी संदर्भ। जितनी स्थिति जमा होती है, उतना ही यह होने की संभावना बढ़ती है।
Edit आदि से ठीक पहले जापानी जैसी भाषा में प्रस्तावना लिखते समय लूप में घुसने की संभावना बढ़ती है——ऐसी रिपोर्ट है।
सीमा-पार कनेक्शन・घरेलू लाइन・tmux के ज़रिए आदि स्ट्रीम रुकने की संभावना बढ़ाते हैं।
कई बड़ी फाइलें पढ़कर लंबी रिपोर्ट निकालने जैसे, जनरेशन को लंबा खींचने वाले काम।
6. अभी ठीक करें (उपयोगकर्ताओं के लिए)
मॉडल की ओर की पुनरावृत्ति को सेटिंग्स से जड़ से नहीं मिटाया जा सकता, इसलिए «जल्दी रोको और स्थिति रीसेट करो» ही सबसे भरोसेमंद है। प्राथमिकता का क्रम इस प्रकार है।
- तुरंत रोकें (Esc)：लूप या हैंग का पता चलते ही Esc से जनरेशन को बीच में रोकें। आउटपुट टोकन की बर्बादी रुक जाती है।
- नए सेशन में भाग निकलें：यह स्थिति-निर्भर bug है, इसलिए नया सेशन शुरू करने पर अक्सर हल हो जाता है। उसी सेशन में दोबारा कोशिश करने पर यह फिर होने की संभावना ज़्यादा है।
/clearसे संदर्भ रीसेट करें：सेशन जारी रखना हो तो संदर्भ साफ़ करके स्थिति हल्की करें（/compactस्थिति को साथ ले जाता है, इसलिए इससे हल होना अनिश्चित है）।- टूल कॉल बिना प्रस्तावना के：Edit आदि से ठीक पहले लंबा वाक्य न लिखवाकर, शून्य प्रस्तावना के साथ टूल कॉल करने का निर्देश देने से लूप से बचना आसान होता है——ऐसी रिपोर्ट है।
- काम को छोटे सेशनों में बाँटें：1 काम ＝ 1 सेशन रखकर जनरेशन समय और संदर्भ छोटा रखने से पुनरावृत्ति और स्ट्रीम रुकना दोनों कम होते हैं।
- कनेक्शन स्थिर करें：अगर stalled बार-बार होता है तो लाइन या प्रॉक्सी रूट की स्थिरता की समीक्षा करें। स्ट्रीम हो चुका हिस्सा बचा रहता है, इसलिए वहीं से आगे का निर्देश दोबारा दे दें।
✅ मुख्य बात：«दो बार चूक जाएँ तो अड़े मत रहें, नए सेशन में जाएँ»। उसी बिगड़ी स्थिति में दोबारा कोशिश करने पर मॉडल पिछली पुनरावृत्ति की नकल करके फिर वही करने लगता है।
7. डेवलपर्स के लिए——API/SDK से रोकें
अगर आप Messages API या SDK से खुद इम्प्लीमेंट कर रहे हैं, तो निम्न उपायों से नुकसान कम कर सकते हैं।
- स्ट्रीमिंग में रीड टाइमआउट सेट करें：एक तय समय तक पैकेट न आए तो रोककर दोबारा कोशिश करें। अनंत इंतज़ार से बचें (stalled का मूल कारण हल)।
- पुनरावृत्ति पहचानने वाला गार्ड：हाल के आउटपुट में एक ही टोकन／छोटी स्ट्रिंग असामान्य बार दोहराई जाए तो जनरेशन रोक दें। आउटपुट टोकन के बेकाबू उपभोग को रोकें।
- अधूरे जवाब की रीट्राई：
stop_reasonजाँचें, और बीच में खत्म हुआ हो तो बिगड़े आउटपुट को हिस्ट्री में रखे बिना दोबारा करें (बिगड़ी हिस्ट्री अगले टर्न में पुनरावृत्ति को उकसाती है)। - max_tokens की ऊपरी सीमा：कहीं बेकाबू हो भी जाए तो बिलिंग और समय की सीमा काट सकें, इसका इंतज़ाम रखें।
- टूल के आर्ग्युमेंट・प्रस्तावना छोटी रखें：लंबे आर्ग्युमेंट या लंबी प्रस्तावना उकसाने वाली स्थिति बन सकती है।
8. मिलती-जुलती त्रुटियों से अंतर
| लक्षण/संदेश | असल वजह | मुख्य उपाय |
|---|---|---|
| court को दर्जनों बार दोहराना → stalled | पुनरावृत्ति लूप ＋ स्ट्रीम रुकना (यह लेख) | Esc से रोकें → नया सेशन /clear |
| court या कच्चा invoke टैग कुछ बार लीक होना | टूल कॉल टैग की जनरेशन बिगड़ना（अलग लेख） | दो बार चूकें तो नया सेशन |
| Connection closed mid-response | स्ट्रीम का «कट» जाना（#69415） | कनेक्शन की समीक्षा・रीट्राई |
| Prompt is too long | इनपुट कॉन्टेक्स्ट की सीमा से ज़्यादा | संदर्भ घटाएँ・/clear |
| usage limit / 429 | उपयोग・रेट की सीमा | समय दें・प्लान जाँचें |
| Output blocked by content filtering policy | आउटपुट-साइड का सेफ्टी फिल्टर（अलग लेख） | शब्दशः कॉपी से बचकर दोबारा शब्दों में कहें |
9. आधिकारिक स्थिति
जुलाई 2026 तक की स्थिति को, विश्वसनीयता स्पष्ट करते हुए व्यवस्थित करते हैं।
- ✅ ज्ञात bug के रूप में मान्यता：court पुनरावृत्ति और stalled दोनों के लिए Anthropic के आधिकारिक रिपॉज़िटरी पर कई Issue हैं, और court पुनरावृत्ति पर
area:model・bugलेबल लगे हैं। - 🟡 स्थायी फिक्स की पुष्टि नहीं：इस लेख को लिखते समय «इससे ठीक हो गया» ऐसा कहा जा सके, ऐसा कोई आधिकारिक फिक्स पुष्ट नहीं है। वर्ज़न अपडेट से सुधार की संभावना है, इसलिए Claude Code को नवीनतम संस्करण पर रखना अच्छा रहेगा।
- 🟡 कारण स्थिति・एनवायरनमेंट पर निर्भर：लंबी अवधि・बड़ा कॉन्टेक्स्ट・कनेक्शन की गुणवत्ता जैसे कई कारक जुड़े हैं, और कोई एकल पुनरुत्पादन-प्रक्रिया तय नहीं हुई है।
※ स्थिति बदल सकती है। नवीनतम जानकारी के लिए Claude Code की Issue सूची और आधिकारिक एरर रेफरेंस देखें।
FAQ
Q1. «court» का कोई मतलब है?
नहीं। यह भाषा मॉडल का एक ही आउटपुट पर अटक जाना यानी «पुनरावृत्ति (डिजेनरेशन)» है, और संयोग से अटकाव «court» टोकन पर हुआ है, बस इतना ही। यह किसी दूसरे शब्द या चिह्नों की शृंखला पर भी हो सकता है। यह आपकी प्रॉम्प्ट या डेटा की समस्या नहीं है।
Q2. «Response stalled mid-stream» आने पर, अब तक का आउटपुट मिट जाता है?
नहीं मिटता। संदेश के अनुसार बस «ऊपर वाला जवाब अधूरा हो सकता है», और वहाँ तक स्ट्रीम हो चुका हिस्सा बचा रहता है। अंतिम कुछ वाक्य या टूल कॉल गायब हो सकते हैं, इसलिए वहीं से आगे का निर्देश दोबारा दे दें तो ठीक है।
Q3. दोबारा कोशिश करने से तुरंत ठीक हो जाएगा?
हल्का मामला हो तो कभी-कभी ठीक हो जाता है, पर उसी सेशन में दोबारा कोशिश करने पर यह फिर होने की संभावना ज़्यादा है। क्योंकि मॉडल पिछले बिगड़े आउटपुट (पुनरावृत्ति) की नकल कर बैठता है। दो बार चूकें तो अड़े बिना नए सेशन पर चले जाना भरोसेमंद है।
Q4. /compact करने से ठीक होगा?
अनिश्चित है। /compact संदर्भ का सारांश बनाकर स्थिति को साथ ले जाता है, इसलिए पुनरावृत्ति का कारण बचा रह सकता है। स्थिति रीसेट करनी हो तो /clear या नया सेशन ज़्यादा भरोसेमंद है।
Q5. क्या यह लेख में बताई «court/invoke टैग लीक» वाली ही bug है?
संबंध है, पर अलग है। यह लेख «court अनंत लूप में जाकर अंत में stalled पर रुकना» वाला पुनरावृत्ति ＋ स्ट्रीम रुकने का प्रकार है। टैग लीक वाला प्रकार «court या कच्चा invoke टैग कुछ बार लीक होकर टूल कॉल विफल हो जाना» है, विस्तार के लिए अलग लेख देखें।
Q6. डेवलपर के रूप में इसे मूल रूप से कैसे रोकें?
स्ट्रीमिंग में रीड टाइमआउट सेट करना, पुनरावृत्ति पहचान से असामान्य दोहराव को रोकना, और बीच में खत्म होने पर बिगड़े आउटपुट को हिस्ट्री में रखे बिना रीट्राई करना——ये तीन बातें कारगर हैं। max_tokens की सीमा भी बिलिंग और समय के बेकाबू होने को रोकती है।
Q7. यह किस समय ज़्यादा होता है?
लंबी・कई दिनों तक चलने वाली सतत सेशन, लाखों टोकन तक का भारी संदर्भ, टूल कॉल से ठीक पहले लंबा वाक्य जनरेट होना, सीमा-पार・घरेलू लाइन・tmux के ज़रिए अस्थिर कनेक्शन, लंबे आउटपुट वाले काम——आदि में संभावना बढ़ती है। 1 काम ＝ 1 सेशन रखकर छोटा रखना बचाव है।
संबंधित लेख
- Claude Code में «court» या invoke टैग आउटपुट होने वाली त्रुटि — टैग लीक प्रकार (इस लेख से अलग)
- Output blocked by content filtering policy के कारण और उपाय — आउटपुट-साइड फिल्टर की त्रुटि
- Claude Code का /loop कमांड क्या है — पुनरावृत्त निष्पादन का सही उपयोग
