Claude 5.5: असफल कार्यों के लिए भुगतान करना बंद करें

Sonnet और Opus का वह सेटअप जो असल में मायने रखता है: effort, cache, verification, और हर पूरे हुए टास्क की लागत

सबसे सस्ता मॉडल वह नहीं होता जिसकी token price सबसे कम हो

वह मॉडल होता है जो काम पूरा करता है, चेक पास कर लेता है, और आपको एक ही context के लिए पाँच बार दोबारा पैसे नहीं चुकाने देता

Sonnet 5.5 और Opus 5.5 इस फर्क को बेहद अहम बना देते हैं। एक की कीमत volume के हिसाब से तय है, तो दूसरे की कठिन कामों के लिए। दोनों में नया effort behavior है, और अगर आपका agent loop अच्छी तरह cached है, तो दोनों उम्मीद से कहीं ज्यादा सस्ते साबित हो सकते हैं

अगर आप अपनी पुरानी config इनमें से किसी भी मॉडल में कॉपी-पेस्ट करेंगे, तो नतीजा या तो धीमा होगा, महँगा होगा, या फिर 400 error आ जाएगा

इसकी जगह मैं यह सेटअप बनाऊँगा

1टास्क → SONNET 5.5 → जाँच → जरूरत पड़ने पर OPUS 5.5 → वेरिफाइड रिजल्ट
2             ↘ effort ↗         ↘ cache + usage ledger ↗

मैं Substack पर AI agents, workflows और production systems के व्यावहारिक विश्लेषण प्रकाशित करता हूँ

यहाँ न्यूज़लेटर जॉइन करें

वह आँकड़ा जो आपके stack का फैसला करे

ज्यादातर मॉडल तुलनाएँ डॉलर प्रति मिलियन tokens से शुरू होती हैं

आपका agent tokens शिप नहीं करता। वह पूरे किए गए टास्क शिप करता है

https://x.com/claudeai/status/2102435511222890900

एक बार फिर: ये उनके टेस्ट हैं। आपके architecture को आपके अपने आँकड़े चाहिए

इसका मतलब है कि कोई एक शानदार जवाब पढ़कर दिया गया "ठीक है" वाला इशारा आपकी जाँच (check) नहीं हो सकता। कोडिंग के लिए वही टेस्ट इस्तेमाल करें जो merge को रोक देता। extraction के लिए, जरूरी fields को किसी labeled set से मिलाकर देखें। research के लिए, नोट करें कि क्या बताए गए source ने वाकई उस दावे का समर्थन किया है। सिर्फ अपने demo के बढ़िया उदाहरणों को ही नहीं, बल्कि उन टास्क की लागत भी जोड़ें जो कभी पास ही नहीं होते

और hard tail (कठिन मामलों) की अलग से जाँच करें। अगर सबसे सस्ती setting आपके 90% requests संभाल लेती है लेकिन बाकी 10% पर आधा budget फूँक देती है, तो उसका औसत आँकड़ा workflow के उस हिस्से को छुपा सकता है जिसे किसी दूसरे मॉडल की जरूरत है

5.5 की प्राइस लिस्ट असल में क्या कहती है

3 अक्टूबर 2026 तक, standard Claude API दरों के अनुसार, प्रति मिलियन tokens:

1SONNET 5.5
2Fresh input  $2       Output  $10
3Cache read   $0.20    Cache write  $2.50 / 5m, $4 / 1h
4
5OPUS 5.5
6Fresh input  $4       Output  $20
7Cache read   $0.20    Cache write  $5 / 5m, $8 / 1h

दोनों मॉडल में 1M-token context window और 128K-token maximum output है। ये ऊपरी सीमाएँ हैं, इन्हें भरने का कोई कारण नहीं है।

मॉडल स्पेसिफिकेशन और प्राइसिंग

यहाँ सबसे अजीब बात cache read की है

Opus में fresh input और output की कीमत दोगुनी है, लेकिन cached prefix की कीमत दोनों मॉडल में बिल्कुल एक जैसी — $0.20 प्रति मिलियन — है। इसका मतलब यह नहीं कि Opus चलाना उतना ही सस्ता हो गया: नए input, output और cache writes के लिए यह अभी भी ज्यादा चार्ज करता है। हाँ, इसका मतलब यह जरूर है कि read-heavy session में दोनों मॉडल की कीमत का फासला कम हो सकता है

