Opus 5 की verbosity काबू में, एक खामी बच गई

आप Opus 5 से दो लाइन का fix माँगते हैं और जवाब में पूरी थीसिस मिलती है। Claude Code के subreddit पर "Opus 5 is insufferable" नाम का एक thread 600 upvotes और 178 comments पार कर चुका है, और लिखने वाले का आरोप है कि मॉडल एक नई भाषा बोलता है जिसे वे "Unintelligiblish" कहते हैं। Reddit तो फिर भी शालीन जगह है: X पर एक डेवलपर ने सिर्फ़ Opus 5 के बनाए code comments का screenshot डाला और 9,700 likes बटोर लिए। Claude Code के निर्माता Boris Cherny ने मॉडल का सार्वजनिक बचाव किया और उन्हें सुनना पड़ा — सबसे ऊपर वाला जवाब, "this response is part of the problem", 2,843 likes पर है।

कहाँ	संकेत
r/ClaudeCode, "Opus 5 is insufferable"	600+ upvotes, 178 comments
X, Opus 5 के code comments का screenshot	9,700 likes
X, Boris Cherny के बचाव का जवाब	2,843 likes

जब शिकायतें जमा हो रही थीं, Anthropic ने चुपचाप Opus 5 के लिए एक prompting गाइड प्रकाशित की जिसे लगभग किसी ने नहीं खोला। तो हमने वह टेस्ट किया जो कोई नहीं करता: जो व्यवहार सबको पागल कर रहे हैं उन्हें दोहराना, गाइड को लाइन दर लाइन लागू करना, और उन्हीं tasks पर फ़र्क़ नापना।

तीन बदलाव ही ज़्यादातर चीज़ें समझा देते हैं।

thinking अब डिफ़ॉल्ट रूप से चालू है: मॉडल हर जवाब से पहले एक private block में सोचता है, और उसे सिर्फ़ effort high या उससे नीचे बंद किया जा सकता है। context window एक मिलियन tokens का हो गया है — डिफ़ॉल्ट भी, अधिकतम भी। और तीसरा बदलाव verbosity की शिकायतों के लिए सबसे अहम है: effort — वह पैरामीटर जो तय करता है कि मॉडल सोचने, tools चलाने और जवाब लिखने में कितने tokens ख़र्च करे — मॉडल का मुख्य डायल बन जाता है, पाँच स्तरों के साथ, और high डिफ़ॉल्ट पर।

Effort	व्यवहार
Low	tool calls एक साथ करता है, कोई भूमिका नहीं, एक वाक्य में पुष्टि
High (डिफ़ॉल्ट)	calls कई गुना, कुछ छूने से पहले योजना समझाता है, बदलावों पर विस्तार से टिप्पणी
Extra high / Max	ज़्यादा फ़ाइलें खंगालता है, edge cases मज़बूत करता है; thinking अब बंद नहीं हो सकता

अगर दूसरी पंक्ति आपके sessions जैसी लगती है, तो वजह यही है कि आप पहले दिन से डिफ़ॉल्ट पर चल रहे हैं। effort verbosity का नॉब नहीं है — यही ग़लतफ़हमी Reddit के threads भर रही है।

एक और बात: Anthropic खुलकर कहता है कि Opus 5 पिछले Opus मॉडलों से लंबे जवाब लिखता है और placeholders छोड़ने के बजाय tasks पूरे करता है। आप जिसे bug समझ रहे हैं उसका एक हिस्सा दस्तावेज़ में दर्ज डिज़ाइन का फ़ैसला है — और दर्ज फ़ैसला दोबारा कॉन्फ़िगर हो सकता है।

इनमें से किसी को ढूँढना नहीं पड़ा।

Verbosity. हमने Opus 5 से एक function समझाने को कहा — ऐसा सवाल जिसका जवाब दो वाक्यों में आता है — और मिला sections, subheadings और चेतावनियों वाला ऑडिट रिपोर्ट जैसा जवाब। Reddit thread की सबसे ऊपर वाली टिप्पणी यही बताती है: "हमने अभी कुछ ऐसा खोजा जो सब बदल देता है" टाइप की भारी-भरकम घोषणाएँ, और उसके बाद दस मिनट के shell commands।

Over-engineering. एक यूज़र 7,000 लाइनों की decisions फ़ाइल की कहानी बताता है; सफ़ाई कहने पर Opus 5 ने 1,200 लाइनें काटीं और फिर हटाई गई चीज़ों को दस्तावेज़ करने के लिए 600 नई जोड़ दीं। हमने यही पैटर्न एक छोटे feature पर दोहराया: हमारे instance ने बिना माँगे एक verification step जोड़ा, फिर पाँच लाइन के functions पर बीस लाइन की docstrings लिख दीं।

