SSD Nodes Learn Hosting plans →
मार्गदर्शक Matt Connorद्वारे Matt Connor · अपडेटेड 2026-08-27

Claude कोणते model वापरावे? किंमत आणि निवड मार्गदर्शक

Opus 4.8, Sonnet 5 की Haiku 4.5? July 2026 मधील modelनुसार दर, 100,000 jobsचा प्रत्यक्ष खर्च आणि बिलावर सर्वाधिक परिणाम करणाऱ्या settings पाहा.

तुम्ही कोणते Claude model वापरावे?

तुम्ही कोणते Claude model वापरावे याचे थोडक्यात उत्तर: Claude Opus 4.8 पासून सुरुवात करा आणि स्पष्ट कारण सांगता येत असेल तेव्हाच त्यापासून दूर जा. Anthropic चे मार्गदर्शनही तेच आहे. "कोणते model वापरावे याबद्दल खात्री नसल्यास, जटिल agentic coding आणि enterprise कामासाठी Claude Opus 4.8 पासून सुरुवात करा." कामाचे तपशील स्पष्ट असतील आणि ते दिवसातून अनेकदा चालवायचे असेल, तर Claude Sonnet 5 वापरा. योग्य उत्तर कसे दिसते हे आधीच माहीत असलेल्या यांत्रिक, मोठ्या प्रमाणातील कामासाठी Claude Haiku 4.5 वापरा. दीर्घकाळ चालणाऱ्या agents साठी Claude Fable 5 हे या सर्वांपेक्षा वरच्या स्तरावर आहे.

या निवडीसोबत किंमतही जोडलेली आहे. 23 July 2026 रोजी Claude API (application programming interface) वरील प्रति million tokens दर खालीलप्रमाणे आहेत. Documentation मध्ये यासाठी MTok हा संक्षेप वापरला आहे.

  • Claude Fable 5 (claude-fable-5): input साठी $10 / MTok, output साठी $50 / MTok. 1M context.
  • Claude Opus 4.8 (claude-opus-4-8): input साठी $5, output साठी $25. 1M context.
  • Claude Opus 4.7 (claude-opus-4-7): input साठी $5, output साठी $25. 1M context.
  • Claude Sonnet 5 (claude-sonnet-5): 31 August 2026 पर्यंतच्या introductory pricing अंतर्गत input साठी $2, output साठी $10. Standard दर 1 September 2026 पासून लागू होतील: input साठी $3, output साठी $15. 1M context.
  • Claude Haiku 4.5 (claude-haiku-4-5): input साठी $1, output साठी $5. 200K context.

हे identifiers जसे लिहिले आहेत तसेच पूर्ण आहेत. त्यांना शेवटी काहीही जोडले जात नाही.

1M-token मॉडेलमध्ये आकारासाठी स्वतंत्र अधिभार नाही: "900k-token विनंतीसाठी आकारले जाणारे प्रति-token दर 9k-token विनंतीइतकेच आहेत." हे दर API पुरते मर्यादित नाहीत, कारण Claude Enterprise आपल्या seat price व्यतिरिक्त API दरांनुसार वापराचे मोजमाप करते. त्यामुळे seat plan वापरणाऱ्या टीमसाठी खालील सर्व गणित तेच राहते. Flat-rate subscription मुळे मोजमापाची पद्धत बदलते, पण हा निर्णय बदलत नाही, कारण Claude Max च्या दोन्ही tiers मध्ये तीच मॉडेल्स आहेत आणि फरक फक्त उपलब्ध वापराच्या प्रमाणात आहे. त्याच श्रेणीच्या खालच्या स्तरावर, Claude Pro चे दरमहा $20 शुल्क प्रति-token दराऐवजी वापराची मर्यादा देते, त्यामुळे तिथे तुम्हाला थांबवणारी गोष्ट बिल नसून limit reset असते. तुम्ही सध्या याच स्थितीत असाल, तर तुम्ही कोणत्या window ची प्रतीक्षा करत आहात हे ठरवणे खालील गणित करण्यापूर्वी आवश्यक आहे, कारण त्यातून बाहेर पडण्याचे मार्ग म्हणजे smaller model, smaller context किंवा API कडे स्थलांतर; स्वस्त दर नव्हे. आणि तुम्ही अद्याप पैसे देण्यास सुरुवात केली नसेल, तर सुरुवातीपासूनच Pro साठी $20 देणे योग्य आहे का हे वरीलपैकी कोणत्याही दरांवर नव्हे, तर free limit तुम्हाला किती वेळा थांबवते यावर ठरते.