एक और फर्क है जिसे लोग अक्सर नजरअंदाज कर देते हैं। Anthropic का "Opus 5 से 40% सस्ता" दावा एक सामान्य \run cost\ का अनुमान है। Opus 5.5 के fresh token की कीमतें 20% गिरीं; इसके cache-read की कीमत 60% गिरी। ये आँकड़े आपस में जुड़े हैं, लेकिन एक-दूसरे की जगह इस्तेमाल नहीं किए जा सकते

Effort कोई quality slider नहीं, बल्कि routing का फैसला है

Sonnet 5.5 low, medium, high, xhigh, और max को सपोर्ट करता है। API पर इसका default high होता है, जबकि Claude apps में Anthropic के मुताबिक medium default है। Opus 5.5 का API पर default medium है। ये levels ठीक वैसा मतलब नहीं रखते जैसा पिछले मॉडल में इन शब्दों का था।

मेरा शुरुआती खाका कुछ ऐसा है:

• Sonnet low छोटे, latency-sensitive requests के लिए जहाँ जाँच सस्ती हो
• Sonnet medium स्पष्ट रूप से तय कोडिंग और रोज़मर्रा के multi-step कामों के लिए
• Sonnet high जब medium run असली जाँच में फेल हो जाए, या टास्क में पहले से जटिलता का पैटर्न दिख रहा हो
• Opus medium ऐसे अस्पष्ट, cross-file, लंबे कामों के लिए जहाँ Sonnet बार-बार एक ही समस्या के गोल-गोल घूम रहा हो
• Xhigh/max तभी, जब आपके evals दिखाएँ कि अतिरिक्त समय और tokens खर्च करने लायक फायदा मिल रहा है

यह एक शुरुआती धारणा है, कोई पक्का नियम नहीं। Anthropic द्वारा बताए गए Sonnet 5.5 के FrontierCode नतीजों में, xhigh का स्कोर max से बेहतर रहा। यानी ज्यादा effort लगाने का मतलब हमेशा बेहतर नतीजा नहीं होता

Anthropic का footnote इस उल्टे नतीजे को समझाता है: max पर, मॉडल ने अक्सर अतिरिक्त code review का काम शुरू कर दिया। जाँचे गए दो मामलों में, इसकी वजह से timeout हो गया या टास्क के दायरे से बाहर जाकर edits हो गए।

समस्या यह नहीं थी कि "मॉडल ने काफी नहीं सोचा"। समस्या यह थी कि उसने गलत जगह effort लगाया। अगर आपका agent पहले से ही अपनी जाँच पास कर रहा है, तो अतिरिक्त review turns सिर्फ लागत बढ़ा सकते हैं और नई गलतियों का कारण बन सकते हैं

https://x.com/edwinarbus/status/2104675431853248816

साथ ही, max_tokens को कम सेट करके उसे optimization का नाम न दें। यह limit thinking और visible output दोनों पर लागू होती है। अगर आप इसे बीच में ही काट देंगे, तो पैसे बचाने के बजाय आपको अधूरा जवाब और दूसरा run खरीदना पड़ सकता है

https://x.com/claudeai/status/2104633115620823187

यह लॉन्च के लिए एक दमदार दावा है। लेकिन production config को फिर भी आपके अपने baseline को पीटना होगा

Model router बनाने से पहले एक छोटा sweep चलाएँ

ऐसे 10-30 टास्क चुनें जो आपके लिए सच में मायने रखते हैं। उनमें आसान काम, अस्पष्ट काम, और आपके logs वाले झंझट भरे failures शामिल करें। हर टास्क के लिए एक verifier तय करें: tests, structured comparison, पहले से पता जवाब, या run से पहले तय किया गया human rubric

यहाँ सबसे छोटी और काम की API probe दी गई है। यह आपके जरूरी usage fields को log करती है। इसे हर मॉडल और effort level पर उसी टास्क के साथ चलाएँ, फिर अपना pass/fail check जोड़ें। यह कोई पूरा agent benchmark नहीं है

