लेखक: Matt Connor 2026-10-13

VPS पर AI agent की लागत को कैसे नियंत्रित करें

Q: max_tokens और task budget में क्या अंतर है?

max_tokens को लागू किया जाता है और यह model को दिखाई नहीं देता है। यह एक request के output को, जिसमें thinking भी शामिल है, सीमित करता है और इसे पार करने पर stop_reason: "max_tokens" प्राप्त होता है। Task budget इसके विपरीत है: model को यह संख्या बताई जाती है और वह agentic loop को इसके अनुसार नियंत्रित करता है, लेकिन "Task budgets एक soft hint हैं, न कि hard cap" और लागू की गई सीमा अभी भी max_tokens ही रहती है।

Always-on AI agent के खर्च को नियंत्रित करने के लिए hard caps, prompt caching और batching का उपयोग करें। API usage logs के जरिए प्रति loop होने वाले खर्च को ट्रैक करना सीखें।

Always-on AI agent के बिल को नियंत्रित कैसे रखें

VPS (virtual private server) पर AI agent की लागत को नियंत्रित करने का अर्थ है agent शुरू करने से पहले ही सीमाएं तय करना, क्योंकि इसके चलते समय कोई भी मीटर की निगरानी नहीं कर रहा होता है। प्रत्येक response को max_tokens के साथ सीमित करें, अपने कोड में loop iterations को बांधें, prompt के उस हिस्से को cache करें जो कभी नहीं बदलता है, और यह देखने के लिए कि कौन सा job खर्च बढ़ा रहा है, प्रत्येक response के usage numbers को log करें। सर्वर का किराया एक निश्चित मासिक मूल्य है। Model API का शुल्क प्रति token के आधार पर लिया जाता है, और एक unattended loop चुपचाप tokens खर्च करने में बहुत सक्षम होती है।

यह मानकर चला गया है कि एक agent पहले से मौजूद है और आपके स्वामित्व वाले बॉक्स से Messages API को कॉल करता है। VPS पर Claude के साथ AI agent बनाना में इसकी कार्यप्रणाली को विस्तार से समझाया गया है।

अनअटेंडेड एजेंट की लागत का स्वरूप अलग क्यों होता है

इंटरैक्टिव सत्र में एक इंसान मौजूद होता है। जब मॉडल गलत दिशा में जाता है या 40,000 लाइन का लॉग पढ़ता है, तो उसे देखने वाला व्यक्ति उसे रोक देता है। अनअटेंडेड एजेंट में ऐसा कोई ब्रेक नहीं होता: यह लूप खत्म होने तक चलता है, फिर एक टाइमर इसे दोबारा शुरू कर देता है।

आवृत्ति (frequency) वह गुणक है जिसे लोग अक्सर नजरअंदाज कर देते हैं। पांच मिनट के शेड्यूल पर चलने वाला जॉब दिन में 288 बार और महीने में लगभग 8,640 बार चलता है। एक बार चलने की जो भी लागत है, उसे ही आपको गुणा करना होता है। कई "always-on" एजेंटों को हर समय चालू रहने की आवश्यकता नहीं होती। उन्हें केवल कुछ मिनटों के भीतर जवाब देने की आवश्यकता होती है, जो कि एक शेड्यूल ही है।

एक एजेंट उन चीजों के लिए भी भुगतान करता है जो चैट विंडो में नहीं होतीं।

टूल डेफिनिशन हर रिक्वेस्ट के साथ जाते हैं। टूल-यूज़ सिस्टम प्रॉम्प्ट की लागत Claude Opus 4.8 पर tool_choice of auto या none के साथ 290 टोकन है, और any या tool के साथ 410 टोकन है। bash टूल इसमें 325 टोकन और जोड़ देता है। हर MCP server जिसे आप जोड़ते हैं वह अपने स्कीमा को उस भार में शामिल कर देता है, जहाँ MCP का अर्थ मॉडल कॉन्टेक्स्ट प्रोटोकॉल है।
टूल के परिणाम इनपुट टोकन होते हैं। एक कमांड जो 8,000 लाइन प्रिंट करती है, वह अगली रिक्वेस्ट में और उस टर्न की उसके बाद की हर रिक्वेस्ट में 8,000 लाइन डाल देती है।
फेच किए गए पेज इनपुट टोकन होते हैं। औसतन 10 kB का वेब पेज लगभग 2,500 टोकन का होता है और 500 kB की रिसर्च PDF लगभग 125,000 टोकन की। max_content_tokens केवल टेक्स्ट वाले कंटेंट को छोटा (truncate) करता है, क्योंकि यह "टेक्स्ट कंटेंट पर लागू होता है, न कि PDF जैसे बाइनरी कंटेंट पर"। PDF को max_uses और allowed_domains के साथ सीमित करें।
वेब सर्च की कीमत प्रति सर्च तय होती है, जो $10 प्रति 1,000 सर्च है, चाहे कितने भी परिणाम वापस आएं। जो सर्च एरर देती है, उसका बिल नहीं बनता।