प्रत्येक मॉडेलचा प्रत्यक्ष उपयोग

Anthropic प्रत्येक मॉडेलचे वर्णन एका वाक्यात करते. ही वाक्ये कोणत्याही leaderboard पेक्षा योग्य मार्गदर्शन करतात.

  • Claude Fable 5: "दीर्घकाळ चालणाऱ्या agents साठी पुढील पिढीची intelligence." Latency च्या बाबतीत चारही मॉडेलमध्ये हे सर्वात धीमे आहे.
  • Claude Opus 4.8: "जटिल agentic coding आणि enterprise कामांसाठी." Latency मध्यम आहे.
  • Claude Sonnet 5: "गती आणि intelligence यांचे सर्वोत्तम संयोजन." हे जलद आहे.
  • Claude Haiku 4.5: "frontier intelligence जवळची क्षमता असलेले सर्वात जलद मॉडेल."

या चार मॉडेलपैकी Fable 5 हे एकमेव मॉडेल आहे ज्याची किंमत या तुलनेत कोणत्याही workload साठी मोजलेली नाही. Opus 4.8 च्या दराच्या दुप्पट दरामुळे कोणती कामे $10 खर्च करून $50 मिळवून देतात या प्रश्नाचे स्वतंत्र उत्तर आवश्यक ठरते.

Haiku 4.5 वर असलेल्या मर्यादा किंमतीपेक्षाही आधी त्याचा कामासाठी योग्य उपयोग ठरवतात. त्याची context window 1M ऐवजी 200K tokens आहे. त्यामुळे मोठे repository किंवा दीर्घ agent transcript त्यात बसणार नाही. Synchronous Messages API वर त्याचे maximum output इतर मॉडेलमधील 128K च्या तुलनेत 64K tokens आहे. तसेच त्याची reliable knowledge cutoff February 2025 आहे, तर इतर तीन मॉडेलसाठी ती January 2026 आहे.

प्रत्यक्ष workload वर या निवडीची किंमत किती पडते?

या lineup मधील प्रत्येक model output साठी input दराच्या पाचपट शुल्क आकारतो. Opus 4.8 साठी input $5 आणि output $25 आहे. Haiku 4.5 साठी input $1 आणि output $5 आहे. हा ratio संपूर्ण range मध्ये कायम राहतो. त्यामुळे मोठ्या प्रमाणात output निर्माण करणाऱ्या कामासाठी तुम्ही निवडलेला model सर्वाधिक महत्त्वाचा ठरतो.

Agentic काम या प्रकारात येते, कारण thinking tokens चे billing output tokens प्रमाणे केले जाते आणि मजकूर तुमच्यापर्यंत कधीच पोहोचला नाही तरी ते max_tokens मध्ये मोजले जातात. Fable 5, Opus 4.8, Opus 4.7 आणि Sonnet 5 वर reasoning summary default स्वरूपात वगळला जातो. त्यामुळे thinking field रिकामे मिळते. Billing मध्ये मात्र कोणताही बदल होत नाही: "दोन्ही परिस्थितींमध्ये block साठी समान billing केले जाते आणि multi-turn conversations मध्ये तोच block परत पाठवला जातो." Claude token bill मध्ये प्रत्यक्षात काय समाविष्ट होते हा meter संपूर्णपणे स्पष्ट करतो.

तुम्ही तुलना करत असलेल्या models मध्ये thinking प्रत्यक्षात चालते की नाही, यात फरक असतो. हा फरक लक्षात न घेतल्यास cost test चे परिणाम चुकीचे येतील. Sonnet 5 आणि Fable 5 वर thinking आधीपासून enabled आहे आणि configuration आवश्यक नाही. Opus 4.8 आणि Opus 4.7 वर request मध्ये thinking: {type: "adaptive"} set करेपर्यंत ते disabled असते. आकड्यांचा अर्थ लावण्यापूर्वी दोन्ही बाजूंची configuration समान ठेवा.