1import anthropic
2
3client = anthropic.Anthropic()
4response = client.messages.create(
5    model="claude-sonnet-5-5",  # claude-opus-5-5 के साथ दोहराएँ
6    max_tokens=8192,
7    output_config={"effort": "medium"},  # high पर दोहराएँ
8    messages=[{"role": "user", "content": "इसे किसी असली टास्क से बदलें।"}],
9)
10
11answer = "".join(b.text for b in response.content if b.type == "text")
12usage = response.usage
13print(answer)
14print("fresh", usage.input_tokens, "output", usage.output_tokens)
15print("cache read", usage.cache_read_input_tokens)
16print("cache write", usage.cache_creation_input_tokens)

यह मानकर चल रहा है कि आपके पास official Anthropic Python package और ANTHROPIC_API_KEY environment variable है। यह caching के बिना एक अलग call है, इसलिए cache reads और writes शून्य रहने की उम्मीद है। अगला section बताता है कि इसे क्या बदलता है

किसी असली agent के लिए, एक task ID के तहत होने वाली सभी API calls (retries और tool calls सहित) के usage को जोड़ें। pass तभी गिनें जब verifier कहे कि काम पूरा हो गया है

अपना default चुनने से पहले प्रति pass कुल डॉलर की तुलना करें

टेस्ट को ईमानदार रखें:

• Configs की तुलना करने से पहले task set और verifier को freeze कर दें
• हर candidate पर same tools, permissions, context और output requirements चलाएँ
• Pass rate, कुल खर्च, प्रति pass लागत, latency, और सबसे लंबे या महँगे failures को record करें
• stop_reason: "max_tokens" को सस्ती सफलता नहीं, बल्कि अधूरी कोशिश मानें

ऊपर दिए गए छोटे code sample में single-turn probe के लिए 8K output cap का इस्तेमाल हुआ है। इस cap को किसी लंबे coding agent में कॉपी न करें।

Anthropic agentic कामों के लिए काफी ज्यादा headroom की सलाह देता है क्योंकि hidden thinking भी इसी limit में गिनी जाती है।

काम के हिसाब से cap सेट करें, फिर जवाब को बीच में रोकने के बजाय effort, caching और task budget से खर्च पर काबू रखें

काम के stable हिस्से को cache करें

Agents बार-बार same system instructions, tool definitions, repository map और पुरानी conversation भेजते हैं। अगर वह prefix stable है, तो prompt caching किसी छोटे prompt rewrite से कहीं ज्यादा economics बदल देता है

उदाहरण के लिए, 200K cached tokens को 50 बार पढ़ने का मतलब है 10M cache-read tokens। $0.20 प्रति मिलियन के हिसाब से, 5.5 के किसी भी मॉडल पर इन reads की लागत $2 होगी।

Opus 5.5 पर, उन्हीं 10M tokens को fresh input के रूप में भेजने पर $40 लगेंगे। 200K tokens के पहले पाँच मिनट वाले cache write का खर्च अलग से $1 होगा।

यह सिर्फ prefix charges का उदाहरण है: new input, output, अन्य writes, TTL expiry, और actual cache misses बिल में और जुड़ते हैं

व्यावहारिक नियम:

• Claude API पर, top-level cache_control={"type": "ephemeral"} या explicit cache breakpoints के जरिए prompt caching opt-in करें। ऊपर दी गई probe इनमें से कुछ नहीं करती, इसलिए उसके cache counters आमतौर पर शून्य ही रहेंगे
• Stable instructions और tools को बदलते user request से पहले रखें
• Turns के बीच shared prefix को बिल्कुल एक जैसा रखें; actual cache_read_input_tokens को verify करें
• Model switch को free continuation नहीं, बल्कि नया conversation budget मानें। Cache per-model होता है: Opus request उस prefix को नहीं पढ़ सकता जिसे Sonnet ने अभी cache किया है
• हर turn पर top-level effort बदलने से बचें; इससे rendered prompt बदल जाता है और cached prefixes invalid हो जाते हैं

सपोर्टेड मॉडल में, per-message effort change पहले के cache को बचा सकता है, लेकिन इसके लिए Anthropic का beta header चाहिए और यह top-level output_config बदलने जैसा नहीं है।

Sonnet 5.5 में एक between_tools शर्त भी है: उस mode में बीच conversation में effort नहीं बदला जा सकता।

Prompt caching documentation

तेज response देखकर cache hit का अंदाजा न लगाएँ। Usage object को पढ़ें। यह fresh input, cache creation और cache reads को अलग-अलग दिखाता है

