Claude की adaptive thinking बनाम extended thinking: क्या बदला

Claude के "सोचने" का तरीक़ा पिछले एक साल में नाटकीय रूप से बदल गया है। पुरानी विस्तारित सोच (extended thinking) इस तरह काम करती थी कि reasoning पर मॉडल कितने token खर्च कर सकता है, यह इंसान तय करता था। मौजूदा पीढ़ी ने इसकी जगह अनुकूली सोच (adaptive thinking) को अपनाया है — मॉडल ख़ुद तय करता है कि सोचना है या नहीं, और कितनी गहराई से। और Claude Opus 5 के साथ thinking अब डिफ़ॉल्ट रूप से चालू है, इसलिए "कुछ configure नहीं किया तो thinking नहीं होगी" वाली पुरानी धारणा भी अब अतीत की बात है।

यह लेख बताता है कि extended thinking और adaptive thinking में असल फ़र्क़ क्या है, हर मॉडल का व्यवहार कैसे अलग है, और कोड migrate करने वालों को कौन-से जाल पकड़ते हैं — 400 errors, कटे हुए output और चुपचाप बढ़ते बिल। हर बात Anthropic के आधिकारिक documentation पर टिकी है।

1. Thinking क्या है

Thinking वह चरण है जहाँ Claude अंतिम जवाब लिखना शुरू करने से पहले समस्या को अपने शब्दों में सुलझाता है। वह सवाल को दोबारा कहकर देखता है, कई तरीक़े आज़माता है, बीच के नतीजे जाँचता है और जो रास्ते नहीं टिकते उन्हें छोड़ देता है — और यह पूरी प्रक्रिया response से पहले thinking content blocks के रूप में generate होती है। सबसे बड़ा फ़ायदा उन कामों में मिलता है जहाँ बीच के काम की गुणवत्ता ही जवाब की गुणवत्ता तय करती है: गणित, कोडिंग, विश्लेषण और लंबे चलने वाले agentic काम।

हालाँकि यह मुफ़्त नहीं है। जैसा कि Anthropic का "Thinking" documentation साफ़ शब्दों में कहता है, reasoning पर Claude जो token खर्च करता है, वे output tokens के तौर पर बिल होते हैं और max_tokens में गिने जाते हैं — और उन configurations में भी बिलिंग बिलकुल वही रहती है जहाँ thinking का टेक्स्ट आपको कभी लौटाया ही नहीं जाता (देखें सेक्शन 6)। यानी thinking का सेटअप डिज़ाइन करना गुणवत्ता जितना ही लागत और latency का सवाल भी है।

2. Extended thinking का दौर — budget_tokens आप तय करते थे

पहला रूप था extended thinking। आप request में thinking: {"type": "enabled", "budget_tokens": N} जोड़ते हैं, और Claude जवाब देने से पहले उसी बजट के भीतर reasoning करता है। कितना सोचना है, यह हर request पर इंसान तय करता है। आधिकारिक documentation के मुताबिक़ नियम ये हैं:

• न्यूनतम 1,024 tokens। इससे छोटी वैल्यू API अस्वीकार कर देता है
• max_tokens से कम होना ज़रूरी है — thinking उसी में गिनी जाती है, इसलिए जवाब के लिए जगह छोड़नी पड़ती है
• बजट एक लक्ष्य है, सख़्त सीमा नहीं। असल खपत टास्क के हिसाब से बदलती है, और Claude अक्सर बजट ख़त्म होने से काफ़ी पहले सोचना पूरा कर लेता है
• 32,000 से ऊपर के thinking बजट पर timeout से बचने के लिए Anthropic batch processing की सलाह देता है

इस डिज़ाइन की दिक़्क़त सीधी-सी है: सही बजट हर टास्क के लिए अलग होता है, और इंसान उसे पहले से भाँप नहीं सकता। आसान सवाल आपका दिया बजट जला सकते हैं; मुश्किल समस्याएँ उसी बजट में भूखी रह सकती हैं। और बजट की वैल्यू बदलने से आपका prompt cache invalidate हो जाता है — documentation इसे एक मापे हुए उदाहरण के साथ दिखाता है।

3. Adaptive thinking की ओर बदलाव — फ़ैसला मॉडल का

2026 में आई adaptive thinking इसी की जगह लेती है। configuration बस एक लाइन है: thinking: {"type": "adaptive"}। सोचना है या नहीं, और कितनी गहराई से — यह Claude का अपना फ़ैसला है, इस आधार पर कि request कितनी मुश्किल दिखती है। आसान inputs पर thinking छोड़कर तुरंत जवाब मिलता है; मुश्किल समस्याओं पर गहरी reasoning।

माइग्रेशन Anthropic के "Extended thinking" documentation में बताए गए शेड्यूल के मुताबिक़ हुआ: budget_tokens को Claude Opus 4.6 / Sonnet 4.6 पर deprecated किया गया (वहाँ यह अब भी चलता है), और Claude Opus 4.7 से आगे के मॉडल इसे 400 error के साथ ठुकरा देते हैं। पुराना कोड नए मॉडल पर चलाइए, और वह यहीं रुक जाता है:

# पुराना: extended thinking (Opus 4.7 और बाद के मॉडलों पर 400 error)
"thinking": {"type": "enabled", "budget_tokens": 10000}
→ 400: "thinking.type.enabled" is not supported ...

# नया: adaptive thinking (गहराई effort से सेट होती है)
"thinking": {"type": "adaptive"},
"output_config": {"effort": "high"}

बदलाव ख़ुद छोटा है — budget_tokens हटाइए, adaptive पर जाइए, और गहराई का नियंत्रण effort को सौंप दीजिए। लेकिन जैसा documentation चेताता है, यह सिर्फ़ syntax का नहीं, व्यवहार का बदलाव है। तय बजट के साथ Claude हर request पर सोचता था; adaptive thinking में कम effort settings पर वह आसान inputs पर सोचना पूरी तरह छोड़ भी सकता है।

4. हर मॉडल में thinking का व्यवहार, एक नज़र में

पेचीदा हिस्सा यह है कि "डिफ़ॉल्ट में चालू है या नहीं?" और "बंद किया जा सकता है या नहीं?" — दोनों के जवाब मॉडल-दर-मॉडल अलग हैं। आधिकारिक documentation को एक टेबल में समेटें तो तस्वीर यह है।

स्रोत: Anthropic, "Thinking" और "Extended thinking" (अगस्त 2026 तक)

व्यवहार में दो बातें मायने रखती हैं। पहली, Opus 5 पीढ़ी के साथ डिफ़ॉल्ट पलटकर "thinking चालू" हो गया — अगर आप Opus 4.8 पर thinking बंद रखकर कोई job सस्ते में चला रहे थे और सिर्फ़ model ID बदल दें, तो output tokens में thinking का हिस्सा जुड़ जाता है, और जवाब max_tokens पर कट जाते हैं या बिल बढ़ जाता है (विस्तार से Opus 5 के breaking changes पर हमारी गाइड में)। दूसरी, budget_tokens सिर्फ़ legacy मॉडल इस्तेमाल करते रहते हैं — जब तक आप Sonnet 4.5 या उससे पहले के मॉडल पर हैं, migrate करने को कुछ नहीं है; नए मॉडल पर जाते समय ही कोड बदलिए।

5. गहराई अब effort से तय होती है

"बजट" के जाने के बाद thinking की गहराई output_config: {"effort": ...} से एडजस्ट होती है — पाँच स्तर, low / medium / high / xhigh / max, जिनमें high API का डिफ़ॉल्ट है। Effort सिर्फ़ thinking की गहराई नहीं बदलता: यह इस पर भी असर डालता है कि tool calls कितने consolidated होंगे और preamble कितना मिलेगा — यानी कुल token खर्च।

पाँचों स्तरों का मतलब, Claude Code का slider और settings कैसे बनी रहती हैं — यह सब effort setting पर हमारी गाइड में है। documentation से caching का एक नोट: adaptive mode में effort की वैल्यू prompt में render होती है, इसलिए उसे बदलने से prompt cache invalidate हो जाता है — ठीक वैसे ही जैसे extended-thinking के दौर में "बजट बदला तो cache गया"। बातचीत के बीच इसे बार-बार आगे-पीछे न करें।

6. Thinking दिखे न दिखे, बिल आपको ही भरना है

बाहर से thinking कैसी दिखती है, यह display field तय करता है। इसकी दो वैल्यू हैं:

• "summarized" — thinking block में reasoning का पठनीय सारांश आता है। Claude Opus 4.6 / Sonnet 4.6 और उससे पहले के मॉडलों पर डिफ़ॉल्ट
• "omitted" — thinking block लौटता तो है, पर अंदर ख़ाली string होती है। Fable 5 / Mythos 5 / Opus 5 / Sonnet 5 / Opus 4.8 / 4.7 पर डिफ़ॉल्ट

यहाँ दो जाल छिपे हैं। पहला, मॉडल जितना नया, डिफ़ॉल्ट उतना ही "मत दिखाओ" की ओर झुका हुआ — जो app users को reasoning stream करके दिखाता था, उसे नए मॉडल पर ले जाइए, और अनुभव बन जाता है लंबी ख़ामोशी और फिर अचानक जवाब। दिखाना है तो साफ़ लिखिए: thinking: {"type": "adaptive", "display": "summarized"}। दूसरा, display सिर्फ़ दिखने-न-दिखने को बदलता है — बिलिंग एक जैसी है। documentation इस पर स्पष्ट है: omitted पर भी पूरे thinking tokens का शुल्क लगता है; जो बचता है वह latency है, लागत नहीं। और किसी भी configuration में आपको कच्ची chain of thought नहीं मिलती — summarized जो दिखाता है वह एक सारांश है।