Scope creep. आप X माँगते हैं, मॉडल तय करता है कि असली विषय Y है, और आठ पैराग्राफ़ में वजह समझाता है।

दबी हुई बुरी ख़बर. एक टिप्पणीकार बताता है कि सब बढ़िया रहा — ऐसी लंबी दीवार जैसी रिपोर्ट, जिसके तीन-चौथाई हिस्से में एक तारांकन मानता है कि कुछ टूट गया। यह हमने भी झेला: हमारे instance ने सफल migration की घोषणा की, और integration tests अब भी ठीक करने बाक़ी हैं यह लाइन सातवें पैराग्राफ़ में थी।

ग़ुस्सा असली है और माँगने पर दोहराया जा सकता है। सवाल बस यह है कि क्या यह ठीक किया जा सकता है।

गाइड का नाम है Prompting Claude Opus 5, यह Anthropic की डॉक्यूमेंटेशन में है, और Reddit thread का बिंदुवार जवाब देती है। इसका सबसे अहम वाक्य एक लाइन में आता है: effort तय करता है कि मॉडल कितना सोचता है, कितना बोलता है यह नहीं। effort घटाने से सोचने की मात्रा घटती है, पर दिखने वाला जवाब भरोसे के साथ छोटा नहीं होता — यानी मॉडल को चुप कराने के लिए effort घटाने वाले सब ग़लत लीवर खींच रहे हैं।

लंबाई के लिए गाइड साफ़ है: सीधे शब्दों में माँगिए, system prompt में एक conciseness instruction के साथ। और गाइड ऐसी बात कहती है जिसकी Anthropic से उम्मीद नहीं होती: आपको अपने prompts से instructions हटानी होंगी। अगर आपकी instructions फ़ाइल में लिखा है "जवाब देने से पहले अपना काम जाँचो", तो वह लाइन मिटा दीजिए: Opus 5 पहले ही ख़ुद को जाँचता है, और ऐसी लाइनें अतिरिक्त verification passes चालू कर देती हैं — यानी बेकार में जले हुए tokens। Boris Cherny ने एक लाइन में समेटा: Opus 5 को कम prompting चाहिए, ज़्यादा नहीं।

बाक़ी गाइड दूसरी शिकायतों को क्रम से निपटाती है — agent narration पर एक section, generated फ़ाइलों की लंबाई पर एक, scope framing पर एक, subagents पर एक, self-correction पर एक — और हर section अस्पष्ट सलाह की जगह कॉपी करने लायक़ ठीक prompt block देती है।

effort sweep का मतलब है वही task हर effort स्तर पर चलाना और tokens, समय और गुणवत्ता की तुलना करना। गाइड कहती है कि अगर आपने पुराने मॉडल की settings रखी हैं तो एक sweep दोबारा कीजिए। व्यवहार में यह चार runs और एक तुलना है।

Claude Code में effort तीन तरीक़ों से सेट होता है: session के भीतर एक command, लॉन्च पर एक flag, या settings फ़ाइल में एक key — आख़िरी वाला हर प्रोजेक्ट के लिए अलग डिफ़ॉल्ट देता है, जब आपके repos की ज़रूरतें एक जैसी न हों।

हमने वही bug fix low, medium, high और extra high पर चलाया, चार साफ़ sessions में।

स्तर	हमारे reference bug fix पर नतीजा
Low / Medium	high के tokens के एक अंश में बराबर का fix
High	डिफ़ॉल्ट; एक लाइन के bug पर गुणवत्ता में कोई फ़ायदा नहीं
Extra high	ज़्यादा फ़ाइलें खंगालीं, edge cases मज़बूत — बड़े refactor पर उपयोगी, यहाँ ज़रूरत से ज़्यादा

यह गाइड की उस सलाह से मेल खाता है कि लागत क़ाबू करने के मुख्य ज़रिये के तौर पर निचले स्तर खुलकर इस्तेमाल कीजिए। script लिखने से पहले एक API बात जान लीजिए: extra high और max पर thinking बंद नहीं किया जा सकता, और कोशिश करने पर request 400 error लौटाती है।

