मुख्य कंटेंट तक स्किप करें

Effort ट्यूनिंग: 5 स्तर, मॉडल के डिफ़ॉल्ट और कैश का जाल

मध्यम

22 जुलाई 2026 को Anthropic ने effort को Claude Managed Agents के मॉडल कॉन्फ़िगरेशन में शामिल कर दिया, यानी उस नियंत्रण का चक्र पूरा हो गया जिसे Messages API ने चुपचाप पाँच स्तरों तक बढ़ा दिया था। अगर आप अब भी 2026 की शुरुआत की किसी ब्लॉग पोस्ट से messages.create के टॉप लेवल पर effort="high" कॉपी कर रहे हैं, तो आपका अनुरोध वैध दिखता है, लेकिन हो सकता है Claude वह फ़ील्ड न मान रहा हो जो आप सोचते हैं: पैरामीटर अब output_config के अंदर रहता है, और API केवल वही स्तर लागू करता है जो मॉडल कार्ड पर दर्ज हैं।

यह ट्यूनिंग की व्यावहारिक गाइड है: अनुरोध में effort असल में कहाँ जाता है, पाँचों स्तर वास्तव में क्या करते हैं (वे सिर्फ़ थिंकिंग की गहराई नहीं, टूल कॉल की संख्या बदलते हैं), हैरान करने वाले मॉडल-वार डिफ़ॉल्ट, और वह एक जाल जो चुपचाप ख़र्च बढ़ा देता है — बातचीत के बीच effort बदलने से प्रॉम्प्ट कैश अमान्य हो जाता है।

What you'll learn
  • effort फ़ील्ड को सही जगह रखना — Messages API में output_config के अंदर, Managed Agents में model ऑब्जेक्ट में, Claude Code में /effort या CLAUDE_CODE_EFFORT_LEVEL से
  • हर मॉडल के लिए शुरुआती स्तर चुनना — ज़्यादातर मॉडल पर API डिफ़ॉल्ट high है, लेकिन Opus 5.5 और Haiku 5.5 पर नहीं, जिनका डिफ़ॉल्ट medium है, और सुझाया गया शुरुआती effort इसके ऊपर भी बदलता है (एजेंटिक कोडिंग के लिए Sonnet 5.5 medium, Sonnet 4.6 medium, Opus 4.7/4.8 xhigh, Fable 5.1 high)
  • समझना कि effort सभी टोकन को प्रभावित करता है — टेक्स्ट, टूल कॉल और (जब सक्रिय हो) थिंकिंग — इसलिए effort घटाने से सिर्फ़ शब्दाडंबर नहीं, टूल कॉल की संख्या भी घटती है
  • कैश के जाल से बचना — एक ही बातचीत में effort बदलने से प्रॉम्प्ट कैशिंग अमान्य होती है और बिल चुपचाप दोगुना हो सकता है
  • Claude Code में effort की सतह जानना — /effort, ultrathink (एक टर्न), ultracode (xhigh + स्थायी मल्टीएजेंट अनुमति), एनवायरनमेंट वेरिएबल CLAUDE_CODE_EFFORT_LEVEL से ओवरराइड

पाँच स्तर (और "ultracode" कहाँ बैठता है)​

22 जुलाई 2026 तक effort स्केल में पाँच मान हैं जिन्हें API स्वीकार करता है:

स्तरयह क्या करता हैकब इस्तेमाल करें
lowसबसे कुशल। क्षमता में कुछ कमी के साथ टोकन की उल्लेखनीय बचत। कम टूल कॉल, संक्षिप्त पुष्टि, कोई भूमिका नहीं।सरल वर्गीकरण, भारी वॉल्यूम वाले वर्कलोड, चैट, देरी-संवेदनशील UX, सीमित काम करने वाले सबएजेंट
mediumसंतुलित। high की तुलना में टोकन की मध्यम बचत।ऐसे एजेंटिक काम जिनमें गति, लागत और गुणवत्ता का संतुलन चाहिए; high से लागत-सचेत एक क़दम नीचे
highउच्च क्षमता। पैरामीटर छोड़ देने के बराबर — Opus 5.5 और Haiku 5.5 को छोड़कर हर मॉडल पर, जिनका डिफ़ॉल्ट medium है।जटिल तर्क, कठिन कोडिंग, ऐसे एजेंटिक काम जहाँ गति से ज़्यादा गुणवत्ता मायने रखती है
xhighलंबी अवधि के काम के लिए विस्तारित क्षमता। high से काफ़ी ज़्यादा टोकन उपयोग की उम्मीद रखें।लंबे (30+ मिनट) एजेंटिक और कोडिंग काम, लाखों टोकन के बजट, कई फ़ाइलों में गहरे रीफ़ैक्टर
maxपूर्ण अधिकतम क्षमता, टोकन ख़र्च पर कोई रोक नहीं।केवल सचमुच अग्रणी समस्याएँ। संरचित-आउटपुट वाले कामों में ज़रूरत से ज़्यादा सोच सकता है।

न max सार्वभौमिक है, न xhigh — भेजने से पहले स्तर को मॉडल से जाँच लें। xhigh Fable 5.1, Mythos 5.1, Fable 5, Mythos 5, Opus 5.5, Opus 5, Opus 4.8, Opus 4.7, Sonnet 5.5, Sonnet 5 और Haiku 5.5 पर समर्थित है। max इन सभी के साथ Mythos Preview, Opus 4.6 और Sonnet 4.6 को भी कवर करता है। Opus 4.5 effort का समर्थन करता है, पर शीर्ष के दोनों स्तरों का नहीं। Anthropic के शब्दों में: "Not every model that supports max supports xhigh."

Pro tip
  • effort को मॉडल के अपने डिफ़ॉल्ट पर सेट करना पैरामीटर छोड़ देने जैसा ही व्यवहार देता है — ज़्यादातर मॉडल पर यह 'high' है, पर Opus 5.5 और Haiku 5.5 पर 'medium'। कैश वाली बातचीत में इसे "स्पष्ट रहने के लिए" सेट न करें, क्योंकि कुछ अनुरोधों में फ़ील्ड लिखना और कुछ में न लिखना कैश अमान्य कर देता है।
  • 'ultracode' छठा स्तर नहीं है। यह xhigh है, साथ में Claude Code को मल्टीएजेंट वर्कफ़्लो शुरू करने की स्थायी अनुमति, जो बातचीत के बीच के सिस्टम संदेशों के ज़रिए दी जाती है। API पाँच मान स्वीकार करता है।

फ़ील्ड की वह संरचना जो ज़्यादातर ब्लॉग पोस्ट ग़लत बताते हैं​

2026 की शुरुआत के effort पैरामीटर वाले लेख टॉप-लेवल फ़ील्ड दिखाते हैं:

# WRONG on current models — silently ignored or 400
client.messages.create(
    model="claude-opus-4-8",
    effort="medium",
    ...
)

मौजूदा API effort को output_config ऑब्जेक्ट के अंदर रखता है, और उसे messages/model के सहोदर के रूप में पास करता है:

effort की सही जगह — Messages API

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
  model="claude-opus-4-8",
  max_tokens=4096,
  output_config={"effort": "medium"},
  messages=[{
      "role": "user",
      "content": "Analyse the trade-offs between microservices and monoliths."
  }],
)

print(response.content[0].text)

Claude Managed Agents पर (22 जुलाई 2026 का बदलाव), effort एजेंट बनाते समय उसके model ऑब्जेक्ट के अंदर जाता है। इसे सेशन सेट नहीं करता — एजेंट का वर्ज़न करता है।

effort की सही जगह — Managed Agents (POST /v1/agents)

# Effort travels with the versioned agent config,
# not the per-run session. Every session pinned to
# this agent version runs at xhigh.

