हमारे नए Claude मॉडल्स की सबसे अच्छी बातों में से एक यह है कि वे Claude Code में prompt cache को तोड़े बिना effort के हिसाब से कैसे रिस्पॉन्स करते हैं, लेकिन मुझे यूज़र्स से इस बारे में बहुत सारे सवाल मिले हैं। आखिर effort असल में है क्या और आपको किस effort level का इस्तेमाल कब करना चाहिए? हमें effort की ज़रूरत ही क्यों है?
इसका जवाब देने के लिए, मैंने evals की गहराई में जाने और रोज़मर्रा के कामों में effort की खुद टेस्टिंग करने का फैसला किया।
नोट: आप इस पोस्ट से जुड़े और भी इंटरैक्टिव डायग्राम और एक्सप्लेनर्स यहाँ देख सकते हैं https://claude.dev/blog/spending-your-effort/
मोटे तौर पर, मैंने पाया कि effort यह बदलने का एक शानदार तरीका है कि Claude कितनी वेरिफिकेशन और edge-case टेस्टिंग करता है और वह अपने खुद के फैसले (judgement) का कितना इस्तेमाल करता है।
जिन क्षेत्रों में वेरिफिकेशन और edge-case टेस्टिंग ज़्यादा काम आती है—जैसे hardware, code review और security—वहाँ extra effort से बेहतर नतीजे मिले।
लेकिन चीज़ों को तेज़ी से निपटाने और Claude के साथ लगातार तालमेल (in the loop) बनाए रखने के लिए low और medium effort बिल्कुल सही था।
आम software engineering के लिए, अब मैं एक ऐसा लूप चलाता हूँ जिसमें पहले मॉडल से अपना इंटरव्यू करवाता हूँ, फिर low/medium effort पर उसे लागू (implement) करता हूँ, उसके बनाए हुए कोड को रिव्यू करता हूँ, और फिर high effort पर वेरिफिकेशन चलाता हूँ।
Effort क्या है?
मोटे तौर पर, effort मॉडल को यह अंदाज़ा देता है कि आप चाहते हैं कि वह किसी टास्क पर कितना compute खर्च करे। यह कुछ हद तक इस बात से जुड़ा है कि आप उस टास्क को कितना मुश्किल मानते हैं।
इसे ऐसे समझिए: अगर कोई आपसे लगातार 12 घंटे में कुछ करने को कहे, तो आप शायद सोचेंगे कि वो बस चाहता है कि आप इसे पूरा करें और इसके लिए जी-जान लगा दें। लेकिन अगर वही काम कोई 1 घंटे में करने को कहे, तो आप ऐसी बेहतरीन चीज़ बनाने की कोशिश करेंगे जो उनके काम आए, और फिर उम्मीद करेंगे कि आगे उसमें सुधार किया जाएगा।
या फिर, आप शायद पलटकर कहें कि इस काम में कम से कम 3 घंटे तो लगेंगे ही, और फिर उसे पूरा करने के लिए 3 घंटे काम करें।
Effort को भी आपको इसी तरह देखना चाहिए। Claude हमेशा आपके टास्क को ठीक-ठाक तरीके से पूरा करने की कोशिश करेगा, लेकिन higher effort का मतलब है कि Claude फैसले लेने और वेरिफिकेशन के लिए ज़्यादा स्वतंत्र रूप से काम करेगा।
Effort curves
Fable 5.1 और Opus 5.5 के effort curves अब तक के सबसे बेहतरीन हैं; हर level पर benchmark scores और इस्तेमाल किए गए tokens में बढ़ोतरी दिखती है। नीचे Terminal Bench 3.0 scores का एक ग्राफ़ दिया गया है जिसे effort के हिसाब से मापा गया है, और यह इस पोस्ट के लिए मेरे द्वारा चलाए गए eval runs का नतीजा है।
लेकिन व्यवहार में इसका क्या मतलब है? इसे जाँचने के लिए, मैंने अलग-अलग effort levels पर कई टास्क आज़माए और benchmarks को बारीकी से खंगाला।
Effort के साथ काम बनाना
मॉडल्स कैसे काम करते हैं, इसे समझने का सबसे अच्छा तरीका है एक्सपेरिमेंट्स करना। मैंने Opus 5.5 पर अलग-अलग effort levels में एक जैसे टास्क करके देखे ताकि समझ सकूँ कि यह कैसा काम करेगा। मैंने यह कई तरह के कामों पर आज़माया, लेकिन यहाँ मैं कुछ छोटे-छोटे उदाहरणों (toy examples) से इसे समझा रहा हूँ।
कम जानकारी वाला build task
अगर मैं Claude से कहूँ कि "एक personal fitness और workout tracker app बनाओ", तो effort इस बात को पूरी तरह बदल देता है कि ऐप कितना विस्तृत होगा, और साथ ही इससे Claude रास्ते में ज़्यादा फैसले खुद लेता है। Low effort पर, फिटनेस ऐप सिर्फ एक log और एक साधारण ग्राफ होता है। Higher effort levels पर ऐप ज़्यादा जटिल और बारीकियों से भरा होता है। Max effort पर इसमें एक heat chart भी होता है।
अगर मुझे आगे सुधार करने के लिए एक साधारण बुनियाद चाहिए होती, तो low effort से काम हो जाता। Max effort तब सही रहता जब मुझे Claude का पहली बार में ही सबसे बेहतरीन नतीजा चाहिए होता।
थोड़ी जानकारी वाला design task
अगर मेरे पास ऐसा टास्क है जिसकी जानकारी पहले से काफी हद तक दी गई है, लेकिन मैं Claude के साथ कुछ नया तलाशना चाहता हूँ तो क्या होगा? उदाहरण के लिए, मैंने उससे Claude Code में /config menu को दोबारा डिज़ाइन करने को कहा। हर बार उसका आईडिया लगभग एक जैसा था—submenus और बेहतर search का इस्तेमाल करना।
Low effort (जिसमें 1 मिनट लगा) पर मुझे एक इंटरैक्टिव स्केच मिला जिसने आईडिया तो समझा दिया, लेकिन वह Claude Code जैसा बिल्कुल नहीं दिखता था।
Max effort (जिसमें 28 मिनट लगे) पर मुझे एक mockup मिला जो बिल्कुल Claude Code जैसा दिखता था, और साथ में अलग-अलग flows के कई walkthroughs भी थे।
अगर मेरा मकसद सुधार करना और feedback देना होता, तो low effort से मैं बहुत जल्दी वहाँ पहुँच जाता। लेकिन max effort मुझे शुरू से ही एक बहुत ज़्यादा निखरा हुआ नतीजा देता है। इस खास टास्क के लिए, मुझे लगता है कि Claude की सोच को समझने के लिए मैं low effort का इस्तेमाल करना ही पसंद करूँगा।
पूरी जानकारी वाला build task
अगर मैं Claude को ढेर सारी बारीकियाँ दूँ तो क्या होगा? मैंने Claude से कहा कि वह फिटनेस ऐप के बारे में मेरा विस्तार से इंटरव्यू ले, और फिर उस spec को अलग-अलग मॉडल्स से अलग-अलग effort levels पर लागू करवाया।
मैंने पाया कि इस spec को मिलने के बाद, मॉडल्स ने काफी हद तक एक जैसा बर्ताव किया। मुझे ऐसे डिज़ाइन मिले जो दिखने में काफी मिलते-जुलते थे और उनका implementation भी एक जैसा था, बस बारीकियाँ अलग थीं। Max effort पर Claude ने कुछ बारीकियों को सरल बनाने में थोड़ा समय लिया।
मुख्य बातें
आम software engineering, खासकर नए features बनाने के काम में, effort level काफी हद तक इस बात पर निर्भर करता है कि मैं कितना शामिल (in the loop) रहना चाहता हूँ। Low effort से Claude जल्दी से एक शुरुआती बिंदु दे देता है, जबकि higher effort levels से ज़्यादा काम हो जाता है लेकिन Claude मेरी तरफ से ज़्यादा अनुमान (assumptions) भी खुद लगा लेता है।
Feature development के लिए मैं जिस लूप का इस्तेमाल कर रहा हूँ, वह काफी फायदेमंद साबित हुआ है:
- Claude को एक spec दें और उससे कहें कि जो बारीकियाँ छूट गई हैं, उन पर वह आपका इंटरव्यू ले
- इसे low effort पर implement करें
- रिव्यू करें कि क्या उसने मूल बात सही पकड़ी है, और ज़रूरत पड़ने पर low effort पर सुधार करें
- High effort पर वेरिफाई और टेस्ट करें
मुश्किल टास्क पर effort levels आउटपुट को कैसे प्रभावित करते हैं
लेकिन ये ज़ाहिर सी बात है कि ये छोटे-मोटे उदाहरण हैं, जिन्हें Claude आसानी से पूरा कर सकता है। लेकिन जब मामला इस बात का हो कि Claude टास्क पूरा कर पाएगा या नहीं, तब क्या होता है?
ऐसी मुश्किल समस्याओं को खोजने के लिए आपको benchmarks की तरफ जाना होगा, इसलिए मैंने अपने पसंदीदा benchmark को खंगाला: Terminal Bench 3, जो community-sourced benchmark है।
Terminal-Bench 3.0 की समस्याओं को मोटे तौर पर security, hardware, ML, science, software, operations और media जैसी श्रेणियों में बाँटा जा सकता है। आप ये सभी समस्याएँ यहाँ देख सकते हैं: https://github.com/harbor-framework/terminal-bench/releases/tag/v3.0.0, इन्हें community से लिया गया है ताकि कोई भी इसमें योगदान कर सके।
यह समझने के लिए कि इन मॉडल्स को किस तरह की समस्याओं का सामना करना पड़ता है, इसे पढ़ना फायदेमंद रहेगा। मुझे इनमें से कई टास्क के दायरे और महत्वाकांक्षा को देखकर सच में हैरानी हुई। ये मेरे रोज़मर्रा के कामों से कहीं ज़्यादा पेचीदा हैं।
उदाहरण के लिए, कुछ टास्क ये थे:
- Hardware (retro-console-soc): Verilog में एक 8-bit game console बनाएँ जो एक छोटे FPGA में फिट हो जाए और test ROM रेंडर करे।
- Science (takens-embedding-lean): Lean 4 में Takens’ embedding theorem को औपचारिक रूप से साबित करें।
- ML (mp-checkpoint-consolidation): mixture-of-experts checkpoint के 16 shards को एक फाइल में मर्ज करें जो reference logits को दोबारा बना सके।
- Operations (intrastat-meldung): किसी कंपनी की month-end EU trade-statistics filing को शुरू से अंत तक चलाएँ।
- Media (layout-config-recreation): एक poster image को editable layout file के रूप में दोबारा बनाएँ।
जब edge cases ज़्यादा हों तो higher effort levels मदद करते हैं
Terminal Bench 3 के नतीजों को पढ़कर मेरी मुख्य समझ यह रही कि जिन टास्क में बहुत सारे छिपे हुए edge cases होते हैं, उनके लिए higher effort सबसे बेहतरीन है।
इसका एक साफ उदाहरण html-js-filter है, जो Terminal-Bench 3.0 का एक टास्क है और इसमें एक HTML sanitizer बनाने को कहा जाता है जो page में JavaScript घुसाने (smuggle करने) के हर तरीके को हटा दे। Fable 5.1 low पर 1/5 से बढ़कर xhigh पर 5/5 तक पहुँच गया।
Low effort पर एक आम कोशिश में करीब 2 मिनट लगते हैं। इन कोशिशों में हर बार लगभग एक ही pass में filter लिखा गया, और फिर उसे हाथ से लिखे गए एक single page पर टेस्ट किया गया।
High effort run करीब 33 मिनट में पूरा होता है। जिस run को मैंने track किया, उसमें उसने पहले अपने initial draft की adversarial समीक्षा की, फिर bugs चेक करने के लिए installed parser का source पढ़ा, कई clean test cases चलाए जब तक कि उन्होंने input जैसा ही output नहीं दिया, एक standard XSS test suite चलाया, और आखिरकार एक random-document fuzzer लिखा।
HTML sanitizer जैसी चीज़ के लिए, जिसमें edge cases भरे पड़े हैं, यह extra effort पूरी तरह सार्थक है। performance optimization या security review जैसे complex tasks जिनमें production requirements ऊँची होती हैं, उनमें thoroughness के लिए ज़्यादा tokens खर्च करना भी समझदारी है।
लेकिन हर टास्क के लिए आपको इस level के effort की ज़रूरत नहीं होती।
नीचे दिया गया डायग्राम हर Terminal-Bench 3.0 result और उसके fail होने के कारण को दिखाता है, जो अलग-अलग models और effort levels के आधार पर है। कुल मिलाकर, effort बढ़ाने से edge cases छूटने की वजह से होने वाली failures (बैंगनी ब्लॉक) कम होती हैं, लेकिन जब मॉडल गलत approach अपनाता है (नीले ब्लॉक) तो यह उसे ठीक नहीं कर पाता।
वे समस्या वाले क्षेत्र जहाँ effort मदद करता है
TerminalBench पर इन मॉडल्स का मूल्यांकन करने से मेरे लिए सबसे दिलचस्प बात यह निकलकर आई कि कुछ ऐसे समस्या वाले क्षेत्र थे जिन्हें दूसरों की तुलना में effort से ज़्यादा फायदा हुआ। आप इसका विवरण नीचे दिए गए डायग्राम में देख सकते हैं:
इसे समझाने के लिए, मैंने Terminal Bench 3.0 के अलग-अलग क्षेत्रों से कुछ ऐसी समस्याएँ चुनीं जिनमें Opus 5.5 low effort पर fail हुआ लेकिन high effort पर pass हो गया—ज़्यादातर इसलिए क्योंकि उसने edge cases को टेस्ट किया और उन्हें ध्यान में रखा:
mvcc-lsm-compaction: Terminal-Bench 3.0 का एक टास्क जिसमें crash report के आधार पर storage-engine bug का fix माँगा गया है, बिना compaction को तोड़े। Opus 5.5 low पर 0/5 से बढ़कर xhigh पर 4/5 तक पहुँच गया।
Low (हर कोशिश में करीब एक मिनट) पर, Claude कोड build करने या reproducer चलाने से पहले ही उसे edit कर देता था, और यह चेक नहीं करता था कि क्या उसका नया test original bug को पकड़ पाता।
Xhigh (करीब 11 मिनट) पर, Claude ने पहले crash को reproduce किया, एक ऐसे reference के खिलाफ randomized test लिखा जो कभी compact नहीं होता, और यह चेक किया कि उसके tests आधे-अधूरे fixes पर fail हो रहे हैं।
cli-2ph-simple: Terminal-Bench 3.0 का एक टास्क है जिसमें Python में लिखा CLI linear-program solver माँगा गया है। Opus 5.5 low पर 0/5 से बढ़कर high पर 5/5 तक पहुँच गया।
Low attempts में एक ही pass में solver लिखा गया, कुछ छोटी problems से उसे चेक किया गया और करीब 10k tokens पर रोक दिया गया। आखिरी message में, Claude ने चेतावनी दी कि बड़ी problems पर यह slow हो सकता है, लेकिन उसने इसे चेक नहीं किया।
High attempts के दौरान Claude ने अपने solver को random problems पर एक अलग brute-force solver के खिलाफ टेस्ट किया, फिर बड़े ones का time मापा, ऐसे cases मिले जो बहुत ज़्यादा समय ले रहे थे या crash हो रहे थे, और उसने अपनी search को दोबारा तैयार किया।
gsea-proteomics: Terminal-Bench 3.0 का एक टास्क जिसमें proteomics data पर gene set enrichment analysis (GSEA) करने को कहा गया है ताकि यह पता लगाया जा सके कि आठ treatments में से कौन सा target tissue जैसा दिखता है। Opus 5.5 low पर 0/5 से बढ़कर high पर 4/5 तक पहुँच गया।
Low effort पर, Claude ने data तैयार करने का एक सुनने में सही लगने वाला तरीका चुना, analysis उसी एक तरीके से चलाया, और result बता दिया।
High पर Claude ने data तैयार करने के दो तरीके आज़माए, उसने देखा कि significant treatments की list बदल गई, और सही तरीका चुनने से पहले उसने इसकी वजह खोज निकाली।
अगर user in the loop होता, तो शायद Claude problem setup करने के तरीके के बारे में user से पूछ लेता, लेकिन user के बिना high effort बेहतर काम करता है।
Claude Code में अलग-अलग effort levels का इस्तेमाल कब करें
किस effort level का इस्तेमाल कब करना है, इस पर मेरा अनुभव यह कहता है:
- Low: जब मुझे in the loop रहते हुए तेज़ जवाब चाहिए हों, जैसे brainstorming, sketching, आसान changes
- Medium: मेरे ज़्यादातर regular software engineering work के लिए, जैसे नए feature का implementation।
- High: ऐसे काम के लिए जहाँ verification ज़रूरी हो या edge cases हों, जैसे brownfield codebase में bug fix करना।
- Max: जब मैं चाहता हूँ कि Claude मुश्किल problems सुलझाने के लिए पूरी तरह autonomously काम करे, जैसे किसी app को end to end बनाना और verify करना, या critical software में security vulnerabilities खोजना।
अपने टास्क के हिसाब से या बीच बातचीत में भी Claude Code में /effort का इस्तेमाल करके Opus 5.5 और Fable 5.1 के लिए effort बदलकर देखें, और मुझे बताएँ कि क्या यह आपकी समझ से मेल खाता है।