सर्वात स्वस्त model सर्वात महाग का ठरू शकतो

एक स्वतंत्र coding task घ्या. Request मध्ये 60,000 tokens चा context आहे आणि model thinking धरून 8,000 tokens चे output तयार करतो. Caching नसल्यामुळे हिशोब स्पष्ट दिसतो.

Opus 4.8 वर 0.06 MTok input साठी $5 प्रमाणे $0.30 आणि 0.008 MTok output साठी $25 प्रमाणे $0.20 लागतात. त्यामुळे एका प्रयत्नाची किंमत $0.50 होते. Haiku 4.5 वर त्याच प्रयत्नासाठी $0.06 अधिक $0.04, म्हणजे $0.10 लागतात.

प्रत्येक प्रयत्नासाठी Haiku पाच पट स्वस्त आहे. अयशस्वी प्रयत्नाचा परिणाम पाहेपर्यंत ही मोठी बचत वाटते. तुम्ही चुकीचे उत्तर वाचता आणि त्यासाठी तुमचा वेळ खर्च होतो. Retry करताना ते उत्तर context म्हणून पुन्हा पाठवता. त्यामुळे प्रत्येक पुढील प्रयत्न मागील प्रयत्नापेक्षा मोठा होतो. तिसरा प्रयत्नही अयशस्वी झाल्यावर तुम्ही तरीही Opus कडे जाता: Haiku चे $0.30 अधिक Opus चे $0.50, म्हणजे एकूण $0.80. Opus एकदाच चालवण्यापेक्षा ही किंमत 60% अधिक आहे.

म्हणून निर्णायक प्रश्न असा आहे की तुम्ही उत्तर किती कमी खर्चात तपासू शकता. चुकीचे उत्तर एका सेकंदात स्पष्ट दिसत असेल, तर छोटा model फायदेशीर ठरतो. पण ते ओळखण्यासाठी diff काळजीपूर्वक वाचावा लागत असेल, तर छोटा model तुमचा असा वेळ खर्च करतो जो invoice वर कधीच दिसत नाही.

लहान मॉडेल स्पष्टपणे अधिक योग्य ठरणारी ठिकाणे

या प्रकरणांमध्ये Haiku 4.5 हा योग्य पर्याय आहे:

  • यांत्रिक subagent काम. फाइलची नावे बदलणाऱ्या किंवा search output गोळा करणाऱ्या subagent ला अत्याधुनिक reasoning ची गरज नसते. तुम्ही Claude सह AI agent तयार करता आणि त्याला helpers देता, तेव्हा हीच नेहमीची रचना असते.
  • Log triage. एखादी ओळ निरुपयोगी आहे की मानवी लक्ष देण्यासारखी आहे, हे ठरवणे हा मर्यादित आवाका असलेला निर्णय आहे आणि त्यातील अपयशाचे स्वरूप स्पष्ट असते.
  • निश्चित label set विरुद्ध classification. Output लहान असतो आणि sample वर accuracy मोजता येते.
  • मोठ्या प्रमाणातील production calls. दररोज 100,000 runs असल्यास प्रति-token मधील फरक नगण्य राहत नाही. n8n मध्ये जोडलेल्या AI workflows चे नेहमीचे स्वरूप असेच असते.
  • वापरकर्त्यासाठी response speed महत्त्वाची असलेली कोणतीही कामे. Haiku 4.5 ला lineup मधील सर्वात वेगवान model म्हणून rated केले आहे.