इनमें से कोई भी चीज एक बार में महंगी नहीं होती। लेकिन 8,640 बार चलने पर यह सब महंगा हो जाता है।

Hard ceilings और soft ceilings अलग-अलग समस्याओं का समाधान करते हैं

max_tokens को लागू किया जाता है। यह एक request के कुल output, thinking और response text पर एक hard cap है। Claude इसके आगे कभी generate नहीं करता है, और model इस संख्या को देख नहीं सकता है। इस तक पहुँचने पर stop_reason: "max_tokens" मिलता है और उत्तर अधूरा (truncated) रह जाता है। Agents के लिए ध्यान देने वाली बात: tool-use loop में हर request का अपना max_tokens होता है, इसलिए यह केवल एक response को सीमित करता है, पूरे कार्य को नहीं। 4,000 tokens पर दस tool calls का मतलब है कि उस turn के लिए 40,000-token की सीमा है।

Task budget एक सलाह है। task_budget, output_config के भीतर रहता है और model को बताता है कि पूरे agentic loop के लिए उसके पास कितने tokens हैं, जिसमें thinking, tool calls, tool results और output शामिल हैं।

resp = client.beta.messages.create(
    model="claude-opus-4-8",
    max_tokens=4096,
    betas=["task-budgets-2026-03-13"],
    output_config={"task_budget": {"type": "tokens", "total": 64000}},
    messages=messages,
)

"Task budgets एक soft hint हैं, hard cap नहीं।" Claude किसी action के बीच में इसे पार कर सकता है, और output पर लागू सीमा अभी भी max_tokens ही रहती है। "Countdown केवल model को दिखाई देता है", और responses में शेष budget का कोई field नहीं होता है। स्वीकार किया जाने वाला न्यूनतम task_budget.total 20,000 tokens है, और इससे कम होने पर 400 error मिलता है। काम के लिए बहुत छोटा budget होने पर model मना करने जैसा व्यवहार करता है, इसलिए model कार्य के दायरे को छोटा कर देता है या जल्दी रुक जाता है।

एक विवरण पैसे बचाने के बजाय खर्च बढ़ाता है। यदि आपका client हर follow-up request पर task_budget.remaining को घटाता है, तो बदला हुआ मान उस cached prefix को अमान्य कर देता है जिसमें वह शामिल है। इसे पहली request पर केवल एक बार set करें।

Task budgets Claude Fable 5.1, Claude Fable 5, Claude Opus 5.5, Claude Opus 5, Claude Opus 4.8, Claude Opus 4.7, Claude Sonnet 5.5 और Claude Haiku 5.5 पर beta में हैं। Claude Sonnet 5 और Claude Haiku 4.5 को Not supported के रूप में सूचीबद्ध किया गया है, और task budgets Claude Code पर लागू नहीं होते हैं, इसलिए tmux में detached Claude Code session session hygiene पर निर्भर करता है।

तीसरी सीमा Claude Console में होती है: agent को अपना workspace दें, फिर उस पर मासिक खर्च की सीमा (monthly spend limit) और प्रति-मिनट rate limits set करें। "आप Default Workspace पर सीमाएं set नहीं कर सकते", और "Organization-wide सीमाएं हमेशा लागू होती हैं, भले ही workspace की सीमाएं कुल मिलाकर उससे अधिक क्यों न हों।" Spend notifications जोड़ें ताकि cap तक पहुँचने से पहले ही threshold आपको alert कर दे।

प्रति-जॉब मॉडल चयन, और वास्तव में क्या प्रयास बदलता है

