हर कोडिंग काम के लिए सही Claude मॉडल टियर कैसे चुनें

जब लोग किसी AI कोडिंग असिस्टेंट के साथ बनाना शुरू करते हैं, तो वे अक्सर उपलब्ध सबसे शक्तिशाली मॉडल चुनते हैं और इसे हर चीज़ के लिए इस्तेमाल करते हैं। यह सुरक्षित लगता है — हमेशा सबसे होशियार मॉडल क्यों न इस्तेमाल करें? लेकिन सबसे होशियार मॉडल सबसे धीमा और सबसे महँगा भी है, और बहुत-से रोज़मर्रा के काम के लिए यह जरूरत से ज़्यादा है। मॉडल टियर को काम से मिलाना सीखना सबसे अधिक लीवरेज वाली आदतों में से एक है जो आप बना सकते हैं। यह पैसा बचाती है, जवाब तेज़ी से लौटाती है, और — उलटी सहज रूप से — कभी-कभी बेहतर परिणाम देती है, क्योंकि एक तेज़ मॉडल जो खत्म कर देता है आपको अधिक दोहराने देता है।

यह गाइड Anthropic की Claude लाइनअप को उदाहरण के रूप में उपयोग करती है, लेकिन सिद्धांत हर उस प्रोवाइडर पर लागू होता है जो एक मॉडल परिवार शिप करता है।

टियर, हल्के से भारी तक

2026 के मध्य तक, Claude के चार टियर हैं, हर एक क्षमता और कीमत में मोटे तौर पर एक कदम ऊपर (आधिकारिक मूल्य निर्धारण):

• Haiku 4.5 — $1 / $5 प्रति मिलियन input/output tokens। तेज़ और सस्ता। सरल, अच्छी तरह-परिभाषित काम के लिए बढ़िया।
• Sonnet 4.6 — $3 / $15। कामकाजी घोड़ा। कोडिंग और अधिकांश प्रोडक्शन कामों में मज़बूत।
• Opus 4.8 — $5 / $25। जटिल, बहु-चरणीय समस्याओं के लिए भारी तर्कशक्ति।
• Fable 5 — $10 / $50। नया Mythos-श्रेणी का फ़्लैगशिप, 9 जून, 2026 को जारी, सबसे कठिन समस्याओं के लिए।

ध्यान दें कि हर टियर पर output tokens की कीमत input tokens से पाँच गुना है, और Sonnet से Fable तक छलाँग 3x से अधिक की कीमत वृद्धि है। वही अंतराल ठीक वह कारण हैं कि टियर चुनाव क्यों मायने रखता है।

Anthropic का अपना नियम

Anthropic के मूल्य-निर्धारण दस्तावेज़ एक ताज़ा-स्पष्ट सिफ़ारिश देते हैं: "सरल कामों के लिए Haiku चुनें, अधिकांश प्रोडक्शन वर्कलोड के लिए Sonnet, और सबसे जटिल तर्क के लिए Opus।" Fable 5 उस सीढ़ी को फ़्रंटियर-स्तरीय समस्याओं के लिए एक पायदान और ऊँचा बढ़ाता है।

कोडिंग काम में अनुवादित:

• Haiku तक पहुँचें जब काम यांत्रिक हो: variables rename करना, एक regex लिखना, JSON फ़ॉर्मैट करना, boilerplate टेस्ट जनरेट करना, एक diff का सारांश देना, या एक त्वरित "यह फ़ंक्शन क्या करता है?" का जवाब देना।
• Sonnet को डिफ़ॉल्ट बनाएँ अधिकांश असली कोडिंग के लिए: एक फ़ीचर लागू करना, एक सामान्य बग ठीक करना, एक कॉम्पोनेंट लिखना, एक पुल रिक्वेस्ट की समीक्षा करना। यह आपका घर-आधार होना चाहिए।
• Opus तक बढ़ें जब किसी काम को बहुत-से कॉन्टेक्स्ट के पार असली तर्क की ज़रूरत हो: बिना स्पष्ट कारण वाला एक अस्पष्ट बग, एक मल्टी-फ़ाइल refactor जहाँ बदलाव आपस में जुड़ते हैं, या आर्किटेक्चरल डिज़ाइन फ़ैसले।
• Fable 5 को बचाएँ उस दुर्लभ समस्या के लिए जो Opus को हरा दे — एक फैला हुआ माइग्रेशन, एक सूक्ष्म concurrency बग, या ऐसा काम जो एक ही सेशन में बहुत बड़े कोडबेस में फैलता है।

