Claude Platform के साथ लागत कम करना और प्रदर्शन में सुधार करना

प्रॉम्प्ट कैशिंग, निर्देशों और प्रयास को ट्यून करने से एप्लिकेशन के प्रदर्शन से समझौता किए बिना Claude की लागत कम हो सकती है।

प्रदर्शन और लागत को अक्सर एक व्यापार-बंद के रूप में देखा जाता है: कम खर्च करने के लिए, आप बदतर परिणाम स्वीकार करते हैं। व्यवहार में, हमने पाया है कि Claude Platform का उपयोग करने वाले कई एप्लिकेशन तीन सुधारों के साथ प्रदर्शन छोड़े बिना लागत कम कर सकते हैं: प्रॉम्प्ट कैश हिट दर को अधिकतम करें, फ्रंटियर Claude मॉडल में अपग्रेड करते समय अपने प्रॉम्प्ट से एंटी-पैटर्न हटाएं, और कार्य के अनुसार प्रयास को कैलिब्रेट करें। हमने इस मार्गदर्शन को claude-api स्किल में डाल दिया है। इस लेख में, हम दिखाते हैं कि कैसे Claude Code, claude-api स्किल के साथ, अक्सर प्रदर्शन को बनाए रखते हुए या सुधारते हुए लागत कम करने के तरीके खोज सकता है।

प्रॉम्प्ट कैश

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

प्रॉम्प्ट कैश के प्रभावी उपयोग को सुनिश्चित करने के लिए कुछ व्यावहारिक विचार हैं। पहला, प्रॉम्प्ट कैश एक विशिष्ट मॉडल से जुड़ा होता है। दूसरा, प्रॉम्प्ट कैश रीड को उपसर्ग में बाइट-एक्सैक्ट होना चाहिए। अंत में, प्रॉम्प्ट कैश की एक सीमित टाइम-टू-लिव (TTL) होती है।

इन बिंदुओं को ध्यान में रखते हुए, कुछ व्यावहारिक सुझाव हैं:

• बातचीत के बीच में प्रयास सेटिंग बदलने से सावधान रहें। ये सेटिंग्स आपकी सामग्री से पहले प्रॉम्प्ट में प्रस्तुत होती हैं, इसलिए वे कैश किए गए उपसर्ग का हिस्सा हैं। केवल चुनिंदा Claude मॉडल, जिनमें Opus 5 और Fable 5.1 शामिल हैं, के साथ आप कैश को तोड़े बिना बातचीत के बीच में प्रयास अपडेट कर सकते हैं।
• अस्थिर मानों को उपसर्ग से बाहर रखें। सिस्टम प्रॉम्प्ट में एक गतिशील टाइमस्टैम्प या ID मॉडल कॉल में बदल सकता है, और कैश को तोड़ सकता है।
• टूल परिभाषाओं से बचें जो स्वयं को पुनर्व्यवस्थित करती हैं। Claude messages API का उपयोग करते समय, प्रॉम्प्ट एक निश्चित क्रम में इकट्ठा किया जाता है जिसमें टूल परिभाषाएँ शीर्ष पर प्रस्तुत की जाती हैं। टूल परिभाषा में कोई भी बदलाव कैश को तोड़ देगा।
• बातचीत को फोर्क करते समय सावधान रहें। सबएजेंट और शाखाएं केवल मूल के कैश को साझा करती हैं जब फोर्क का उपसर्ग बाइट-समान हो, उसी मॉडल पर हो, और उसी प्रयास का उपयोग कर रहा हो।

इसे कैसे ठीक करें

हमने प्रॉम्प्ट कैश प्रबंधन के लिए कुछ सबक जमा किए हैं:

• अपनी प्रॉम्प्ट कैश हिट दर की सावधानीपूर्वक निगरानी करें। Claude Console और कैश डायग्नोस्टिक्स API प्रॉम्प्ट कैश डायग्नोस्टिक्स प्रदान करते हैं, जिसमें प्रॉम्प्ट कैश मिस के कारण (चित्र 1) और वास्तव में दो अनुरोध कहाँ भिन्न हुए, शामिल हैं।