मॉडल का चयन प्रति-जॉब निर्णय है। अक्टूबर 2026 तक, प्रति दस लाख टोकन के लिए, इनपुट और फिर आउटपुट दरें इस प्रकार हैं: Claude Fable 5.1 और Fable 5 के लिए $10 और $50, Claude Opus 5.5 के लिए $4 और $20, Claude Opus 5, Opus 4.8 और Opus 4.7 के लिए $5 और $25, Claude Sonnet 5.5 और Sonnet 5 के लिए $2 और $10, Claude Haiku 5.5 के लिए 100,000 टोकन तक के प्रॉम्प्ट के लिए $0.10 और $0.50 (उससे अधिक के लिए $0.50 और $2.50, जिसमें कैश किए गए टोकन शामिल हैं), और Claude Haiku 4.5 के लिए $1 और $5। Anthropic ने पहले Sonnet 5 को उस कीमत पर शुरुआती दर के रूप में बेचा, फिर इसे मानक कीमत बना दिया और $3 और $15 की नियोजित वृद्धि को रद्द कर दिया। जो चरण केवल लॉग लाइनों को वर्गीकृत करता है, उसके लिए Opus की आवश्यकता नहीं है।

व्यस्त शेड्यूल के लिए मुफ्त उपयोग पर निर्भर न रहें। Claude API द्वारा साइनअप पर दिए जाने वाले छोटे क्रेडिट के अलावा, एकमात्र आवर्ती भत्ता Claude Max और Team प्लान के साथ शामिल मासिक API क्रेडिट है: Max 5x पर $100, Max 20x पर $200 और Team पर $500 तक, जो प्रत्येक बिलिंग चक्र में रिफ्रेश होता है। आप इसे एक पात्र प्लान पर 7 दिनों के बाद क्लेम कर सकते हैं, और किसी भुगतान विधि की आवश्यकता नहीं है। यह Claude API, Managed Agents, Agent SDK और playground को कवर करता है, लेकिन Claude Code को नहीं, और यह प्रत्येक चक्र के अंत में समाप्त हो जाता है, आगे नहीं बढ़ता। इसे खर्च करना आपकी खर्च सीमा में गिना जाता है, और एक बार समाप्त होने पर, अनुरोध तब तक रुक जाते हैं जब तक कि संगठन के पास खरीदे गए क्रेडिट न हों।

प्रयास (effort) दूसरा लीवर है। output_config.effort, low, medium, high, xhigh और max को स्वीकार करता है, हालांकि हर मॉडल हर स्तर का समर्थन नहीं करता है। अधिकांश मॉडलों पर डिफ़ॉल्ट high है और Claude Opus 5.5 तथा Claude Haiku 5.5 पर medium है, और किसी मॉडल के डिफ़ॉल्ट को स्पष्ट रूप से सेट करना उसे छोड़ने के समान ही है। कम प्रयास केवल तर्क की लंबाई से अधिक कटौती करता है: दस्तावेज़ीकरण कहता है कि यह Claude को कम टूल कॉल करने और कई ऑपरेशनों को कम कॉल में संयोजित करने के लिए प्रेरित करता है। एक एजेंट पर यह बड़ी बचत है, क्योंकि एक टूल कॉल का बचना एक पूरा अनुरोध है जो कभी नहीं होता।

खतरा यह है कि प्रयास कैश के साथ संघर्ष करता है। अनुरोधों के बीच शीर्ष-स्तरीय मान बदलने से प्रॉम्प्ट कैशिंग अमान्य हो जाती है। Claude Opus 5.5 पर दस्तावेजी उदाहरण में, अनुरोध 2 ने cache_read_input_tokens: 3546 रिपोर्ट किया। अनुरोध 3 ने प्रयास को medium (उस मॉडल का डिफ़ॉल्ट) से बदलकर low कर दिया, और 3546 में से cache_creation_input_tokens तथा 0 में से cache_read_input_tokens रिपोर्ट किया। इसलिए वर्कलोड के बीच शीर्ष-स्तरीय प्रयास को बदलें, कभी भी एक कैश किए गए वार्तालाप के अंदर नहीं। दो तरीके कैश को तोड़े बिना गहराई बदलते हैं। Claude Fable 5.1, Opus 5.5, Opus 5, Sonnet 5.5 और Haiku 5.5 पर, प्रति-संदेश प्रयास परिवर्तन (बीटा, हेडर mid-conversation-output-config-2026-07-01) एक नया स्तर सेट करता है और कैश किए गए प्रीफ़िक्स को वैसा ही छोड़ देता है। किसी भी मॉडल पर आप प्रॉम्प्ट में निर्देश दे सकते हैं: नवीनतम उपयोगकर्ता संदेश पर "बिना विचार किए सीधे उत्तर दें" जैसी एक पंक्ति पहले के ब्रेकपॉइंट्स को बरकरार रखती है। हालांकि, Claude Haiku 5.5 पर, वह वाक्यांश विश्वसनीय रूप से सोच को कम नहीं करता है।