दोनों 5.5 मॉडल को cacheable prefix में कम से कम 512 tokens चाहिए। कोई बहुत छोटा system prompt ऊपर दिए गए उदाहरण जैसी बचत नहीं करा पाएगा। Default cache lifetime पाँच मिनट है, जो तेज tool loop के लिए सही बैठता है।

एक घंटे वाले write की लागत ज्यादा होती है और यह तभी समझदारी है जब असली sessions अक्सर इतना रुकते हों कि पाँच मिनट की window निकल जाए। लंबे TTL के पैसे देने से पहले इन gaps को नाप लें

घबराहट में नहीं, सबूत के आधार पर escalate करें

ज्यादातर टीमें router को उल्टा बनाती हैं: टास्क को "कठिन" मान लेती हैं, उसे महँगे मॉडल पर भेज देती हैं, और कभी पता ही नहीं लगातीं कि क्या सस्ता रास्ता काम कर जाता

Verifier को routing signal की तरह इस्तेमाल करें

11  Sonnet 5.5 · चुना गया effort  → टास्क चलाएँ
22  Verifier                    → पास होने पर स्वीकार करें
33  Opus 5.5 · medium           → सिर्फ failure के सबूत होने पर retry करें
44  Verifier                    → स्वीकार करें या सबूत के साथ आगे भेजें

यह check test suite, schema validation, पता जवाब, या reviewer हो सकता है। इसे बताना चाहिए कि क्या फेल हुआ।

"जवाब थोड़ा कमजोर लग रहा है" escalate करने का खराब संकेत है, "बदले गए endpoint ने दो integration tests फेल कर दिए" काम का संकेत है

बिना सोचे बिल्कुल वैसा ही prompt दोबारा न चलाएँ। अगली कोशिश को failed check, संबंधित artifacts, और कमी सुधारने का स्पष्ट निर्देश दें। ladder पर एक सीमा तय करें ताकि agent किसी ऐसे टास्क को ठीक करने में अपना budget न फूँक दे जिसके लिए इंसानी फैसले की जरूरत हो

आप अपने offline sweep में Sonnet high retry को टेस्ट कर सकते हैं। इसे live route में तभी रखें जब यह प्रति verified task लागत कम करे। हर failure के लिए Opus से पहले दो Sonnet runs का खर्च उठवाने का कोई तुक नहीं है

Model switch खुद cached prefix को तोड़ सकता है। जब आप rescue path की तुलना Opus-first route से करें, तो इसे ध्यान में रखें

Crossover point को पकड़ना आसान नहीं होता। मान लीजिए Sonnet की एक कोशिश पर $0.06 लगते हैं और यह आपके 80% टास्क पास कर देता है।

अगर हर failed task को Opus पर पूरा करने में $0.20 लगते हैं, तो आपका उदाहरण के तौर पर औसत $0.10 प्रति पूरा टास्क होगा: $0.06 और हर पाँच में से एक टास्क पर $0.20 का rescue खर्च। यह हर टास्क पर Opus के लिए $0.20 देने से बेहतर है। लेकिन अगर Sonnet पर $0.14 लगते हैं और वह सिर्फ आधे टास्क पास करता है, तो वही ladder $0.24 का पड़ेगा, और इसमें model switch की कीमत अभी जुड़ी भी नहीं है। ऐसे workload में Opus-first सस्ता और तेज दोनों है

ये आँकड़े सिर्फ उदाहरण हैं, Claude के नापे गए नतीजे नहीं। इनका मकसद routing rule को परखा जाने लायक बनाना है। Ladder तभी सही है जब बचाए गए Opus calls का फायदा, फेल हुए Sonnet attempts, cache misses और बढ़ी हुई latency से ज्यादा हो

एक बीच का रास्ता भी है: Anthropic का beta advisor tool। Sonnet टास्क चलाता रहे और पूरा काम Opus को सौंपने के बजाय, किसी कठिन फैसले में Opus से मदद माँग ले।

यह अपने आप सस्ता नहीं होता। Log करें कि Sonnet असल में advisor से कितनी बार पूछता है, उन calls की क्या लागत है, और क्या उनसे final pass rate सुधरता है। अगर executor शायद ही कभी पूछता है, तो advisor सिर्फ एक बेकार feature है।