व्यवहार में एक और अहम बात: thinking blocks को सँभालना। multi-turn बातचीत और tool use में पिछले response के thinking blocks को बिना किसी बदलाव के ज्यों का त्यों वापस भेजिए। उनमें छेड़छाड़ करने पर 400 आता है — Claude Code users जिस "invalid signature in thinking block" error से टकराते हैं, वह ठीक इसी तंत्र से निकलता है।

7. Thinking बंद करने के जाल

"हमें रफ़्तार चाहिए, thinking बंद कर दो" एक जायज़ फ़ैसला है — पर Opus 5 पर यह शर्तों के साथ आता है। आधिकारिक documentation के मुताबिक़:

request पास हो भी जाए, तो भी side effects हैं। Anthropic ने दर्ज किया है कि thinking बंद होने पर Opus 5 tool calls को body text के रूप में लिख सकता है (tool कभी चलता ही नहीं, जबकि turn ऊपर से सफल दिखता है) और output में आंतरिक XML tags leak कर सकता है। अगर आप agents बना रहे हैं, तो thinking चालू रखकर effort घटाना ही सुरक्षित रास्ता है — और लागत भी वह मोटे तौर पर उसी दिशा में घटाता है।

8. Tool calls के बीच सोचना — interleaved thinking

Thinking सिर्फ़ "जवाब से पहले, एक बार" नहीं है। interleaved thinking के साथ Claude tool calls के बीच भी reasoning करता है — हर tool result को तौलकर अगला क़दम तय करता है: search results पढ़कर योजना बदलना, पिछली command का output पढ़कर अगली command चुनना। अच्छे agentic व्यवहार के पीछे यही मशीनरी है।

यहाँ भी पीढ़ियों का फ़र्क़ है। पुराने extended-thinking के दौर में इसके लिए beta header interleaved-thinking-2025-05-14 चाहिए था; adaptive thinking में यह अपने आप होता है और header की ज़रूरत नहीं (documentation कहता है कि "adaptive thinking अपने आप interleave करती है" और migrate करने के बाद header हटाया जा सकता है)। adaptive thinking पर जाने से आपका कोड एक और setting से हल्का हो जाता है।

9. जब रफ़्तार चाहिए: fast mode

अगर आपको thinking की गुणवत्ता चाहिए पर इंतज़ार कम, तो विकल्प है fast mode। Claude Code के fast mode documentation के मुताबिक़ यह किसी दूसरे मॉडल पर downgrade नहीं है: यह वही Claude Opus है, speed-first configuration में। output क़रीब 2.5x तक तेज़ होता है और क़ीमत दोगुनी हो जाती है (Opus 5 और Opus 4.8 दोनों पर $10 in / $50 out प्रति million tokens)। यह सिर्फ़ Opus 5 और Opus 4.8 पर उपलब्ध है; Opus 4.7 का fast mode 24 जुलाई 2026 को हटा दिया गया।

Thinking, effort और fast mode की भूमिकाएँ अलग-अलग हैं: thinking = reasoning हो या नहीं, इसका तंत्र; effort = reasoning कितनी गहरी हो; fast mode = वही reasoning कितनी तेज़ी से पहुँचे। "धीमा है, thinking बंद करो" पर पहुँचने से पहले याद रखिए कि आपके हाथ में दो और पत्ते हैं: effort घटाइए, या fast mode चालू कीजिए।

सारांश

• Extended thinking (budget_tokens) पुराना तरीक़ा है। Opus 4.6 / Sonnet 4.6 पर deprecated, Opus 4.7 से आगे 400 error — और legacy मॉडलों (Sonnet 4.5 / Haiku 4.5 आदि) पर आज भी एकमात्र thinking mode
• Adaptive thinking मौजूदा तरीक़ा है। सोचना है या नहीं और कितना, यह मॉडल तय करता है; गहराई effort से (पाँच स्तर, डिफ़ॉल्ट high)
• Opus 5 / Sonnet 5 / Fable 5 पर thinking डिफ़ॉल्ट रूप से चालू है। Fable 5 इसे बंद नहीं कर सकता; Opus 5 सिर्फ़ effort high या उससे नीचे पर
• Thinking अदृश्य हो तब भी पैसा उसका लगता है। नई पीढ़ी का डिफ़ॉल्ट display: "omitted" है (ख़ाली thinking blocks)। मापिए usage.output_tokens_details.thinking_tokens से
• Thinking बंद करने के side effects हैं (tool calls text के रूप में, tags का leak)। बंद करने से effort घटाना ज़्यादा सुरक्षित है
• Adaptive में interleaved thinking अपने आप है — beta header की अब ज़रूरत नहीं
• रफ़्तार चाहिए? Fast mode (क़रीब 2.5x, 2x क़ीमत, Opus 5/4.8; Claude Code में /fast से toggle)

FAQ

नोट: इस लेख की specifications और आँकड़े Anthropic के documentation "Thinking", "Extended thinking" और Claude Code के documentation "Fast mode" पर आधारित हैं (सभी अगस्त 2026 तक)। specifications बदलती रहती हैं; इन पर कुछ बनाने से पहले आधिकारिक docs की मौजूदा wording ज़रूर देख लें।