थिंकिंग टोकन आउटपुट दरों पर बिल किए जाते हैं और max_tokens के विरुद्ध गिने जाते हैं, यही कारण है कि एक छोटा उत्तर अक्सर यह दर्शाता है कि थिंकिंग ने बजट खत्म कर दिया है। संख्या के लिए usage.output_tokens_details.thinking_tokens पढ़ें। Claude टोकन बिल को वास्तव में क्या भरता है मीटर का विश्लेषण करता है।

Stable prefix को cache करें और इसे गलती से टूटने से बचाएं

Cache write की कीमत पांच-मिनट वाली cache पर बेस इनपुट कीमत का 1.25 गुना और एक-घंटे वाली cache पर 2 गुना होती है। अधिकांश मॉडलों पर cache read की कीमत 0.1 गुना होती है, इसलिए "5-मिनट की अवधि (1.25x write) के लिए एक cache read के बाद, या 1-घंटे की अवधि (2x write) के लिए दो cache reads के बाद caching फायदेमंद हो जाती है"। नवीनतम मॉडलों पर reads और भी सस्ते हैं: Claude Opus 5.5 और Claude Sonnet 5.5 पर 0.05 गुना, और Claude Fable 5.1 पर 0.025 गुना।

एक पंक्ति बताती है कि यह हमेशा चालू रहने वाले agent के लिए क्यों उपयुक्त है: "हर बार जब cached content का उपयोग किया जाता है, तो cache बिना किसी अतिरिक्त लागत के रिफ्रेश हो जाती है।" पांच-मिनट वाली cache के विरुद्ध हर दो मिनट में चलने वाला job पूरे दिन अपने prefix को एक ही write में warm रखता है।

Cache को बिना जाने खोने के तीन तरीके।

एक prefix जो बदलता है। "Cache prefixes इस क्रम में बनाए जाते हैं: tools, system, फिर messages।" उस क्रम में पहले किसी भी बाइट में बदलाव उसके बाद की हर चीज़ को अमान्य कर देता है, और tool definitions को edit करने से पूरी cache अमान्य हो जाती है। सिस्टम प्रॉम्प्ट में टाइमस्टैम्प या run id का होना एक आम गलती है: हर request फिर एक अलग prefix ले जाती है, 1.25x पर एक नई entry लिखती है, और कुछ भी read नहीं करती। इसका संकेत समान दिखने वाली calls पर usage.cache_read_input_tokens का 0 होना है। अस्थिर टेक्स्ट को नवीनतम user message में ले जाएं।

एक prefix जो बहुत छोटा है। प्रत्येक मॉडल की एक न्यूनतम cacheable लंबाई होती है, और उससे नीचे request बिना caching के प्रोसेस की जाती है और "कोई error नहीं लौटाया जाता"। इन आंकड़ों में Claude Fable 5.1, Fable 5, Opus 5.5, Opus 5, Sonnet 5.5 और Haiku 5.5 पर 512 tokens, Claude Opus 4.8 और Claude Sonnet 5 पर 1,024, और Claude Haiku 4.5 पर 4,096 शामिल हैं, इसलिए किसी job को Sonnet 5 से Haiku 4.5 पर ले जाने से caching चुपचाप बंद हो सकती है।