इन 5.5 मॉडल में, सलाह खुद encrypted होकर client को मिलती है, इसलिए यह मानकर न चलें कि आप private advice text को audit कर सकते हैं — बल्कि उसके बाद हुए काम का मूल्यांकन करें

चार ऐसी खामियाँ जो मॉडल चुनने से पहले ही बिल बढ़ा देती हैं

हर लागत की समस्या का हल नया router नहीं होता

पहले ये जाँचें:

• Output जो लगातार बढ़ता रहे दोनों 5.5 मॉडल में, output tokens की कीमत fresh input tokens से पाँच गुना है। Conversation में, कोई लंबा जवाब बाद के turns में context बनकर लौट सकता है। हर step की कहानी सुनाने के बजाय artifact और एक छोटा completion note माँगें। Hidden thinking भी output के रूप में बिल होती है, इसलिए सिर्फ छोटा final answer effort की समस्या नहीं सुलझाएगा। लेकिन result verify करने के लिए जरूरी सबूतों को दबाएँ नहीं
• जरूरत से बड़ी images Sonnet 5.5 पुराने Sonnet versions के मुकाबले higher-resolution images process कर सकता है, जिससे image token count बढ़ सकता है। अगर agent को सिर्फ button label या एक paragraph चाहिए, तो पहले crop या resize करें। अगर dense chart या छोटे UI details चाहिए, तो resolution वैसा ही रखें और उसे बिना सोचे छोटा करने के बजाय लागत नापें
• Context जिसका कोई इस्तेमाल नहीं करता Tool definitions, पुराने logs, पुराने search results, और एक फैला हुआ CLAUDE.md हर request के साथ जा सकते हैं। पक्के नियमों को एक छोटे stable prefix में रखें; अस्थायी सबूतों को उसी टास्क के पास रखें जिसे उनकी जरूरत है। Context छाँटने का मतलब वे facts हटाना नहीं होना चाहिए जो मॉडल को काम सही ढंग से पूरा करने के लिए अभी भी चाहिए
• ऐसे काम के लिए interactive pricing जिसका कोई इंतजार नहीं कर रहा Message Batches API दोनों मॉडल पर input और output में 50% छूट देता है। यह offline evaluations, document backfills और अन्य asynchronous jobs के लिए काम का है। यह live tool loop की जगह नहीं ले सकता जहाँ किसी इंसान को अगला step तुरंत चाहिए

चारों में pattern एक ही है: ज्यादा intelligence खरीदने या quality टूटने तक effort कम करने से पहले, वो काम हटा दें जिसकी टास्क को जरूरत ही नहीं है

Migration के ऐसे जाल जो बचत को 400 error में बदल देते हैं

पुराने request bodies 5.5 family के लिए खराब शुरुआत हैं।

खास तौर पर:

• Opus 5.5 में thinking हमेशा on रहती है thinking: {"type": "disabled"} और पुरानी fixed budget_tokens settings हटा दें; depth को output_config.effort से control करें
• दोनों 5.5 मॉडल में forced tool choice फेल हो जाता है

tool_choice values any और tool पर 400 error आता है। auto का इस्तेमाल करें, बताएँ कि tool कब इस्तेमाल करना है, और tool result को अपने code में validate करें

• Thinking blocks, text blocks नहीं होते Content को content [0] से नहीं, बल्कि type से पढ़ें। Tool loops में, thinking blocks को assistant turn के साथ बिना बदले लौटाएँ
• आपका UI शांत दिख सकता है Opus 5.5 पर, between-tool progress उन thinking blocks में आ सकता है जो default display setting में खाली दिखते हैं। अगर आप पहले ये notes users को दिखाते थे, तो supported thinking display mode request करें और blocks को type के हिसाब से render करें। वरना agent काम कर रहा होगा और interface जमा हुआ लगेगा
• Computer-use tool के पुराने versions फेल हो सकते हैं Browser/computer agent migrate करने से पहले current tool version जाँच लें
• छोटी max_tokens cap काम को बीच में काट सकती है

Text छिपा होने पर भी thinking शामिल होती है

ये API behavior changes हैं, prompt-writing tricks नहीं।

Opus migration guide और Sonnet migration guide

Contract अपने दिमाग में नहीं, Claude Code में रखें