POST https://api.anthropic.com/v1/agents
{
"name": "code-reviewer",
"model": {
  "id": "claude-opus-4-8",
  "effort": "xhigh"
},
"system_prompt": "You review pull requests for security issues.",
"tools": [...],
"mcp_servers": [...]
}

Effort थिंकिंग का नियंत्रण नहीं है​

यह दूसरी बड़ी ग़लतफ़हमी है। Effort थिंकिंग चालू हो या नहीं, दोनों में काम करता है, और जवाब के उन हिस्सों में Claude जो टोकन ख़र्च करता है उन्हें बदलता है जो थिंकिंग नहीं हैं:

  • टूल कॉल। कम effort → कम कॉल। Claude कई ऑपरेशन को एक कॉल में जोड़ देता है, वैकल्पिक खोजबीन छोड़ देता है, और बिना भूमिका के सीधे कार्रवाई पर पहुँचता है।
  • टेक्स्ट की लंबाई। कम effort → कसा हुआ आउटपुट। विस्तृत सारांश की जगह टूल कॉल के बाद संक्षिप्त पुष्टि। कोड कमेंट कम।
  • थिंकिंग की गहराई (जब थिंकिंग चालू हो)। कम effort → आसान प्रॉम्प्ट पर थिंकिंग पूरी तरह छोड़ देता है; सचमुच कठिन प्रॉम्प्ट पर अब भी सोचता है, बस कम।

आख़िरी बात मायने रखती है: low effort पर भी Claude किसी प्रमाण वाली समस्या पर सोचेगा, क्योंकि काम की माँग यही है। Effort एक व्यवहारगत संकेत है, कठोर टोकन बजट नहीं। किसी कड़ी सीमा की उम्मीद न रखें।

thinking पैरामीटर और effort पैरामीटर अलग-अलग सवालों का जवाब देते हैं। thinking तय करता है कि Claude थिंकिंग ब्लॉक बनाएगा या नहीं। effort तय करता है कि पूरे जवाब में कितनी मेहनत लगे — इसमें यह भी शामिल है कि adaptive thinking चालू होने पर Claude कितनी बार और कितनी गहराई से सोचता है। effort="adaptive" पास करना एक आम ग़लती है; adaptive एक थिंकिंग मोड है, effort का स्तर नहीं।

Pro tip

Opus 4.5 पर — effort का समर्थन करने वाला इकलौता केवल-एक्सटेंडेड-थिंकिंग मॉडल — आप effort और budget_tokens एक साथ सेट करते हैं। अपने काम के लिए effort का स्तर चुनें, फिर तर्क की गहराई के हिसाब से थिंकिंग टोकन बजट तय करें। effort का समर्थन करने वाले बाक़ी सभी मॉडल adaptive thinking इस्तेमाल करते हैं और budget_tokens नहीं लेते।

मॉडल-वार शुरुआती बिंदु जो टीमों को चौंकाते हैं​

effort का समर्थन करने वाले ज़्यादातर मॉडल पर API डिफ़ॉल्ट high है — लेकिन सभी पर नहीं। Opus 5.5 और Haiku 5.5 का डिफ़ॉल्ट medium है। इसके ऊपर, Anthropic का सुझाया गया शुरुआती effort मॉडल के हिसाब से बदलता है, और यही असंगति वह जगह है जहाँ टीमें ज़्यादा या कम ख़र्च कर देती हैं।

Guided walkthrough1 of 9
  1. Opus 5.5 इकलौता Opus है जिसका डिफ़ॉल्ट medium है, इसलिए effort छोड़ने वाला अनुरोध Opus 5 पर उसी कोड की तुलना में एक स्तर नीचे चलता है। अगर माइग्रेशन के बाद गुणवत्ता गिरी है, तो सबसे पहले यही जाँचें। Adaptive thinking हमेशा चालू रहती है और बंद नहीं की जा सकती (thinking: {type: 'disabled'} हर स्तर पर 400 लौटाता है), इसलिए यह तय करने का आपका एकमात्र नियंत्रण effort है कि वह कितना तर्क करे और अनुरोध की लागत क्या हो। सेटिंग्स ढोने की बजाय effort का नया स्वीप चलाएँ — एक ही स्तर पर यह Opus 5 से ज़्यादा प्रति टर्न सोचता है।