• शायद ही कभी उपयोग किए जाने वाले टूल को स्थगित करें। अपने सभी टूल को शुरू में घोषित करें लेकिन शायद ही कभी उपयोग किए जाने वाले टूल को defer_loading के रूप में चिह्नित करें: वे कैश किए गए उपसर्ग से बाहर रहते हैं और केवल तभी बातचीत में जोड़े जाते हैं जब Claude टूल खोज के साथ उन्हें देखता है, इसलिए कैश संरक्षित रहता है।
• सिस्टम प्रॉम्प्ट अपडेट को संदेशों के रूप में लागू करें। कुछ Claude मॉडल आपको सिस्टम प्रॉम्प्ट को संपादित करने के बजाय बातचीत के बीच में एक संदेश के रूप में एक सिस्टम निर्देश जोड़ने देते हैं, जो कैश को संरक्षित करता है।
• अनुरोध को इस तरह व्यवस्थित करें कि स्थिर भाग स्थिर रहे। पहले स्थिर संदर्भ (टूल परिभाषाएँ और सिस्टम प्रॉम्प्ट) जोड़ें और उनके पीछे बढ़ती बातचीत जोड़ें (चित्र 2)।

• मॉडल या प्रयास में परिवर्तन तब करें जब प्रॉम्प्ट कैश पहले से ही टूट जाएगा। कुछ ऑपरेशन, जैसे कॉम्पैक्शन, पहले से ही कैश (बातचीत) के अधिकांश भाग को फिर से लिखते हैं। यह मॉडल या प्रयास को स्विच करने का एक अच्छा समय है, क्योंकि आप वैसे भी मिस के लिए भुगतान कर रहे हैं।
• जैसे-जैसे बातचीत बढ़ती है, कैश ब्रेकपॉइंट को स्थानांतरित करें। Claude Platform के साथ, आप अंतिम कैश करने योग्य ब्लॉक पर कैश ब्रेकपॉइंट लागू करने के लिए ऑटोमैटिक कैशिंग सेट कर सकते हैं।
• कैश को प्री-वार्म करें। विलंबता कम करने के लिए, max_tokens: 0 और एक स्पष्ट कैश ब्रेकपॉइंट के साथ एक अनुरोध भेजें, अपने वास्तविक ट्रैफ़िक के समान प्रयास सेटिंग का उपयोग करें। यह कुछ भी उत्पन्न किए बिना प्रॉम्प्ट को संसाधित करता है और इसे कैश में लिखता है। यदि आप इसे सत्र की शुरुआत में चलाते हैं (उदाहरण के लिए, जब कोई उपयोगकर्ता टाइप कर रहा है), तो पहला वास्तविक अनुरोध एक गर्म कैश से टकराता है।
• प्रॉम्प्ट कैश TTL से अधिक न हों। 5 मिनट का कैश TTL अनुरोध की शुरुआत से गिना जाता है। यदि कोई एजेंट टूल कॉल या सबएजेंट अनुरोधों पर ब्लॉक करता है जो 5 मिनट से अधिक समय तक चलते हैं, तो परिणाम वापस आने से पहले मूल का कैश समाप्त हो जाता है। ऐसे मामलों में, उपसर्ग पर 1 घंटे का TTL सेट करने पर विचार करें।

निर्देश

प्रॉम्प्ट में ऐसे निर्देश जमा हो सकते हैं जो मॉडल की कमजोरियों को ठीक करते हैं। ये निर्देश नवीनतम Claude मॉडल की क्षमताओं के सापेक्ष बहाव कर सकते हैं। यहाँ सामान्य प्रॉम्प्टिंग "एंटी-पैटर्न" दिए गए हैं जो फ्रंटियर Claude मॉडल को बाधित करते हैं और अनजाने में लागत बढ़ा सकते हैं:

• सत्यापन अनुष्ठान। "अपने काम की दोबारा जाँच करें" या "उत्तर देने से पहले दो बार सत्यापित करें" जैसे निर्देशों को अक्सर फ्रंटियर मॉडल द्वारा शाब्दिक रूप से लिया जाता है और टोकन बर्बाद कर सकते हैं।
• पूर्णता और जोर बढ़ाने वाले। "अधिकतम पूर्णता से काम करें," "महत्वपूर्ण: आपको हमेशा…" फ्रंटियर मॉडल के साथ काम करते समय वाचालता और अतिरिक्त टूल कॉल का कारण बन सकता है।
• अनिवार्य प्रक्रियाएं और स्क्रैचपैड स्कैफोल्ड। निश्चित-चरण प्रक्रियाएं (जैसे, "स्क्रैचपैड में चरण दर चरण सोचें") या तर्क टेम्पलेट ऐसे अनुष्ठान हैं जिनकी फ्रंटियर मॉडल को आवश्यकता नहीं है। यह स्कैफोल्डिंग देशी तर्क के ऊपर स्टैक हो सकती है और अनावश्यक टोकन का उपयोग कर सकती है।
• पुराने उदाहरण। पुराने मॉडल की विफलता मोड के अनुरूप कुछ-शॉट उदाहरण एक फ्रंटियर मॉडल को उन अनुरोधों पर लंबी तर्क श्रृंखलाओं की नकल करना सिखा सकते हैं जिन्हें उनकी आवश्यकता नहीं है।
• विरोधाभासी नियम। फ्रंटियर मॉडल निर्देशों का पालन करने में बेहतर होते हैं। विरोधाभासी निर्देश ("हमेशा नीति के भीतर रिफंड करें" बनाम "एस्केलेशन के बिना कभी रिफंड जारी न करें") का फ्रंटियर मॉडल द्वारा अधिक शाब्दिक रूप से पालन किया जा सकता है, जिसके परिणामस्वरूप प्रदर्शन खराब हो सकता है।
• पुराना कॉन्फ़िगरेशन। पुरानी Claude पीढ़ी के लिए लिखी गई सेटिंग्स (जैसे, मैनुअल थिंकिंग बजट) को नए मॉडलों के साथ Claude Platform द्वारा अस्वीकार किया जा सकता है।

इसे कैसे ठीक करें

हमने claude-api स्किल को एक नए कमांड के साथ अपडेट किया है जो इन एंटी-पैटर्न पर नज़र रखता है। Claude Code में, अपने प्रॉम्प्ट, स्किल या टूल विवरण के विरुद्ध /claude-api prompt-audit चलाएं। ऑडिट आपकी कार्यशील निर्देशिका में किसी भी चीज़ को कवर करता है, जिसमें एप्लिकेशन कोड शामिल है जो Claude API और Claude Code के अपने कॉन्फ़िगरेशन (जैसे, CLAUDE.md या स्किल) को कॉल करता है।

उदाहरण के लिए, हमने एक ग्राहक सहायता बेंचमार्क पर Opus 4.8 से Opus 5 में मॉडल माइग्रेशन का परीक्षण किया। हमने एक साफ प्रॉम्प्ट से शुरुआत की और एक बार में एक एंटी-पैटर्न लगाया (एक सेवानिवृत्त थिंकिंग सेटिंग, विरोधाभासी रिफंड नियमों की एक जोड़ी, एक मैनुअल स्क्रैचपैड, "दो बार सत्यापित करें", "अधिकतम पूर्णता से काम करें", और एक अनिवार्य छह-चरणीय प्रक्रिया), जिससे छह विरासत प्रॉम्प्ट तैयार हुए।

हमने प्रत्येक को Opus 4.8 पर, केवल मॉडल ID बदलने के साथ Opus 5 पर, और प्रति प्रॉम्प्ट एक बार /claude-api prompt-audit चलाने के बाद Opus 5 पर चलाया (चित्र 3 छह का औसत दिखाता है)।

Opus 5 के साथ, सत्यापन अनुष्ठान ("दो बार सत्यापित करें") प्रत्येक रिफंड पर ऑर्डर लुकअप को डुप्लिकेट करके अनावश्यक टोकन का उपयोग करते हैं। जोर बढ़ाने वाले ("अधिकतम पूर्णता से काम करें") दर्जनों अनावश्यक नॉलेज-बेस खोज बन गए।

/claude-api prompt-audit चलाने से एंटी-पैटर्न हटा दिए गए, जिससे लागत में औसतन 14.6% की कमी आई और सटीकता में 5.3% की वृद्धि हुई। लागत में गिरावट आई क्योंकि अतिरिक्त टूल कॉल और डुप्लिकेट तर्क समाप्त हो गए। सटीकता तीन कारणों से बढ़ी। सेवानिवृत्त थिंकिंग सेटिंग ने API को हर रूटिंग अनुरोध को सीधे अस्वीकार कर दिया। विरोधाभासी रिफंड नियमों ने Opus 5 को चार रिफंड रोकने के लिए प्रेरित किया जबकि उसने ग्राहक से पुष्टि करने के लिए कहा। और मैनुअल स्क्रैचपैड Opus 5 की अंतर्निहित सोच से टकरा गया: तीन टिकटों पर इसने अपने तर्क के अंदर टूल कॉल लिखा और उसे कभी निष्पादित नहीं किया।