एक हल किया हुआ उदाहरण

मान लीजिए आप एक वेब ऐप में एक नया "export to CSV" फ़ीचर जोड़ रहे हैं। एक टियर-जागरूक वर्कफ़्लो ऐसा दिख सकता है:

1. Opus के साथ योजना बनाएँ। "यह मेरा कोडबेस ढाँचा है। export लॉजिक कहाँ होना चाहिए, और मुझे कौन-से edge cases संभालने चाहिए?" यह तर्क-भारी है और दिशा तय करता है — बेहतर मॉडल के लायक।
2. Sonnet के साथ लागू करें। "export फ़ंक्शन लिखो और इसे एक बटन से जोड़ो।" मानक कोडिंग जिसे कामकाजी घोड़ा अच्छे से संभालता है।
3. Haiku के साथ टेस्ट और सुथरा करें। "इस फ़ंक्शन के लिए unit tests जनरेट करो" और "इस फ़ाइल को फिर से फ़ॉर्मैट करो।" सस्ता, तेज़, यांत्रिक।

महँगा मॉडल काम के सिर्फ़ उस 10% को छूता है जिसे इसकी वास्तव में ज़रूरत है। Claude Code में आप सेशन के बीच /model sonnet या /model haiku से स्विच करते हैं; Cursor में आप model dropdown से चुनते हैं। पूरा फ़ीचर उसकी एक अंश कीमत में बनता है जितनी अगर Opus या Fable हर कदम करते — और तेज़ी से खत्म होता है, क्योंकि सस्ते कदम लगभग तुरंत लौटते हैं।

टियर गिराए बिना लागत घटाएँ

टियर चुनाव सबसे बड़ा लीवर है, लेकिन दो built-in फ़ीचर इसके ऊपर ढेर हो जाते हैं:

• Prompt caching। अगर आप वही बड़ा कॉन्टेक्स्ट बार-बार भेजते हैं (एक बड़ा system prompt, एक फ़ाइल जिसका आप बार-बार संदर्भ देते हैं), तो इसे cache करना बाद के reads को input कीमत का सिर्फ़ 10% बना देता है। हर बारी कॉन्टेक्स्ट फिर से भेजने वाले एजेंट लूप के लिए, यह बहुत बड़ा है।
• Batch processing। गैर-जरूरी, उच्च-मात्रा वाले कामों के लिए — 200 फ़ाइलों के लिए टेस्ट जनरेट करना, एक docs फ़ोल्डर का अनुवाद करना — Batch API असिंक्रोनस रूप से चलता है input और output दोनों पर 50% छूट पर।

इनमें से कोई भी मॉडल की गुणवत्ता नहीं बदलता; वे बस वही काम के लिए आप जो चुकाते हैं उसे बदलते हैं।

निचोड़

सावधानी के चलते सबसे बड़े मॉडल को डिफ़ॉल्ट न बनाएँ। Sonnet को डिफ़ॉल्ट बनाएँ, जब काम मामूली हो तो Haiku पर गिरें, और Opus या Fable तक तभी चढ़ें जब कोई समस्या सचमुच गहरे तर्क की माँग करे। आप कम खर्च करेंगे, कम इंतज़ार करेंगे, और — क्योंकि आप अधिक दोहराने का खर्च उठा सकते हैं — अक्सर बेहतर कोड शिप करेंगे। लक्ष्य सबसे होशियार मॉडल इस्तेमाल करना नहीं है; यह आपके सामने वाले काम के लिए सही मॉडल इस्तेमाल करना है।