कैश का जाल — जो बिल को चुपचाप दोगुना कर देता है​

प्रॉम्प्ट कैशिंग मानक इनपुट क़ीमत के एक अंश पर कैश रीड देती है (ज़्यादातर मॉडल पर दसवाँ हिस्सा, नए मॉडलों पर और कम — देखें Pricing)। एक ही बातचीत में अनुरोधों के बीच टॉप-लेवल output_config.effort बदलने से कैश अमान्य हो जाता है, ठीक वैसे ही जैसे मॉडल बदलने से: टॉप-लेवल effort रेंडर किए गए प्रॉम्प्ट को आकार देता है, इसलिए नया मान यानी कोई कैश्ड प्रीफ़िक्स मेल नहीं खाता। लंबे संदर्भ पर यह हर अगले टर्न पर आपके पूरे इतिहास को पूरी क़ीमत पर दोबारा पढ़ना है।

निकास मार्ग: प्रति-संदेश effort (बीटा)​

सबसे नए मॉडल कैश खोए बिना effort बदलने देते हैं। output_config.effort में नया स्तर लिए, ख़ाली content वाला एक role: "system" संदेश जोड़ें, और उससे पहले की हर चीज़ बाइट-दर-बाइट एक जैसी रहती है — इसलिए कैश्ड प्रीफ़िक्स अब भी मेल खाता है।

कैश मिस के बिना बातचीत के बीच effort बदलें

# Beta header required:
#   anthropic-beta: mid-conversation-output-config-2026-07-01

{
"model": "claude-fable-5-1",
"max_tokens": 4096,
"output_config": {"effort": "high"},
"messages": [
  {"role": "user", "content": "Plan a migration from SQLite to PostgreSQL."},
  {"role": "assistant", "content": "1. Export... 2. Create schema... 3. Import."},
  {"role": "system", "content": [], "output_config": {"effort": "low"}},
  {"role": "user", "content": "Summarize the plan in one sentence."}
]
}

19 अक्टूबर 2026 तक उपलब्धता: Claude API और Google Cloud पर यह Fable 5.1, Mythos 5.1, Opus 5.5, Opus 5, Sonnet 5.5 और Haiku 5.5 पर काम करता है; Amazon Bedrock पर केवल Fable 5.1, Mythos 5.1 और Opus 5.5 पर। इसके लिए बीटा हेडर mid-conversation-output-config-2026-07-01 चाहिए — इसके बिना प्रति-संदेश output_config 400 messages.N.output_config: Extra inputs are not permitted लौटाता है। हेडर के साथ लेकिन असमर्थित मॉडल (जिनमें Fable 5 भी है) पर आपको 400 output_config.effort requires a model that supports per-turn effort; this model does not मिलता है।

दो मॉडल थिंकिंग के पिन होने पर प्रति-टर्न effort बदलने से इनकार करते हैं: thinking: {"type": "between_tools"} वाला Sonnet 5.5 और thinking: {"type": "disabled"} वाला Haiku 5.5 400 लौटाते हैं अगर प्रति-संदेश स्तर मौजूदा स्तर से अलग हो। वहाँ effort बदलने के लिए adaptive thinking इस्तेमाल करें।

बाक़ी सब पर पुराना नियम लागू रहता है — एक स्तर चुनें और उसे थामे रखें:

Pro tip
  • प्रति-संदेश effort के बिना वाले मॉडलों पर effort को अलग-अलग वर्कलोड के बीच बदलें, कैश वाली बातचीत के अंदर नहीं। बातचीत की शुरुआत में स्तर चुनें और /clear तक उसे स्थिर रखें।
  • दोनों तरीक़े चलें तब भी टॉप-लेवल बदलाव की बजाय प्रति-संदेश effort को तरजीह दें: Fable 5.1 पर टॉप-लेवल पलटना मॉडल को कम भरोसेमंद ढंग से भी दिशा देता है, क्योंकि उसके पिछले जवाब पुराने स्तर पर लिखे गए थे और वह उनके अनुरूप बने रहने की प्रवृत्ति रखता है।
  • Claude Code में सेशन के बीच /effort मॉडल बदलने के बराबर है — अगले टर्न पर बड़े कैश मिस की उम्मीद रखें।
  • अगर सिर्फ़ एक टर्न के लिए गहराई बढ़ानी है, तो /effort xhigh की बजाय Claude Code में 'ultrathink' (एक टर्न का गहरा तर्क-बूस्ट) इस्तेमाल करें — इससे सेशन कॉन्फ़िग नहीं बदलता।
  • अगर सेशन के बाक़ी हिस्से के लिए बढ़ाना ही है, तो जल्दी करें। टर्न 3 पर बदलाव सस्ता है; टर्न 30 पर बदलाव 30 टर्न का संदर्भ पूरी क़ीमत पर दोबारा पढ़ता है।

इसका निष्कर्ष: कुछ कैश्ड अनुरोधों में effort="high" स्पष्ट रूप से सेट करना और दूसरों में छोड़ देना भी कैश को उसी तरह अमान्य करता है — क्योंकि दोनों व्यवहार में समान हैं पर टेक्स्ट में अलग। एक परिपाटी चुनें (हमेशा सेट करें, या हमेशा छोड़ें) और उस पर टिके रहें।

Claude Code — CLI की सतह​

Claude Code effort को इंटरैक्टिव कमांड, लॉन्च फ़्लैग और एनवायरनमेंट वेरिएबल के रूप में देता है (सबसे ऊँची प्राथमिकता जीतती है, उल्टे क्रम में):

# In-session (interactive slider, or direct)
/effort
/effort xhigh
/effort auto           # reset to model default

# At launch
claude --effort low

# Environment (overrides everything else)
CLAUDE_CODE_EFFORT_LEVEL=high claude

दो संबंधित कमांड जानने लायक़ हैं क्योंकि वे effort के स्तर नहीं हैं पर उनके पास का व्यवहार करते हैं:

  • ultrathink — एक टर्न के लिए गहरे तर्क का बूस्ट जो सेशन के effort को नहीं बदलता। तब इस्तेमाल करें जब आप चाहें कि अगला टर्न ज़्यादा ज़ोर से सोचे, बिना बाद के सभी टर्न पर कैश अमान्य किए।
  • ultracode — पूरे सेशन के लिए xhigh सेट करता है और Claude Code को मल्टीएजेंट वर्कफ़्लो शुरू करने की स्थायी अनुमति देता है (बातचीत के बीच के सिस्टम संदेशों के ज़रिए)। API में ultracode मान नहीं है — यह एक CLI सुविधा है जो xhigh को ऑर्केस्ट्रेशन अनुमति के साथ जोड़ती है।

याद रखने लायक़ स्थायित्व के नियम: low, medium, high और xhigh एक बार सेट करने पर Claude Code सेशनों के पार बने रहते हैं। max केवल मौजूदा सेशन पर लागू होता है — अगली बार इसे फिर लगाना पड़ता है।

ट्यूनिंग का एक वॉकथ्रू — एक प्रॉम्प्ट, तीन effort​

अंतर्ज्ञान को कैलिब्रेट करने के लिए वही प्रॉम्प्ट तीन स्तरों पर चलाएँ और आउटपुट का स्वरूप तुलना करें:

ट्यूनिंग-कैलिब्रेशन प्रॉम्प्ट (low, high, xhigh पर चलाएँ)

Task: Review this pull request for security issues.

<pr_diff>
[paste a real diff — 300+ lines, multi-file, at least one auth-touching change]
</pr_diff>

Report: severity-tagged findings + a one-line fix per finding.
Do not restate what the diff does.