एक मर्यादा विशेषतः Haiku साठी लागू होते. त्याचा cacheable prompt किमान 4,096 tokens चा असावा; Opus 4.8 आणि Sonnet 5 साठी ही मर्यादा 1,024 आहे. या किमान मर्यादेपेक्षा कमी असल्यास "या संख्येपेक्षा कमी tokens cache करण्याच्या कोणत्याही requests caching शिवाय process केल्या जातील आणि कोणताही error परत केला जाणार नाही". Sonnet 5 वर cache होणारा 1,500-token instruction block Haiku 4.5 वर कोणतीही सूचना न देता cache होत नाही. cache_creation_input_tokens आणि cache_read_input_tokens दोन्ही zero असणे हे त्याचे लक्षण आहे. नेहमी सुरू असलेल्या agent चा खर्च कमी ठेवणे या विषयात cache गमावण्याचे इतर मार्गांसह याचेही स्पष्टीकरण दिले आहे.

उत्तर बदलणारे घटक

यापैकी प्रत्येक घटक model name पेक्षा बिलावर अधिक परिणाम करतो.

Effort. output_config.effort हे उत्तर देण्यापूर्वी model किती काम करेल हे नियंत्रित करते. याचे स्तर low, medium, high, xhigh आणि max आहेत. high हे default आहे: "effort ला high वर सेट केल्यास effort parameter पूर्णपणे वगळल्यासारखेच वर्तन मिळते." हे request च्या top level वर नसून output_config मध्ये अंतर्भूत असते:

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=4096,
    output_config={"effort": "medium"},
    messages=messages,
)

Effort चा परिणाम response मधील प्रत्येक token वर होतो: "याचा परिणाम tool calls सहित एकूण token वापरावर होऊ शकतो. उदाहरणार्थ, कमी effort मुळे Claude कमी tool calls करेल." Agentic loop मध्ये हा परिणाम वाढत जातो. हे token cap नाही: "Effort हा behavioral signal आहे; तो कठोर token budget नाही." Anthropic प्रत्येक स्तरासाठी cost multiplier प्रकाशित करत नाही आणि तुमच्या use case वर चाचणी घेण्यास सांगते. त्यामुळे high वर चालवलेला Sonnet 5 run आणि low वर चालवलेला Opus 4.8 run ही तुम्ही आजच प्रत्यक्ष तुलना करू शकता. Effort ला support करणाऱ्या models च्या यादीत Haiku 4.5 नाही.

Prompt caching. Cache read साठी base input rate च्या 0.1x इतका खर्च येतो. त्यामुळे model निवडताना महत्त्वाचा मुद्दा म्हणजे हा परिणाम वेगवेगळ्या tiers मध्ये कसा बदलतो. Opus 4.8 वरील cache hit साठी $0.50 / MTok खर्च येतो, तर Haiku 4.5 वरील uncached input साठी $1 / MTok खर्च येतो. त्यामुळे व्यवस्थित cache केलेला Opus prefix हा cold Haiku prompt पेक्षा प्रत्येक input token साठी स्वस्त ठरतो. मोठा आणि स्थिर prefix पुन्हा पाठवणाऱ्या कोणत्याही workload मध्ये model निवडीपेक्षा session hygiene अधिक महत्त्वाची ठरते.

Batches. उत्तराची वाट पाहणारी कोणतीही प्रक्रिया नसल्यास, Message Batches API तेच models input आणि output tokens वर "50% discount" देऊन चालवते. त्यामुळे खालील तुलनेतील प्रत्येक row चा खर्च निम्मा होतो. हे सर्व tiers मध्ये लागू होते: 1 September 2026 पासूनच्या standard price नुसार, batched Opus 4.8 job ची किंमत synchronous Sonnet 5 job पेक्षा कमी असते. समान खर्चात capability टिकवून latency वाढते.

एक प्रत्यक्ष खर्च तुलना

कामाचे स्वरूप: 100,000 support emails चे वर्गीकरण करायचे आहे. प्रत्येक email साठी एक call, 2,000 input tokens आणि 300 output tokens आहेत. म्हणजे एकूण 200 MTok input आणि 30 MTok output.

  • Haiku 4.5: 200 x $1 = $200 input, 30 x $5 = $150 output. एकूण $350.
  • Sonnet 5, प्रारंभिक दर: 200 x $2 = $400 input, 30 x $10 = $300 output. एकूण $700.
  • Sonnet 5, 1 September 2026 पासून: 200 x $3 = $600 input, 30 x $15 = $450 output. एकूण $1,050.
  • Opus 4.8: 200 x $5 = $1,000 input, 30 x $25 = $750 output. एकूण $1,750.