sweep का सबसे फ़ायदेमंद इस्तेमाल code review है। Anthropic का दावा है कि Opus 5 की review सटीकता निचले effort स्तरों पर भी टिकी रहती है, जिससे commit के वक़्त तेज़ और सस्ता pass और बाद में गहरा pass मुमकिन है। हमने इसे अपने एक diff पर परखा: low pass ने वही दो असली bugs पकड़े जो extra high pass ने पकड़े थे, लगभग पाँचवें हिस्से के tokens में।

तो आपका बिल बदलने वाली पहली सेटिंग यह है कि सब कुछ डिफ़ॉल्ट पर छोड़ने के बजाय task के हिसाब से effort चुनिए — रोज़मर्रा के काम और reviews के लिए low या medium, बड़े कामों के लिए extra high। verbosity, इस बीच, एक शब्द भी नहीं घटी।

चूँकि effort जवाब छोटे नहीं करता, लंबाई instruction से तय होती है — और वह instruction कहाँ रखी है यह उतना ही मायने रखता है जितना उसमें लिखा क्या है। Claude Code subreddit के एक और यूज़र ने दिनों तक यही परखा, और उनका पहला नतीजा हमारे जैसा है: बना-बनाया Concise output style आउटपुट सिर्फ़ लगभग 6 प्रतिशत घटाता है। काम आया एक असली conciseness instruction output style slot में रखना, और कहीं नहीं — वही वाक्य hook में या instructions फ़ाइल के नियम में रखने से कुछ नहीं बदला।

output style, Claude Code का वह slot है जो तय करता है कि assistant कैसे लिखता है, न कि वह क्या जानता है। हमने अपना आधिकारिक गाइड की भाषा से बनाया: छोटे और केंद्रित जवाब, कम चेतावनियाँ, और विस्तार माँगे बिना ऊपरी स्तर का सारांश।

conciseness नियम कहाँ है	लंबाई पर असर
बना-बनाया Concise preset	~6 प्रतिशत छोटा
hook, या instructions फ़ाइल का नियम	कोई नापने लायक़ बदलाव नहीं
output style slot	पाँच sections की रिपोर्ट → एक पैराग्राफ़ और फ़ाइलों की सूची

गाइड दो और मिलती-जुलती instructions देती है जिन्हें हमने ज्यों का त्यों कॉपी किया: एक agent narration के लिए, जो तय करती है कि मॉडल अपने काम पर कब टिप्पणी करे, और एक डिस्क पर लिखी फ़ाइलों के लिए, क्योंकि generated रिपोर्ट और Markdown फ़ाइलें भी फूलती हैं।

जो नियम कभी चलते ही नहीं, उनके लिए उसी Reddit पोस्ट में कसौटी है: नियम में एक पहचानने लायक़ मौक़ा और एक ठोस काम होना चाहिए। "changelog अपडेट रखो" कभी नहीं चलता। "जब source फ़ोल्डर की फ़ाइल बदलो, उसी commit में changelog में एक लाइन जोड़ो" चलता है।

एक आदत बची रह जाती है जिसे ये blocks नहीं ढँकते: बोल-बोलकर की जाने वाली self-correction। Opus 5 को यह बताना बहुत पसंद है कि वह पिछला वाक्य सुधार रहा है, चाहे उस सुधार से आपके लिए कुछ न बदले — और गाइड में इसके लिए अलग instruction है: सुधार तभी बताओ जब ग़लती से आपका code या फ़ैसले बदलते हों, बाक़ी चुपचाप ठीक करो। जब से यह लाइन हमारी config में आई, नक़ली माफ़ीनामे ग़ायब हो गए।

तो verbosity क़ाबू में आती है, बस स्विच से नहीं: सही slots में रखे चार prompt blocks से।

दूसरी शिकायत text जोड़ने से नहीं, हटाने से ठीक होती है। हमने पहले अपने prompts से हर verification माँग हटाई, ठीक वैसे जैसे गाइड कहती है, और अतिरिक्त verification loop उनके साथ ही ग़ायब हो गया।

फिर scope के लिए गाइड एक framing instruction देती है जिसे हमने ज्यों का त्यों चिपकाया: जो माँगा गया वही, इच्छित दायरे में दो; बेहतर तरीक़ा हो तो एक वाक्य में बताओ; और माँगे गए काम को चुपचाप बदलने के बजाय उसी पर चलते रहो। जिस feature ने बीस लाइन की docstrings कराई थीं, उसी माँग को इस framing के साथ दोहराया — diff नौ फ़ाइलों से घटकर तीन पर आ गया, बिना किसी फ़ालतू verification step के।