API वह जगह है जहाँ आप हर usage field नाप सकते हैं। Claude Code वह जगह है जहाँ ज्यादातर लोगों को मॉडल बदलाव का पहला एहसास होगा। यही सिद्धांत लागू होता है: agent को done की एक तय सीमा दें, फिर उससे सबूत माँगें

Claude Code में, /model मॉडल चुनता है और /effort supported effort level चुनता है। Sessions की तुलना करने से पहले active settings जाँच लें। Sonnet API default इस बात का भरोसेमंद ब्योरा नहीं है कि आपका Claude app या Claude Code session अभी क्या इस्तेमाल कर रहा है

यह एक पूरा, reusable CLAUDE.md starting block है। Commands को अपने project के हिसाब से बदल लें

1# Working contract
2
3सिर्फ वही बदलाव करें जो कहा गया है। बाकी के काम को वैसा ही रहने दें।
4Edit करने के बाद संबंधित tests चलाएँ। जो check आप नहीं चला सकते, उसे report करें।
5जब माँगा गया काम पास हो जाए, रुक जाएँ। अतिरिक्त features या review loops न जोड़ें।
6अंत में यह बताएँ: Changed / Verified / Remaining risk.
7Data मिटाने, publish करने, या इस repository से बाहर कोई बदलाव करने से पहले पूछें।

यह block जादू से हर run को सस्ता नहीं बना देगा। यह success और failure को दिखाता है। इसके बाद आप same tasks पर Sonnet-first workflow की तुलना Opus-first workflow से कर सकते हैं

Task message को फिर भी specific होना पड़ेगा। "payments code ठीक करो" और उस काम में जो agent सच में पूरा कर सकता है, यही फर्क है

1Change: payment endpoint को नए client पर migrate करें
2Done: पुराना client हटा, endpoint tests पास हुए, diff सिर्फ इस path तक सीमित
3Stop: data delete करने या repo से बाहर कुछ बदलने से पहले पूछें
4Report: बदली गई files, चलाए गए exact checks, remaining risk

यह छोटा contract verifier को जाँचने के लिए कुछ ठोस देता है। यह मॉडल को रुकने का कारण भी देता है। "परफेक्ट होने तक review करो" जैसी खुली instruction एक पास होने वाले बदलाव को एक और paid loop में बदल सकती है

लंबे projects के लिए, checklist को किसी ऐसी file में रखें जो compaction के बाद भी बची रहे। Subagents के लिए, lead agent से कहें कि उनकी reports मानने से पहले उनके सबूतों की जाँच करे। और अगर आपने सिर्फ ideas माँगे हैं, तो Claude से कहें कि वह बनाना शुरू न करे। ये workflow boundaries हैं, "और smart बनो" वाले prompts नहीं

वह सेटअप जो मैं सबसे पहले ship करूँगा

• 10-30 असली टास्क चुनें और हर एक के लिए check तय करें
• Sonnet 5.5 को medium और high पर, फिर Opus 5.5 को medium पर sweep करें
• Fresh input, output, cache writes, cache reads, latency, retries, और प्रति टास्क pass/fail को log करें
• Stable prefix को cacheable रखें और usage में hits confirm करें
• सिर्फ failures को उनके सबूतों के साथ ऊपर route करें
• Workload बदलने पर ladder को दोबारा देखें। कोई saved benchmark हमेशा के लिए सच नहीं होता

अगर कठिन 10% बार-बार Sonnet failure से सीधे Opus success पर जा रहा है, तो उस पहचाने जा सकने वाले task class को शुरू से ही Opus पर route करने पर विचार करें। अगर Sonnet high उन्हीं मामलों को कम खर्च में पास कर दे, तो उन्हें वहीं रखें। Router एक नापा गया policy है, इस बारे में कोई पक्की राय नहीं कि कौन सा मॉडल ज्यादा smart है

5.5 upgrade सिर्फ "सस्ते काम के लिए Sonnet और कठिन काम के लिए Opus" नहीं है

यह मौका है कि मॉडल की कीमत तय करना बंद करें और पूरे हुए काम की कीमत तय करना शुरू करें

अगर आपने यहाँ तक पढ़ा

-> मेरा Substack सब्सक्राइब करें

-> मेरा Telegram जॉइन करें

-> इस article को bookmark करें

-> @0xwhrrari को follow करें