उद्याचे दर वापरून ही गणना पुन्हा करण्यासाठी चार संख्या बदला. खालील समायोजनांचा परिणाम model name पेक्षा अधिक मोठा आहे:

  • Batching मुळे प्रत्येक ओळ अर्धी होते: $175, $350, $525 आणि $875. रात्री होणाऱ्या classification run ची वाट पाहावी लागत नाही, त्यामुळे ते टाळण्याचे कारण नाही.
  • सामायिक prefix cache करणे. समजा, 2,000 input tokens पैकी 1,200 tokens प्रत्येक वेळी समान instruction block आहेत. Sonnet 5 च्या प्रारंभिक दरात cache hit साठी त्यांची किंमत $2 / MTok ऐवजी $0.20 / MTok असते. त्यामुळे 120 MTok ची किंमत $240 ऐवजी $24 होते. त्यात $2 दराने 80 MTok fresh input म्हणजे $160 आणि $300 output जोडा. त्यामुळे Sonnet 5 ची किंमत $700 ऐवजी सुमारे $484 होते. Haiku 4.5 वर हीच पद्धत उपयोगी ठरत नाही, कारण 1,200 tokens ही त्याची 4,096-token किमान मर्यादेपेक्षा कमी संख्या आहे.
  • Retries. समजा, 8% emails साठी Haiku चा answer नाकारून ते Opus 4.8 वर पुन्हा चालवता. $350 मध्ये 0.08 x $1,750 = $140 जोडा. त्यामुळे एकूण $490 होते. माझा rejection rate वापरण्याऐवजी स्वतःचा rejection rate मोजा.
  • Tool definitions, जर job मध्ये त्यांचा वापर होत असेल. tool_choice हे auto वर set केल्यास ते निर्माण करणारा system prompt Opus 4.8 वर 290 tokens, Sonnet 5 वर 354 tokens आणि Haiku 4.5 वर 496 tokens असतो. सर्वात स्वस्त model वर fixed overhead सर्वाधिक आहे.

Escalation path असलेल्या Haiku ची किंमत $490 आणि cached Sonnet 5 ची किंमत $484 आहे. दोन्हींची किंमत जवळपास समान आहे आणि त्यांपैकी एक model हे काम एकाच pass मध्ये पूर्ण करतो. प्रश्न केवळ model चा नव्हता.

सत्रादरम्यान model बदलल्याने खर्च वाचतो का?

Sticker prices पाहता वाटते त्यापेक्षा कमी वेळा, कारण बचत प्रति-token मोजली जाते; परंतु जोखीम संपूर्ण cached prefix ची असते.

Cache अमान्य करणाऱ्या गोष्टी Anthropic ने स्पष्ट केल्या आहेत. Prefix तयार होण्याचा क्रम tools, त्यानंतर system आणि मग messages असा असतो. तसेच, "प्रत्येक स्तरातील बदल त्या स्तराला आणि त्यानंतरच्या सर्व स्तरांना अमान्य करतात." दोन request settings देखील त्या यादीत आहेत: "Thinking configuration आणि resolved effort level prompt मध्येच render केले जातात. त्यामुळे यापैकी कोणताही बदल केल्यास नवीन cache prefix सुरू होतो." Effort बाबत documentation मध्ये पुढे असेही म्हटले आहे: "Cache hits वर अवलंबून असलेल्या conversation मध्ये effort बदलण्याऐवजी वेगवेगळ्या workloads मध्ये effort बदलावा."

Model या documentation मधील यादीत नाही. त्यामुळे कोणतेही गृहीतक धरू नका. Switch केल्यानंतरच्या पहिल्या request मधील cache_read_input_tokens वाचा आणि त्यातील आकड्याला उत्तर देऊ द्या. 150,000-token Opus 4.8 prefix साठी cache read ची किंमत सुमारे $0.08 आणि नवीन write ची किंमत सुमारे $0.94 असते. तुम्ही ज्या प्रति-token फरकामागे होतात, त्या फरकाच्या अनेक turns पेक्षा ही किंमत जास्त आहे.