मोटे तौर पर यह उम्मीद रखें:

  • low — स्पष्ट उच्च-गंभीरता वाली समस्याएँ पकड़ता है (SQL स्ट्रिंग जोड़ना, हेडर में बिना जाँचा यूज़र इनपुट)। सूक्ष्म लॉजिक बग छूट जाते हैं। टूल उपलब्ध हों तो 1-2 टूल कॉल। छोटा आउटपुट। तेज़।
  • high — पूरा विश्लेषण। सूक्ष्म वाले समेत ज़्यादातर कमज़ोरियाँ पकड़ता है। संबंधित फ़ाइलें पढ़ने के लिए कई लक्षित टूल कॉल। संरचित निष्कर्ष। ज़्यादातर टीमें यहीं रुकती हैं।
  • xhigh — विस्तृत। नए हमले के रास्तों और डिफ़ेंस-इन-डेप्थ पर विचार करता है। पास की वे फ़ाइलें पढ़ता है जिन्हें low/high ने नहीं छुआ। कहीं ज़्यादा टूल कॉल। टोकन उपयोग उल्लेखनीय रूप से ज़्यादा।

अगर आपके मूल्यांकन दिखाते हैं कि आपके कोडबेस पर high और xhigh एक जैसे निष्कर्ष देते हैं, तो high पर शिप करें। xhigh की क़ीमत ठीक तब दिखती है जब काम को बार-बार टूल कॉल और विस्तृत खोजबीन से फ़ायदा हो — और ठीक तभी Anthropic इसकी सिफ़ारिश करता है।

Sonnet 5 ने कैलिब्रेशन खिसका दिया — स्तरों को आँख मूँदकर न ले जाएँ​

अगर आप Sonnet 4.6 को high पर चला रहे थे और Sonnet 5 पर माइग्रेट हुए, तो वही स्तर रखने से Sonnet 5 उसके क़रीब ख़र्च करता है जो Sonnet 4.6 max पर करता था — Sonnet 5 का effort स्केल खिसका हुआ है। Anthropic का अपना मार्गदर्शन: Sonnet 5 medium ≈ Sonnet 4.6 high। अगर आपने effort समायोजित किए बिना ट्रैफ़िक दोबारा चलाया, तो यह प्रति-अनुरोध लागत का वह अंतर है जिसे जाँचना चाहिए। पूरी माइग्रेशन कहानी के लिए Sonnet 5 फ़ील्ड गाइड देखें।

इसे पक्का करें​

कार्ड पलटने के लिए Enter या Space दबाएँ। कार्ड बदलने के लिए बाएँ और दाएँ तीर कुंजियों का उपयोग करें।शब्द दिखाया गया।
1 / 9

ख़ुद को जाँचें

0/7
  1. इनमें से कौन-सा Messages API पर वैध effort मान नहीं है?
  2. आप 20 टर्न की कैश्ड बातचीत चला रहे हैं और टर्न 21 पर टॉप-लेवल effort को high से xhigh कर देते हैं। क्या होता है?
  3. आप Opus 5.5 पर हैं और effort पैरामीटर पूरी तरह छोड़ देते हैं। कौन-सा स्तर चलता है?
  4. आप Claude Code में हैं और चाहते हैं कि सिर्फ़ अगला टर्न सेशन की effort सेटिंग को छुए बिना ज़्यादा ज़ोर से तर्क करे। सबसे अच्छा तरीक़ा?
  5. Opus 4.8 पर effort='xhigh' के साथ, लंबी थिंकिंग के बाद आपके जवाब बार-बार stop_reason='max_tokens' के साथ कट जाते हैं। सबसे संभावित सुधार?
  6. Claude Managed Agents का एजेंट बनाते समय (जुलाई 2026 का अपडेट) effort कहाँ जाता है?
  7. कौन-सा बदलाव Sonnet 5 'medium' को 'high' पर Sonnet 4.6 के सबसे क़रीब व्यवहार कराता है?

स्रोत और आगे पढ़ें​

आगे​