प्रयास

प्रयास Claude को बताता है कि "कितनी मेहनत करनी है।" कम प्रयास पर Claude आम तौर पर तेजी से निष्कर्ष पर पहुँचता है। उच्च प्रयास पर, Claude उत्तर देने से पहले विचार-विमर्श करता है, सत्यापित करता है और विकल्पों का पता लगाता है।

एकल मॉडल पर प्रयास स्तरों पर लागत-बनाम-प्रदर्शन भिन्न हो सकता है। उदाहरण के लिए, Claude Fable 5 FrontierCode Diamond (सबसे कठिन 50 कार्य) पर कम प्रयास पर $5.35 प्रति कार्य के लिए 11.5% स्कोर करता है। अधिकतम प्रयास पर, Fable 5 $19.00 प्रति कार्य के लिए 30.9% प्राप्त करता है; प्रयास बदलने से स्कोर लगभग 2.7x (+19 अंक) बढ़ जाता है, लागत लगभग 3.5x (चित्र 4) होती है।

Claude Fable 5.1 पर, Humanity's Last Exam (बिना टूल के) एक कम होते अंतिम चरण के साथ एक तीव्र वक्र दिखाता है। यह कम प्रयास पर लगभग $0.30 प्रति प्रश्न के लिए लगभग 53% और अधिकतम प्रयास पर लगभग $2.23 के लिए लगभग 61% स्कोर करता है; अधिकतम तक का अंतिम चरण 46% अधिक लागत के लिए लगभग आधा अंक जोड़ता है। लाभ बेंचमार्क के रन-टू-रन शोर के अंतर्गत आता है, इसलिए आप बिना किसी मापने योग्य लाभ के अधिक भुगतान करते हैं।

प्रयास को किसी भी दिशा में गलत तरीके से कैलिब्रेट किया जा सकता है:

• यह मान लेना कि उच्च हमेशा बेहतर होता है। उच्च प्रयास अत्यधिक सोच का कारण बन सकता है। Claude कार्य के लिए आवश्यकता से अधिक समय विचार-विमर्श में बिताता है, जो लागत और विलंबता जोड़ता है, और उत्तर की गुणवत्ता को खराब कर सकता है। विचार-विमर्श तभी मदद करता है जब खोजने के लिए अभी भी सबूत हों।
• कम प्रयास की ओर झुकाव। बहुत कम सेट करने पर, Claude के पास पर्याप्त सबूत होने से पहले ही रुक जाता है। यह कम टूल कॉल करता है, इसलिए यह तीसरे के बजाय पहले खोज परिणाम से उत्तर दे सकता है। यह कठिन चरणों पर कम सोचता है और उस जाँच को छोड़ देता है जो वह सामान्य रूप से अपने आप चलाएगा। उत्तर तैयार दिखता है, लेकिन यह आंशिक जानकारी पर बनाया गया है।

इसे कैसे ठीक करें

प्रयास को कैलिब्रेट करने के कुछ उपयोगी तरीके हैं:

• कम प्रयास पर मजबूत मॉडल का परीक्षण करें। कम प्रयास पर एक मजबूत मॉडल कड़ी मेहनत (उच्च प्रयास) करने वाले कमजोर मॉडल की तुलना में सस्ता हो सकता है। उदाहरण के लिए, CursorBench 3.2 पर, कम प्रयास पर Claude Fable 5.1 एक तिहाई लागत पर उच्च प्रयास पर Fable 5 के प्रदर्शन से मेल खाता है (चित्र 5)। दो चीजें नए मॉडल को सस्ता बनाती हैं: कम प्रयास पर यह प्रति कार्य कम काम करता है, और Fable 5.1 के प्रॉम्प्ट-कैश रीड की कीमत $0.25 प्रति मिलियन टोकन बनाम Fable 5 के लिए $1.00 है। Fable 5 की कीमतों पर भी, कम प्रयास पर Fable 5.1 की लागत लगभग 40% कम होगी।