म्हणून या गोष्टी एका task मधून दुसऱ्या task मध्ये बदला; एकाच task मध्ये बदलू नका. Claude Code मध्ये याचा अर्थ cache आधीच discard होत असताना प्रथम /clear, आणि त्यानंतर /model किंवा /effort. हे दोन्ही CLI मध्ये type केले जातात. त्यामुळे Linux वर काम करत असल्यास terminal आवृत्ती install करणे अधिक उपयुक्त ठरते, कारण Linux साठी Anthropic कडून native स्वरूपात उपलब्ध असलेले हे साधन स्थिर CLI ला अजून beta मध्ये असलेल्या desktop app सोबत जोडते. हा बदल bill वर दिसेल की नाही, हे त्या session साठी तुम्ही पैसे कसे देत आहात यावर अवलंबून असते. कारण Claude Code flat monthly plan किंवा प्रति-token API credits यांपैकी कोणत्याही पद्धतीने चालते आणि model बदलाची किंमत dollars मध्ये फक्त दुसरी पद्धत मोजते.

तुमच्या स्वतःच्या workload वर उत्तराची चाचणी कशी घ्यावी

वेगळ्या model मधून घेतलेल्या count च्या आधारे prompt चे आकारमान ठरवू नका. Token-counting endpoint वापरण्यासाठी विनामूल्य आहे आणि तुम्ही ज्या model चे नाव देता त्याच model च्या tokenizer ने count करतो. त्यामुळे ज्या model ला call करायचे आहे त्याचे नाव द्या. हा endpoint platform मधील अशा मोजक्या भागांपैकी एक आहे ज्यासाठी कधीही billing होत नाही. त्यामुळे प्रत्यक्ष credit खर्च करण्यापूर्वी पैसे न देता आणखी काय चालवता येते हे तपासणे उपयुक्त ठरेल. Opus 4.7 आणि त्यानंतरचे versions, Fable 5 आणि Sonnet 5 हे नवीन tokenizer वापरतात. हा tokenizer “त्याच text साठी अंदाजे 30% अधिक tokens तयार करतो”. त्यामुळे जुन्या model वर मोजलेले budget, प्रति-token rate न बदलल्यास, नवीन model साठी कमी पडते.

त्यानंतर परत आलेला output वाचा. input_tokens हा केवळ uncached remainder आहे. त्यामुळे prompt चा खरा आकार त्या field मध्ये, तसेच cache_creation_input_tokens आणि cache_read_input_tokens मध्ये असलेल्या मूल्यांची बेरीज आहे. VPS वर पहिला Claude API app हे मोजमाप चालवण्यासाठी सर्वात लहान पण विश्वासार्ह ठिकाण आहे. तसेच तुमच्या वापरासाठी कोणता Claude plan योग्य आहे हा स्वतंत्र निर्णय आहे: तुम्ही प्रति-token पैसे देणार आहात की नाही. जर प्रश्न subscription घ्यायची की नाही हा नसून कोणती subscription ठेवायची हा असेल, तर ChatGPT च्या किंमतींच्या शेजारी दिलेले Claude चे tiers दुसऱ्या provider च्या seats वर त्याच coding work साठी किती खर्च येतो हे स्पष्ट करते. या मोजमापामुळे तुमचे काम कायमचे API कडे पाठवायचे ठरले, तरी subscription एक tier ने कमी करणे किंवा पूर्णपणे बंद करणे शक्य आहे. तुम्ही आधीच पैसे दिलेला कालावधी कायम राहतो. त्यामुळे numbers मिळाल्यानंतर निर्णय घेतल्याबद्दल कोणताही penalty नाही.

FAQ

कोडिंगसाठी कोणते Claude model सर्वोत्तम आहे?

