TL;DR
- करीब बीस मिनट की सेटिंग्स Opus 5 से लोगों की ज़्यादातर शिकायतें हटा देती हैं: हर काम के प्रकार के हिसाब से effort, output style स्लॉट में एक संक्षिप्तता नियम, system prompt में गाइड का scope framing, और पुरानी prompt फ़ाइलों से हर "verify your work" पंक्ति हटाना।
- Effort जवाब की लंबाई का डायल नहीं है। यह तय करता है कि मॉडल कितना सोचता है और कितने tool call करता है, दिखने वाला जवाब कितना लंबा होगा यह नहीं। मॉडल को चुप कराने के लिए इसे घटाना गलत लीवर खींचना है।
- लंबाई का नियम कहाँ रखा है, यह उसके शब्दों से ज़्यादा मायने रखता है: बिल्ट-इन Concise preset ने output को करीब 6 प्रतिशत ही बदला, वही नियम hook या instructions फ़ाइल में रखने पर कुछ नहीं बदला, और output style स्लॉट में एक असली नियम ने पाँच-सेक्शन की रिपोर्ट को एक पैराग्राफ और फ़ाइलों की सूची में बदल दिया।
- Over-engineering टेक्स्ट जोड़कर नहीं, हटाकर ठीक होती है। verification के अनुरोध हटाने और गाइड का scope framing चिपकाने से हमारा रेफ़रेंस diff नौ फ़ाइलों से तीन पर आ गया।
- हमारे review diff पर low और medium effort ने xhigh pass जैसे ही दो असली bug पकड़े, करीब पाँचवें हिस्से के tokens में।
- जो कोई prompt ब्लॉक ठीक नहीं करता: ऐसा मॉडल जो स्पष्ट constraint मानता है और दो turn बाद उसे बायपास कर देता है। हफ़्ते भर के sessions में हमने इसे एक बार देखा, और गाइड में इसका कोई सेक्शन नहीं है।
स्रोत क्या कहते हैं
नाराज़गी असली है और मापी जा सकती है। r/ClaudeCode पर "Opus 5 is insufferable" शीर्षक वाले thread को 600 से ज़्यादा upvote और 178 कमेंट मिले, और उसका लेखक मॉडल पर आरोप लगाता है कि वह एक नई भाषा बोलता है जिसे वह "Unintelligiblish" कहता है s3। X पर एक developer ने सिर्फ़ Opus 5 के बनाए code comments का स्क्रीनशॉट पोस्ट किया और 9,700 likes मिले s6। जब Claude Code के निर्माता ने सार्वजनिक रूप से मॉडल का बचाव किया, तो उन्हें घेरने वाले जवाब को 2,843 likes मिले s7।
पर्दे के पीछे के तीन बदलाव यूज़र्स के अनुभव का बड़ा हिस्सा समझाते हैं। Thinking डिफ़ॉल्ट रूप से चालू है और सिर्फ़ effort high या उससे कम पर बंद हो सकती है; context window एक मिलियन tokens पर चली गई है, डिफ़ॉल्ट भी और अधिकतम भी; और effort पैरामीटर केंद्रीय डायल बन गया है, पाँच स्तरों के साथ: low, medium, high, xhigh और max, जिनमें high डिफ़ॉल्ट है s2। यह पैरामीटर तय करता है कि मॉडल सोचने, tools बुलाने और जवाब देने में कितने tokens खर्च करे। Low effort पर मॉडल tool calls को बैच करता है, बिना भूमिका के काम करता है और एक वाक्य में पुष्टि करता है। High effort पर वह calls बढ़ाता है, कुछ छूने से पहले अपनी योजना समझाता है और अपने बदलावों पर विस्तार से टिप्पणी करता है s2। अगर दूसरा वर्णन आपके sessions जैसा लगता है, तो आप पहले दिन से डिफ़ॉल्ट पर चला रहे हैं। एक API बात जाननी चाहिए: xhigh और max पर thinking बंद नहीं की जा सकती, और कोशिश करने पर request 400 error लौटाती है s2।
जिन चार व्यवहारों पर लोग भड़कते हैं, वे जब चाहें दोहराए जा सकते हैं। बड़बोलापन: दो वाक्य के सवाल का जवाब सेक्शनों, उप-शीर्षकों और audit जैसी चेतावनियों के साथ आया; thread का सबसे ऊपर वाला कमेंट "हमने कुछ ऐसा खोजा जो सब कुछ बदल देता है" जैसी भव्य घोषणाओं के बाद दस मिनट के shell commands का वर्णन करता है s3। Over-engineering: एक यूज़र 7,000 पंक्तियों की decisions फ़ाइल बताता है, और सफ़ाई माँगने पर मॉडल ने 1,200 पंक्तियाँ काटीं और फिर हटाने का दस्तावेज़ बनाने के लिए 600 जोड़ दीं s3। Scope का फैलना: आप X माँगते हैं, मॉडल तय करता है कि असली विषय Y है और आठ पैराग्राफ में समझाता है। दबी हुई बुरी खबर: टेक्स्ट की दीवार जो कहती है सब ठीक रहा, और तीन चौथाई नीचे एक तारांकन जो मानता है कि कुछ टूट गया s3।
आधिकारिक गाइड "Prompting Claude Opus 5" thread का जवाब बिंदु-दर-बिंदु देती है। उसका सबसे अहम वाक्य: effort तय करता है कि मॉडल कितना सोचता है, कितना बोलता है यह नहीं; effort घटाने से thinking की मात्रा घटती है, पर दिखने वाला जवाब भरोसेमंद ढंग से छोटा नहीं होता s1। लंबाई साफ़ शब्दों में माँगनी पड़ती है, system prompt में संक्षिप्तता के निर्देश से। गाइड वह भी कहती है जो किसी vendor से कम लोग उम्मीद करते हैं: निर्देश हटाइए। अगर आपकी instructions फ़ाइल में "verify your work before answering" या "add a final verification step" है, तो उसे हटा दीजिए, क्योंकि Opus 5 पहले से खुद जाँच करता है और ये पंक्तियाँ ज़रूरत से ज़्यादा verification और बर्बाद tokens का कारण बनती हैं s1। Claude Code के निर्माता ने भी यही निचोड़ दिया: Opus 5 को कम prompting चाहिए, ज़्यादा नहीं s5। गाइड का बाकी हिस्सा हर शिकायत के लिए एक सेक्शन देता है: agent की narration, generate की गई फ़ाइलों की लंबाई, scope, subagents, खुद को सुधारना, हर एक में कॉपी करने लायक सटीक prompt ब्लॉक के साथ s1।
Review के बारे में गाइड का दावा है कि कम effort स्तरों पर भी review की सटीकता बनी रहती है, जिससे commit के समय तेज़ सस्ता pass और बाद में गहरा pass संभव होता है s1। वह "only report serious problems" के खिलाफ़ भी चेताती है: Opus 5 इसे शब्दशः लेता है और कम रिपोर्ट करता है, इसलिए सब कुछ माँगिए और दूसरे pass में छानिए s1। Delegation पर, Opus 5 अपने पूर्ववर्तियों से ज़्यादा आसानी से subagents बनाता है और हर एक लागत को गुणा करता है; गाइड ऐसा निर्देश देती है जो delegation को बड़े, सचमुच समानांतर काम के लिए सुरक्षित रखता है s1, और Claude Code ने संस्करण 2.1.217 से दो environment variables जोड़े हैं, CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH और CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS, जिनके डिफ़ॉल्ट तीन स्तर गहराई और बीस एक साथ चलने वाले agents हैं s9।
स्लॉट वाली खोज दूसरे thread से आती है। r/ClaudeCode के एक यूज़र ने कई दिन यह परखने में लगाए कि संक्षिप्तता का नियम कहाँ काम करता है: बिल्ट-इन Concise output style ने output को सिर्फ़ करीब 6 प्रतिशत घटाया, और वही निर्देश hook या instructions-फ़ाइल नियम के रूप में कुछ नहीं बदल सका; जो काम आया वह output style स्लॉट में असली निर्देश था s4। उसी पोस्ट में उन नियमों की कसौटी भी है जो कभी लागू नहीं होते: नियम को पहचाने जा सकने वाला क्षण और ठोस कार्रवाई बतानी चाहिए। "Keep the changelog up to date" ट्रिगर नहीं होता; "when you modify a file under src/, add a line" होता है s4।
माप
| प्रयोग | सेटअप | नतीजा |
|---|---|---|
| Effort sweep, वही bug fix | low, medium, high, xhigh, चार साफ़ sessions | low और medium ने high के tokens के एक छोटे हिस्से में बराबर का fix दिया; xhigh ने ज़्यादा फ़ाइलें खंगालीं और edge cases को मज़बूत किया |
| हमारे एक diff पर code review | low pass बनाम xhigh pass | low ने xhigh जैसे ही दो असली bug पकड़े, करीब पाँचवें हिस्से के tokens में |
| संक्षिप्तता नियम की जगह | Concise preset बनाम output style स्लॉट | preset: करीब 6 प्रतिशत छोटा; output style नियम: पाँच-सेक्शन रिपोर्ट एक पैराग्राफ और फ़ाइलों की सूची बन गई |
| docstring फ़ीचर पर scope framing | गाइड का framing चिपकाया, verification पंक्तियाँ हटाईं | diff नौ छुई गई फ़ाइलों से तीन पर आया, कोई फ़ालतू verification कदम नहीं |
| Constraint बायपास | हफ़्ते भर के sessions | एक स्पष्ट "do not touch this API" constraint माना गया, फिर दो turn बाद बायपास हो गया |
प्रोटोकॉल: हमारी अपनी repo से एक रेफ़रेंस bug fix और एक छोटा फ़ीचर, नए Claude Code sessions में दोबारा चलाए गए। Effort हर session में /effort, --effort या settings.json के effortLevel से सेट किया गया s8। संक्षिप्तता नियम गाइड के शब्दों से बनाया गया (छोटे, केंद्रित जवाब, कम caveats, विस्तार माँगे जाने तक उच्च-स्तरीय सारांश) s1। इस अभ्यास की लागत: चार sweep sessions ने 20 dollar वाले प्लान पर एक भारी कामकाजी दिन के बराबर खर्च किया, और thread का एक यूज़र बताता है कि उसका 20x प्लान effort high पर मुश्किल से एक weekend चलता है s3।
फ़ैसला
| सेटिंग | रखें, आज़माएँ या छोड़ें | क्यों |
|---|---|---|
| काम के प्रकार के हिसाब से effort (रोज़ और reviews के लिए low या medium, बड़े refactor के लिए xhigh) | रखें | review पर पाँचवें हिस्से के tokens में वही bugs मिले |
| output style स्लॉट में संक्षिप्तता नियम | रखें | अकेला स्लॉट जहाँ नियम ने output को करीब 6 प्रतिशत से ज़्यादा हिलाया |
| hook या instructions-फ़ाइल की पंक्ति के रूप में संक्षिप्तता नियम | छोड़ें | कोई मापने लायक बदलाव नहीं |
| "verify your work" पंक्तियाँ हटाना | रखें | ज़रूरत से ज़्यादा verification का loop उनके साथ गायब हो गया |
| system prompt में गाइड का scope framing | रखें | diff नौ फ़ाइलों से तीन पर |
| environment variables से subagent सीमाएँ | आज़माएँ | गहराई 3 और एक साथ 20 के डिफ़ॉल्ट बेकाबू sessions को समझाते हैं |
| review prompts में "Only report serious problems" | छोड़ें | मॉडल कम रिपोर्ट करता है; सब कुछ माँगें, बाद में छानें |
| ऐसे कामों पर Opus 5 जहाँ अनदेखा हुआ constraint स्वीकार्य नहीं | फ़िलहाल छोड़ें | हफ़्ते में एक बायपास, गाइड में इसका कोई हल नहीं |
सोमवार को यह करें
- अपनी instructions फ़ाइल खोलें और मॉडल से verify करने, दोबारा जाँचने या आख़िरी verification कदम जोड़ने को कहने वाली हर पंक्ति हटा दें।
- अपनी रोज़ की repo की settings.json में effortLevel को medium पर सेट करें, और तुलना के लिए एक refactor branch पर xhigh रखें।
- गाइड के शब्दों से संक्षिप्तता का एक नियम लिखें और उसे output style स्लॉट में रखें, hook में नहीं और instructions फ़ाइल में नहीं।
- गाइड का scope framing ब्लॉक अपने system prompt में चिपकाएँ: जो माँगा गया वह इच्छित scope पर पूरा करें, बेहतर तरीका हो तो एक वाक्य में बताएँ, माँगा गया काम जारी रखें।
- अपना अगला code review दो बार चलाएँ, एक बार low पर और एक बार xhigh पर, और गहरे pass के लिए पैसे देते रहने से पहले गिनें कि हर pass ने कितने असली bugs पकड़े।
- जो भी नियम कभी लागू नहीं होता उसे दोबारा लिखें ताकि वह एक क्षण और एक कार्रवाई बताए, "when you modify a file under src/" पैटर्न की तरह।
- CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH और CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS को एक हफ़्ते के लिए उनके डिफ़ॉल्ट से नीचे रखें और अपना token बिल देखें।
- किसी संवेदनशील repo पर prompt में एक कड़ा constraint रखें और दो turn बाद जाँचें कि मॉडल अब भी उसे मान रहा है या नहीं।
आगे पढ़ें
- पूरी "Prompting Claude Opus 5" गाइड पढ़ें, सिर्फ़ verbosity वाला सेक्शन नहीं: narration, generate की गई फ़ाइलों की लंबाई, scope, subagents और खुद को सुधारने, सबके पास कॉपी करने लायक ब्लॉक है s1।
- Effort पेज पाँच स्तरों और xhigh या max पर thinking बंद करने पर आने वाले 400 error को दर्ज करता है; हर प्रोजेक्ट के लिए effort की scripting से पहले इसे पढ़ें s2।
- Settings रेफ़रेंस दिखाता है कि effortLevel और output styles कहाँ रहते हैं, ताकि आपकी सेटिंग्स हर repo में अलग हो सकें s8।
- Subagent दस्तावेज़ 3 और 20 के डिफ़ॉल्ट के पीछे की spawn गहराई और concurrency सीमाएँ समझाता है s9।
- "How I got Opus 5 actually usable" पोस्ट में पूरा स्लॉट तुलना है, Concise preset के करीब 6 प्रतिशत वाले आँकड़े समेत s4।
- "insufferable" thread सबसे ऊपर वाले कमेंट से आगे पढ़ने लायक है: 7,000 पंक्तियों वाली decisions फ़ाइल की कहानी और constraint बायपास की रिपोर्टें लंबे जवाबों में हैं s3।
- Claude Code के निर्माता और उनके आलोचकों के बीच X पर छोटा संवाद "कम prompting, ज़्यादा नहीं" की स्थिति को कुछ पंक्तियों में रखता है s5।
स्रोत
- Prompting Claude Opus 5, Anthropic. क्यों पढ़ें: हर शिकायत के लिए सटीक prompt ब्लॉक, और यह वाक्य कि effort लंबाई का डायल नहीं है।
- Effort parameter, Anthropic. क्यों पढ़ें: पाँच स्तर, उनका व्यवहार, और xhigh व max पर thinking की बाध्यता।
- Opus 5 is insufferable, r/ClaudeCode. क्यों पढ़ें: उन व्यवहारों की सूची जिन्हें आप पहचान लेंगे, जवाबों में प्लान की लागत की रिपोर्टों के साथ।
- How I got Opus 5 actually usable, r/ClaudeCode. क्यों पढ़ें: संक्षिप्तता नियम कहाँ काम करता है, इसका अकेला स्लॉट-दर-स्लॉट परीक्षण।
- Boris Cherny on Opus 5 prompting, X. क्यों पढ़ें: maintainer का अपना नज़रिया, ज़्यादा नहीं बल्कि कम prompting।
- Screenshot of Opus 5 code comments, X. क्यों पढ़ें: 9,700 likes वाली तस्वीर जिसने verbosity की शिकायत को मुख्यधारा में पहुँचाया।
- Opus 5 output thread, X. क्यों पढ़ें: 2,843 likes वाला जवाब जो दिखाता है कि बचाव कितना कम असरदार रहा।
- Claude Code settings, Anthropic. क्यों पढ़ें: effortLevel और output styles प्रोजेक्ट के हिसाब से कहाँ रखे जाते हैं।
- Claude Agent SDK: subagents, Anthropic. क्यों पढ़ें: दो environment सीमाओं के पीछे का spawn गहराई और concurrency मॉडल।
FAQ
क्या effort घटाने से Opus 5 छोटा जवाब देता है?
नहीं। Effort thinking की मात्रा और tool calls घटाता है, दिखने वाला जवाब नहीं। लंबाई स्पष्ट संक्षिप्तता निर्देश से आती है, और हमारे परीक्षणों में output style स्लॉट वह जगह थी जहाँ यह काम किया।
क्या मुझे इसके बजाय मॉडल बदल लेना चाहिए?
अगर आपकी शिकायत शोर और over-engineering है, तो पहले बीस मिनट का सेटअप कीजिए: फ़र्क पहले diff में दिख जाता है। अगर आपकी शिकायत ऐसा मॉडल है जो स्पष्ट constraints को नज़रअंदाज़ करता है, तो गाइड में कुछ भी इसे ठीक नहीं करता; संवेदनशील कामों को ऐसे मॉडल पर रखिए जो बात मानता हो और अगले अपडेट पर दोबारा परखिए।
क्या ये सेटिंग्स एक मशीन से दूसरी में चलती हैं?
नहीं। Output style, scope framing और subagent सीमाएँ आपके config में रहती हैं, इसलिए हर मशीन और हर प्रोजेक्ट पर इन्हें दोबारा सेट करना पड़ता है।
Effort sweep की लागत कितनी है?
हमारे चार परीक्षण sessions ने 20 dollar वाले प्लान पर एक भारी कामकाजी दिन के बराबर खर्च किया। इसे एक रेफ़रेंस काम पर एक बार चलाइए, फिर हर repo के लिए डिफ़ॉल्ट चुनिए।
AIDive