• अपने कार्य के आकार को समझें। प्रयास स्तरों की एक श्रृंखला में एप्लिकेशन प्रदर्शन को मापना आपके विशेष कार्य के लिए लागत-प्रदर्शन व्यापार-बंद को समझने का एक उपयोगी तरीका है। एक गैर-संतृप्त मूल्यांकन पर, प्रयास स्तरों पर एक सपाट लागत-प्रदर्शन वक्र बताता है कि कार्य सोच कंप्यूट से बंधा नहीं है; प्रयास बढ़ाना लाभदायक नहीं है।

इस अंशांकन में अक्सर मॉडल और प्रयास स्तरों पर एक मूल्यांकन चलाना शामिल होता है। Claude Code में, /claude-api hillclimb आपके लिए यह खोज करता है: यह आपके मूल्यांकन को प्रशिक्षण और परीक्षण सेट में विभाजित करता है, कॉन्फ़िगरेशन परिवर्तन प्रस्तावित करता है, और जो पाता है उसे ठीक करने के लिए असफल प्रशिक्षण उदाहरणों को पढ़ता है।

हमने इसे एक ग्राहक सहायता बेंचमार्क पर चलाया, जो Opus 4.8 से उसके डिफ़ॉल्ट (उच्च) प्रयास पर शुरू हुआ। हिलक्लिम्बर ने पहले कम प्रयास पर Opus 5 की कोशिश की, अनिवार्य टूल-कॉल अनुष्ठानों, स्क्रैचपैड चरणों और विरोधाभासी नियमों को हटाने के लिए prompt-audit लागू किया। इसने 98.9% प्रशिक्षण सटीकता पर Opus 4.8 बेसलाइन को साफ कर दिया और लागत को 2.6 सेंट प्रति टिकट (चित्र 6) तक कम कर दिया।

इसके बाद यह कम प्रयास पर Sonnet 5 पर आ गया, जो 1 सेंट प्रति टिकट पर और भी सस्ता था, लेकिन सटीकता 88.9% तक गिर गई। असफल प्रशिक्षण टिकटों को पढ़कर, Claude ने प्रॉम्प्ट में रूटिंग नियम और एक रिफंड-कैप क्रॉस-रेफरेंस जोड़ा, जिससे Sonnet 5 उसी लागत पर 98.9% पर वापस आ गया।

उन 14 होल्ड-आउट टिकटों पर जिन्हें खोज ने कभी नहीं देखा, अंतिम कॉन्फ़िगरेशन ने मूल सेटअप के 78.6% के मुकाबले 90.5% स्कोर किया, लगभग पांचवें हिस्से की लागत पर।

लागत में कमी को स्वचालित करना

प्रॉम्प्ट कैशिंग, निर्देश और प्रयास लागत कम करने के लिए सामान्य लीवर हैं। हमारा दस्तावेज़ीकरण और भी अधिक कवर करता है। Claude API का उपयोग करने वाले एप्लिकेशन कोड का समग्र लागत ऑडिट चलाने के लिए, हमने /claude-api cost-optimize जोड़ा है: यह प्रोफाइल करता है कि आपका खर्च कहाँ जाता है, लागत में कमी लागू करता है, और यदि आप एक मूल्यांकन प्रदान करते हैं, तो दिखाता है कि बचत प्रदर्शन के साथ कैसे व्यापार करती है।

cost-optimize यह पता लगाकर शुरू होता है कि आपके टोकन कहाँ जाते हैं: आपके संगठन के उपयोग और लागत रिपोर्ट से यदि आपके पास Claude Admin API कुंजी है, प्रत्येक API प्रतिक्रिया पर उपयोग ऑब्जेक्ट से यदि आपका एप्लिकेशन इसे लॉग करता है, या, दोनों विफल होने पर, आपके अनुरोध-निर्माण कोड को पढ़कर और अनुमान लगाकर।

यह तब उपलब्ध बचत को रैंक करता है, प्रॉम्प्ट कैशिंग से शुरू करके, प्रत्येक अनुरोध द्वारा ले जाने वाली चीज़ों को ट्रिम करना (एक prompt-audit सहित), आउटपुट को बाउंड करना, और अप्राप्त कार्य को बैचिंग करना। यदि आप एक मूल्यांकन प्रदान करते हैं, तो यह आगे बढ़ता है और प्रयास स्तरों और मॉडल विकल्पों में लागत और प्रदर्शन की गणना करता है। हमने इसे Sonnet 5 को बेसलाइन के रूप में चार सार्वजनिक बेंचमार्क पर चलाया (चित्र 7):