एक conversation जो lookback से बाहर हो जाती है। "Lookback window 20 blocks की है।" सिस्टम प्रति breakpoint अधिकतम 20 positions की जांच करता है, फिर रुक जाता है। प्रलेखित उदाहरण में, block 35 पर breakpoint के साथ 35 blocks रखने वाला एक turn, block 35 से 16 तक की जांच करता है, और block 15 पर पिछले turn की entry window के बाहर गिर जाती है, इसलिए कोई hit नहीं मिलता। प्रति turn कई tool-use और tool-result blocks जोड़ने वाला एक agent दो या तीन turns में 20 को पार कर जाता है। आपको प्रति request चार breakpoints मिलते हैं, इसलिए एक का उपयोग हाल के संदेशों पर करें।

जो काम तुरंत जरूरी न हों, उन्हें Batches API पर भेजें

"सभी उपयोग पर मानक API कीमतों का 50% शुल्क लिया जाता है", यह इनपुट और आउटपुट दोनों पर लागू होता है। बैच प्रोसेसिंग एसिंक्रोनस (asynchronous) होती है, "जिसमें अधिकांश बैच 1 घंटे से कम समय में पूरे हो जाते हैं", और परिणाम तब मिलते हैं जब हर अनुरोध पूरा हो जाता है या 24 घंटे बाद, जो भी पहले हो। यह सामान्य है, गारंटीकृत नहीं।

processing_status को तब तक पोल (poll) करें जब तक वह ended न हो जाए। errored, canceled या expired लौटाने वाले अनुरोधों के लिए बिल नहीं लिया जाता है। यदि आप स्पेंड कैप (spend cap) पर निर्भर हैं तो एक सावधानी बरतें: "बैच आपके वर्कस्पेस की कॉन्फ़िगर की गई खर्च सीमा से थोड़ा ऊपर जा सकते हैं।"

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

हर रिस्पॉन्स के usage fields को अपने स्टोर में लॉग करें

आप उस खर्च का हिसाब नहीं लगा सकते जिसे आपने रिकॉर्ड ही नहीं किया है। हर रिस्पॉन्स आपको बताता है कि उसकी लागत क्या है।

u = resp.usage
row = {
    "job": job_name,
    "model": resp.model,
    "uncached_input": u.input_tokens,
    "cache_write": u.cache_creation_input_tokens,
    "cache_read": u.cache_read_input_tokens,
    "output": u.output_tokens,
    "stop_reason": resp.stop_reason,
}

हर API कॉल के लिए एक पंक्ति को JSON-lines फाइल में जोड़ें, जिसे आपके जॉब नाम के साथ टैग किया गया हो। एक सप्ताह बाद आप बता पाएंगे कि कौन सा जॉब खर्च कर रहा है और कौन सा केवल व्यस्त होने का दिखावा कर रहा है। cache_read पर नज़र रखें: self-hosted एजेंट में शून्य का कॉलम सबसे आम कॉस्ट बग है।

एक फील्ड को गलत पढ़ना आसान है। input_tokens केवल अंतिम कैश ब्रेकपॉइंट के बाद के टोकन की गिनती करता है, इसलिए वास्तविक प्रॉम्प्ट का आकार total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens है। एक बड़ा प्रॉम्प्ट होने पर input_tokens: 400 रिपोर्ट करने वाला एजेंट सस्ता नहीं है: बाकी हिस्सा कैश से आया है।

भेजने से पहले गिनती करें। टोकन की गिनती मुफ्त है और इसकी रेट लिमिट मैसेज बनाने से अलग है, इसलिए बहुत बड़े अटैचमेंट को भुगतान करके खोजने के बजाय उसे अस्वीकार करने के लिए count_tokens का उपयोग करें। परिणाम एक अनुमान है, इसलिए प्रति मॉडल दोबारा मापें और कभी भी किसी अन्य वेंडर के टोकेनाइज़र से मिली गिनती का पुन: उपयोग न करें। Claude 4.7 और बाद के मॉडल, जिनमें Claude Fable 5 और Claude Sonnet 5 शामिल हैं, एक नए टोकेनाइज़र का उपयोग करते हैं जो "समान टेक्स्ट के लिए लगभग 30% अधिक टोकन उत्पन्न करता है"। Claude Sonnet 4.6 और उससे पहले के मॉडल, जिनमें Claude Haiku 4.5 शामिल हैं, पिछले वाले का उपयोग करते हैं।