इसी परिवार की दो settings एक-एक लाइन की हक़दार हैं। code review के लिए "सिर्फ़ गंभीर समस्याएँ बताओ" लिखना बंद कीजिए: Opus 5 इसे शब्दशः लेता है और कम रिपोर्ट करता है, इसलिए सब माँगिए और दूसरे pass में छाँटिए। और अगर मॉडल ज़रा-ज़रा सी बात पर subagents चलाता है, वह भी दर्ज है: Opus 5 अपने पूर्ववर्तियों से ज़्यादा आसानी से काम बाँटता है, और हर subagent लागत कई गुना कर देता है। गाइड एक instruction देती है जो delegation को सचमुच parallel बड़े कामों तक सीमित रखती है, और version 2.1.217 से Claude Code दो environment variables भी देता है जो spawn की गहराई और एक साथ चलते agents पर सख़्त सीमा लगाते हैं।

सीमा	डिफ़ॉल्ट
subagent spawn गहराई	3 स्तर
एक साथ चलते agents	20

यही डिफ़ॉल्ट समझाते हैं कि एक session आपकी राय पूछे बिना इतनी दूर कैसे निकल जाता है। over-engineering मॉडल की नियति नहीं है: यह काफ़ी हद तक आपके पुराने prompts का आप पर उलटा असर है।

सीमा साफ़ है: गाइड यह ठीक करती है कि Opus 5 क्या कहता है, यह नहीं कि वह क्या करने का फ़ैसला करता है। thread की कुछ शिकायतें verbosity से अलग चीज़ बताती हैं — मॉडल एक साफ़ शर्त मानता है, उसका पालन करने का वादा करता है, और पहले ही turn से उलटा कर देता है। इस शिकायत के लिए गाइड में कोई section नहीं है, और हमारे किसी prompt block ने इसे ख़त्म नहीं किया। हमने अपने tests में एक बार देखा: एक API को न छूने की साफ़ शर्त, जवाब में मानी गई, और दो turns बाद तोड़ दी गई। एक हफ़्ते के sessions में एक बार, यह कुछ शिकायतों में बताए गए जहाज़ डूबने जैसा नहीं है, पर production code पर आ जाए तो यह वैसी ग़लती है जिसे कोई setting माफ़ नहीं करती।

एक शुरुआती लागत भी है। sweep असली tokens जलाता है: हमारे चार test sessions ने 20 डॉलर वाले plan पर एक भरपूर दिन के काम जितना खा लिया, और thread का एक यूज़र बताता है कि सबसे बड़ा max plan भी high effort पर एक weekend मुश्किल से झेलता है। और इनमें से कोई setting portable नहीं है — output style, scope framing और subagent सीमाएँ सब आपकी config में रहती हैं, इसलिए हर मशीन और हर प्रोजेक्ट फिर से सेट करना पड़ता है।

अगर आपकी तकलीफ़ शोर है, गाइड उसे ठीक कर देती है। अगर आपकी तकलीफ़ ऐसा मॉडल है जो मनमानी करता है, गाइड नहीं बचाएगी — और उस thread में असली शिकायत के बाद सबसे ज़्यादा upvote वाली टिप्पणी आज भी यही है: "पिछले Opus पर लौट जाओ"।

हमारे लिए बीस मिनट की settings काफ़ी थीं: डिफ़ॉल्ट के बजाय task के हिसाब से चुना गया effort, output style slot में एक conciseness instruction, system prompt में गाइड का scope framing, और पुरानी फ़ाइलों से हटाई गई verification माँगें।

हमारे reference task पर माप	पहले	बाद में
जवाब की लंबाई	पाँच sections की रिपोर्ट	~5× छोटा, एक पैराग्राफ़ + फ़ाइल सूची
diff का आकार	9 फ़ाइलें छुईं	3 फ़ाइलें छुईं
code review की लागत	extra high pass	~1/5 tokens, वही दो असली bugs

न मॉडल बदला, न plan। अगर आपकी शिकायतें verbosity और over-engineering हैं, मॉडल बदलने से पहले यह tuning कीजिए — सब कुछ दर्ज है, और फ़र्क़ पहले ही diff में दिख जाता है। अगर आपकी समस्या ऐसा मॉडल है जो पहले turn से आपकी शर्तें अनदेखी करता है, तो गाइड का कोई prompt इसे नहीं सुधारता: संवेदनशील काम उसी मॉडल पर रखिए जो आपकी मानता है, और अगले अपडेट पर Opus 5 दोबारा परखिए।