जटिल agentic coding साठी Claude Opus 4.8 हा दस्तऐवजीकरणानुसार प्रारंभ करण्यासाठी योग्य पर्याय आहे. July 2026 पर्यंत त्याची किंमत प्रति million input tokens $5 आणि प्रति million output tokens $25 आहे. Claude Sonnet 5 हे वेग आणि बुद्धिमत्तेचे सर्वोत्तम संयोजन म्हणून मांडले आहे. 31 August 2026 पर्यंत त्याची किंमत $2 / $10 आहे, त्यामुळे तो निम्म्यापेक्षाही कमी खर्चिक आहे. दोन्ही models वर समान task चालवा. thinking configuration समान ठेवा. त्यानंतर response.usage मधील एकूण token खर्चाची तुलना करा.

Claude Haiku 4.5 हे Sonnet 5 ची जागा घेण्यासाठी पुरेसे स्वस्त आहे का?

प्रति token विचार करता, नक्कीच. introductory pricing मध्ये Sonnet 5 साठी $2 / $10 च्या तुलनेत Haiku 4.5 ची किंमत $1 / $5 आहे. 1 September 2026 पासून Sonnet 5 ची किंमत $3 / $15 असेल. मात्र मर्यादा निर्णायक ठरतात. Haiku 4.5 मध्ये 1M ऐवजी 200K token context window आहे. synchronous Messages API वर maximum output 64K tokens आहे. त्याचा विश्वासार्ह knowledge cutoff February 2025 आहे. त्याला output_config.effort support नाही. तसेच cache करता येणाऱ्या prompt साठी किमान 4,096 tokens आवश्यक आहेत. त्यामुळे लहान system prompts साठी caching नकळत बंद होते.

session च्या मध्यावर स्वस्त Claude model वापरल्यास खर्च कमी होतो का?

दिसते त्यापेक्षा कमी वेळा. Anthropic नुसार cache invalidators मध्ये tools, system किंवा messages prefix मधील बदल, thinking configuration मधील बदल आणि output_config.effort मधील बदल यांचा समावेश होतो. model बदलल्यावर विद्यमान cache वर काय परिणाम होतो, हे दस्तऐवजीकरणात स्पष्ट केलेले नाही. त्यामुळे ते अज्ञात समजा आणि त्यानंतरच्या पहिल्या request मध्ये cache_read_input_tokens वाचा. हे जाणून घेणे महत्त्वाचे आहे. 150,000-token Opus 4.8 prefix साठी cache read ची किंमत सुमारे $0.08 आणि नव्याने write करण्याची किंमत सुमारे $0.94 असते. हा खर्च प्रति-token बचतीच्या अनेक turns पेक्षा जास्त असू शकतो. tasks यांच्यामध्ये model बदला. Claude Code मध्ये /clear नंतर model बदला, कारण त्या वेळी cache कोणत्याही परिस्थितीत टाकून दिला जातो.

output_config.effort मुळे माझ्या bill वर काय परिणाम होतो?

यामुळे model text, tool calls आणि thinking यांवर खर्च करणाऱ्या tokens ची संख्या बदलते. कमी effort मुळे tool calls कमी होतात. agentic loops मध्ये याचा एकत्रित परिणाम होतो, कारण प्रत्येक tool result पुढील turns मध्ये पुन्हा पाठवला जातो. levels low, medium, high, xhigh आणि max आहेत. high हे default आहे. Anthropic प्रत्येक level साठी cost multiplier प्रकाशित करत नाही. त्यांच्या मते effort हा token budget नसून behavioural signal आहे. त्यामुळे तो तुमच्या स्वतःच्या task वर मोजा.

Claude Batches API मुळे किती बचत होते?

input आणि output tokens दोन्हींवर 50% बचत होते. त्यासाठी asynchronous delivery स्वीकारावी लागते. July 2026 पर्यंत Opus 4.8 ची किंमत $2.50 in / $12.50 out, Sonnet 5 ची introductory pricing अंतर्गत $1 / $5 आणि Haiku 4.5 ची $0.50 / $2.50 इतकी होते. tiers मधील तुलना अधिक महत्त्वाची आहे. 1 September 2026 पासून standard rate वर synchronous Sonnet 5 job पेक्षा batched Opus 4.8 job कमी खर्चिक असेल. त्यामुळे त्याच खर्चात अधिक सक्षम model वापरता येतो.