आधिकारिक जानकारी के लिए, Admin API https://api.anthropic.com/v1/organizations/usage_report/messages पर उपयोग और https://api.anthropic.com/v1/organizations/cost_report पर लागत की रिपोर्ट करता है। दोनों के लिए एक एडमिन की (sk-ant-admin01-...) की आवश्यकता होती है, जिसे anthropic-version: 2023-06-01 के साथ x-api-key: $ANTHROPIC_ADMIN_KEY के रूप में उपयोग किया जाता है। उपयोग रिपोर्ट bucket_width=1d, group_by[]=model और api_key_ids[]= को स्वीकार करती है। लागत रिपोर्ट केवल दैनिक होती है और workspace_id या description द्वारा समूहीकृत (group) की जाती है। एक सीमा: "Admin API व्यक्तिगत खातों के लिए उपलब्ध नहीं है।"

वह api_key_ids[] पैरामीटर खर्च के श्रेय (attribution) का एक सस्ता तरीका है: प्रत्येक जॉब को अपनी API की दें, api_key_ids[] के साथ उपयोग रिपोर्ट को फ़िल्टर करें, और इसे group_by[]=api_key_id के साथ विभाजित करें। फ़िल्टर बहुवचन (plural) है, ग्रुपिंग डाइमेंशन एकवचन (singular) है। कीज़ को कोड के बजाय एनवायरनमेंट में रखें, ठीक वैसे ही जैसे VPS पर पहला Claude API ऐप उन्हें हैंडल करता है।

लूप को सीमित करें, क्योंकि कोई और ऐसा नहीं करेगा

यहाँ एक सीमित iteration count का होना वैकल्पिक नहीं है। लूप आपका है, इसलिए counter भी आपका ही है:

for step in range(MAX_STEPS):          # MAX_STEPS = 12, never "while True"
    resp = client.messages.create(...)
    if resp.stop_reason != "tool_use":
        break
else:
    log.warning("job %s hit MAX_STEPS=%d, giving up", job_name, MAX_STEPS)

ऊपर दी गई कोई भी सीमा आपके लिए यह काम नहीं करती: max_tokens केवल एक response को सीमित करता है, और model को केवल एक task budget की सलाह दी जाती है। एक hosted product आपको यहाँ रोक देगा, जिस तरह Claude's cap on tool calls within a single turn उस session को रोक देता है जिसमें बहुत अधिक tool calls किए गए हों, लेकिन आपके द्वारा लिखा गया लूप तब तक किसी सुरक्षा के बिना चलता है जब तक आप उसे जोड़ते नहीं हैं।

प्रक्रिया के बाहर एक दूसरा brake लगाएँ। job को एक permanent process के बजाय systemd timer से चलाएँ, और उसकी service unit को एक wall-clock cap दें। एक timer job आमतौर पर Type=oneshot होती है, और RuntimeMaxSec= का "Type=oneshot services पर कोई प्रभाव नहीं पड़ता", इसलिए वहाँ TimeoutStartSec=600 सेट करें। RuntimeMaxSec=600 का उपयोग केवल Type=simple unit पर करें। किसी भी स्थिति में, एक hung run को दस मिनट बाद kill कर दिया जाता है, बजाय इसके कि वह तब तक चलता रहे जब तक आप उस पर ध्यान न दें। Running a program as a systemd service and timer में unit files के बारे में विस्तार से बताया गया है। journalctl -u triage-agent.service --since "1 hour ago" के साथ देखें कि run ने क्या किया।

retries को भी सीमित करें, क्योंकि जो handler हमेशा retry करता है, वह हर प्रयास के लिए billing करता है। 429 या 500 error के लिए backoff के साथ कुछ प्रयासों की आवश्यकता होती है। 400 error के लिए किसी retry की आवश्यकता नहीं है, क्योंकि वही request हर बार उसी तरह विफल होगी।

AI agent की लागत पर नियंत्रण आपके अपने आंकड़ों को पढ़ने से शुरू होता है

कोई भी आपको यह नहीं बता सकता कि हमेशा चलने वाले (always-on) agent की लागत क्या होगी, क्योंकि लागत का अर्थ है प्रति रन टोकन की संख्या जिसे प्रति दिन होने वाले रन की संख्या से गुणा किया जाता है, और ये दोनों आंकड़े आपके पास होते हैं। इसे एक बार चलाएं, आपके द्वारा लॉग की गई usage row को पढ़ें, और इसे अपने शेड्यूल के अनुसार गुणा करें। दो दिन बाद लागत रिपोर्ट की जांच उस गणित के आधार पर करें। जब दोनों में अंतर हो, तो इसका कारण लगभग हमेशा एक टूटा हुआ cache या ऐसा लूप होता है जो आपके अनुमान से अधिक समय तक चला।