• LegalBench (~58% कम लागत): cost-optimize ने कार्यों में एक साझा उपसर्ग को कैश करने, कम प्रयास सेट करने और बैच API के माध्यम से कार्यों को संसाधित करने का प्रस्ताव दिया। थिंकिंग टोकन 102,779 से घटकर 8,284 हो गए और पास दर शोर के भीतर रही और लागत में ~58% की गिरावट आई।
• tau2-bench retail (~73% कम लागत): स्पष्ट ब्रेकपॉइंट प्लेसमेंट के साथ प्रॉम्प्ट कैशिंग लागू करके, cost-optimize ने पास दर को सपाट रखते हुए खर्च में 72% की कमी की।
• OfficeQA Pro (~52% कम लागत): cost-optimize ने बैच प्रोसेसिंग और दस्तावेज़ कैशिंग जोड़ा, जिससे लागत $136.20 से घटकर $64.87 हो गई।
• SWE-bench Verified (~55% कम लागत): cost-optimize ने पाया कि डिफ़ॉल्ट कॉन्फ़िगरेशन पहले से ही सही ढंग से कैश करता है। बचत प्रयास को मध्यम पर सेट करने और एजेंट के आउटपुट को केवल कुछ संक्षिप्त वाक्यों तक सीमित करने से आई। प्रति कार्य माध्य चरण 29 से घटकर 17 हो गए और प्रॉम्प्ट टोकन 75.2M से घटकर 33.7M हो गए।

आरंभ करना

/claude-api prompt-audit से शुरू करें जब आप एक फ्रंटियर Claude मॉडल में माइग्रेट कर चुके हों और अपने मौजूदा प्रॉम्प्ट की जाँच करना चाहते हों। यह आपकी कार्यशील निर्देशिका में प्रॉम्प्ट, स्किल और टूल विवरण को स्कैन करता है। यह एप्लिकेशन कोड हो सकता है जो Claude API या Claude Code के कॉन्फ़िगरेशन (CLAUDE.md, स्किल) को कॉल करता है। यह सामान्य एंटी-पैटर्न को हटाता है जो फ्रंटियर मॉडल को बाधित करते हैं।

/claude-api cost-optimize का उपयोग करें जब आपका एप्लिकेशन Claude API का उपयोग करता है और आप एक लागत ऑडिट चाहते हैं। यह टोकन खर्च को प्रोफाइल करता है और फिर विभिन्न लीवरों का परीक्षण करता है: यह prompt-audit लागू करता है, लेकिन प्रॉम्प्ट कैशिंग, अप्राप्त कार्य को बैचिंग, या आउटपुट को बाउंड करके लागत कम करने के तरीकों की भी जाँच करता है। यदि आप एक मूल्यांकन प्रदान करते हैं, तो यह प्रयास और मॉडल चयन व्यापार-बंद को मापता है।

अंत में, लागत और प्रदर्शन पर खोज के लिए /claude-api hillclimb का उपयोग करें। एक मूल्यांकन दिए जाने पर, Claude इसे प्रशिक्षण और परीक्षण सेट में विभाजित करता है, फिर आपके एप्लिकेशन में अपडेट प्रस्तावित करता है जिसका उद्देश्य बेसलाइन प्रदर्शन को बनाए रखते हुए लागत को कम करना है। Claude खोज का मार्गदर्शन करने के लिए असफल प्रशिक्षण मामलों को पढ़ता है, और अंतिम कॉन्फ़िगरेशन को होल्ड-आउट परीक्षण सेट पर स्कोर किया जाता है।

अधिक जानने के लिए:

• हमारा दस्तावेज़ीकरण यहाँ देखें
• हमारी लागत कम करने वाली कुकबुक यहाँ देखें
• claude-api स्किल यहाँ देखें; स्किल Claude Code में भी बनाया गया है
• Claude ब्लॉग पर यह लेख यहाँ देखें

Lance Martin (@RLanceMartin), Brad Abrams (@brada), Isabella He (@IsabellaKHe), और Ben Lehrburger (@benlehrburger) द्वारा लिखित।