यह एक API key को आधार मानकर है, क्योंकि agent आपका अपना प्रोग्राम है जो Messages API को कॉल कर रहा है। अपने स्वयं के इंटरैक्टिव काम के लिए, आपके काम करने के तरीके के लिए कौन सा Claude plan उपयुक्त है सब्सक्रिप्शन वाले हिस्से को कवर करता है। यहाँ दी गई प्रत्येक कीमत और सीमा की जांच अक्टूबर 2026 में Anthropic के documentation के अनुसार की गई थी, इसलिए बजट बनाने से पहले pricing page को दोबारा पढ़ें।

FAQ

VPS पर हमेशा चालू रहने वाले AI agent को चलाने में कितना खर्च आता है?

इसमें दो तरह के बिल होते हैं और केवल एक का अनुमान लगाया जा सकता है। सर्वर की कीमत हर महीने निश्चित होती है। Model API का शुल्क प्रति token के आधार पर लिया जाता है, इसलिए खर्च इस बात पर निर्भर करता है कि एक बार चलाने में कितना खर्च आता है और उसे कितनी बार चलाया जाता है। Anthropic हमेशा चालू रहने वाले self-hosted agent के लिए कोई निश्चित आंकड़ा नहीं देता है, इसलिए किसी भी बताए गए नंबर को केवल एक अनुमान मानें। एक वास्तविक run से usage को log करें और उसे अपने schedule से गुणा करें।

max_tokens और task budget में क्या अंतर है?

max_tokens को लागू किया जाता है और यह model को दिखाई नहीं देता है। यह एक request के output को, जिसमें thinking भी शामिल है, सीमित करता है और इसे पार करने पर stop_reason: "max_tokens" प्राप्त होता है। Task budget इसके विपरीत है: model को यह संख्या बताई जाती है और वह agentic loop को इसके अनुसार नियंत्रित करता है, लेकिन "Task budgets एक soft hint हैं, न कि hard cap" और लागू की गई सीमा अभी भी max_tokens ही रहती है।

मेरे agent के लिए cache_read_input_tokens हमेशा शून्य क्यों रहता है?

क्योंकि calls के बीच prefix बदल जाता है, या यह cache करने के लिए बहुत छोटा होता है। इसका सामान्य कारण system prompt में डाला गया timestamp या run id है: cache prefix पर आधारित होता है, इसलिए किसी भी byte के बदलने से उसके बाद का सब कुछ अमान्य हो जाता है। Tool definitions या top-level effort मान को बदलने से भी ऐसा ही होता है। इसके अलावा, यह आकार के कारण भी हो सकता है, क्योंकि छोटे prompts cache नहीं किए जाते और इसके लिए कोई error नहीं मिलता है।

मैं AI agent को हमेशा के लिए loop में चलने से कैसे रोकूँ?

अपने loop code में iterations की गिनती करें और एक निश्चित अधिकतम सीमा पर रुकें, क्योंकि max_tokens केवल एक response को सीमित करता है और एक agent कई responses बनाता है। process के बाहर एक wall-clock limit जोड़ें: job को systemd timer से शुरू करें और oneshot unit पर TimeoutStartSec=, या simple unit पर RuntimeMaxSec= सेट करें, ताकि फंसा हुआ run schedule के अनुसार kill हो जाए। Retries को भी सीमित करें, क्योंकि retry loop हर प्रयास के लिए billing करता है।

क्या मैं एक Claude API key पर खर्च की सीमा तय कर सकता हूँ?

documented spend limit प्रति key के बजाय प्रति workspace होती है, इसलिए agent को अपना एक अलग workspace दें और वहां उसका मासिक खर्च सीमित करें। "आप Default Workspace पर सीमाएं तय नहीं कर सकते"। खर्च की सूचनाएं (spend notifications) जोड़ें ताकि एक threshold पार होने पर आपको पहले ही alert मिल जाए। attribution के लिए, प्रत्येक job को अपनी key दें, फिर usage report को group_by[]=api_key_id के साथ group करें।

#claude #ai #agents #api #cost