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

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 को सीमित करता है, पूरे task को नहीं। 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 में कोई remaining-budget field नहीं होती है। न्यूनतम स्वीकार्य task_budget.total 20,000 tokens है, और इससे कम होने पर 400 error मिलता है। काम के लिए बहुत छोटा budget होने पर model मना करने जैसा व्यवहार करता है, इसलिए model task को छोटा कर देता है या जल्दी रुक जाता है।

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

Task budgets Claude Fable 5, Claude Opus 4.8 और Claude Opus 4.7 पर 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 के लिए $10 और $50, Claude Opus 4.8 और Opus 4.7 के लिए $5 और $25, Claude Sonnet 5 के लिए $3 और $15, और Claude Haiku 4.5 के लिए $1 और $5। Sonnet 5 की कीमत फिलहाल इसके अंकित मूल्य से कम है, क्योंकि "31 अगस्त 2026 तक प्रति दस लाख इनपुट/आउटपुट टोकन पर $2/$10 की शुरुआती कीमत प्रभावी है"। जो स्टेप केवल लॉग लाइनों को वर्गीकृत करता है, उसके लिए Opus की आवश्यकता नहीं है। व्यस्त शेड्यूल को संभालने के लिए कोई मुफ्त भत्ता भी उपलब्ध नहीं है, क्योंकि Claude API में कोई मुफ्त टियर नहीं है जो साइनअप के समय दिए गए छोटे क्रेडिट से अधिक हो।

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

इसमें एक समस्या यह है कि प्रयास (effort) कैशिंग के साथ विरोधाभास पैदा करता है। रिक्वेस्ट के बीच इस वैल्यू को बदलने से प्रॉम्प्ट कैशिंग अमान्य हो जाती है। डॉक्यूमेंटेड उदाहरण में, रिक्वेस्ट 2 ने cache_read_input_tokens: 3546 रिपोर्ट किया; रिक्वेस्ट 3 में, प्रयास को 'high' से 'medium' करने पर 3546 में से cache_creation_input_tokens और 0 में से cache_read_input_tokens रिपोर्ट किया गया। इसलिए, वर्कलोड के आधार पर प्रयास को बदलें, लेकिन कभी भी एक ही कैश किए गए कन्वर्सेशन के भीतर न बदलें। कैश को तोड़े बिना गहराई को नियंत्रित करने के लिए, इसे प्रॉम्प्ट में करें: सबसे नए यूजर मैसेज पर "बिना विचार किए सीधे उत्तर दें" जैसी एक लाइन लिखने से पहले के ब्रेकपॉइंट्स सुरक्षित रहते हैं।

थिंकिंग टोकन का बिल आउटपुट दरों पर बनता है और यह 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 read के बाद caching फायदेमंद हो जाती है"।

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

Cache खोने के तीन तरीके जिन्हें आप नोटिस नहीं कर पाते।

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

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

एक conversation जो lookback से बाहर हो जाती है। "Lookback window 20 blocks की होती है।" सिस्टम प्रति breakpoint अधिकतम 20 positions की जांच करता है, फिर रुक जाता है। प्रलेखित उदाहरण में, 35 blocks वाली एक turn जिसमें block 35 पर breakpoint है, वह 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) वाले बैच के लिए एक घंटे के कैश की सिफारिश करता है। इसलिए काम को विभाजित करें: जिस काम के लिए कोई व्यक्ति या वेबहुक प्रतीक्षा करता है, उसे लाइव पाथ पर रखें, और नाइटली डाइजेस्ट या कल के लॉग वर्गीकरण जैसे कामों को आधी कीमत पर बैच में डालें।

प्रत्येक रिस्पॉन्स के उपयोग संबंधी डेटा को अपने स्टोर में लॉग करें

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

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 Opus 4.7 और बाद के Opus मॉडल, 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[]= को स्वीकार करते हैं। एक सीमा: "Admin API व्यक्तिगत खातों के लिए उपलब्ध नहीं है।"

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

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

यहाँ एक सीमित इटरेशन काउंट (iteration count) वैकल्पिक नहीं है। लूप आपका है, इसलिए काउंटर भी आपका ही होना चाहिए:

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 केवल एक रिस्पॉन्स को सीमित करता है, और मॉडल को केवल टास्क बजट के बारे में सूचित किया जाता है। एक होस्ट किया गया प्रोडक्ट आपको यहाँ रोक देगा, ठीक वैसे ही जैसे Claude's cap on tool calls within a single turn उस सेशन को रोक देता है जिसमें बहुत अधिक कॉल किए गए हों, लेकिन आपके द्वारा लिखे गए लूप में तब तक कोई सुरक्षा नहीं होती जब तक आप उसे खुद न जोड़ें।

प्रोसेस के बाहर एक दूसरा ब्रेक लगाएँ। जॉब को एक स्थायी प्रोसेस के बजाय systemd timer से चलाएँ, और इसकी सर्विस यूनिट पर RuntimeMaxSec= सेट करें। RuntimeMaxSec=600 के साथ, एक हैंग हुआ रन दस मिनट बाद समाप्त हो जाएगा, बजाय इसके कि वह तब तक चलता रहे जब तक आप उस पर ध्यान न दें। Running a program as a systemd service and timer में यूनिट फाइलों के बारे में विस्तार से बताया गया है। journalctl -u triage-agent.service --since "1 hour ago" के साथ देखें कि रन ने क्या किया।

रीट्राय (retries) को भी सीमित करें, क्योंकि जो हैंडलर हमेशा रीट्राय करता रहता है, वह हर प्रयास के लिए बिल बनाता है। 429 या 500 एरर के लिए बैकऑफ के साथ कुछ प्रयास उचित हैं। 400 एरर के लिए कोई प्रयास न करें, क्योंकि वही रिक्वेस्ट हर बार उसी तरह विफल होगी।

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

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

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

FAQ

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

इसके दो बिल होते हैं और केवल एक ही अनुमानित होता है। सर्वर की कीमत हर महीने निश्चित होती है। Model API का शुल्क token के आधार पर लिया जाता है, इसलिए कुल खर्च एक बार चलने की खपत को उसकी आवृत्ति से गुणा करने पर निकलता है। Anthropic हमेशा चालू रहने वाले self-hosted agent के लिए कोई निश्चित आंकड़ा नहीं देता है, इसलिए किसी भी बताए गए नंबर को केवल एक अनुमान मानें। एक वास्तविक run से usage लॉग करें और उसे अपने 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 या effort मान को बदलने से भी ऐसा ही होता है। अन्यथा यह आकार के कारण होता है, क्योंकि छोटे prompts cache नहीं किए जाते और कोई error भी नहीं मिलता।

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

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

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

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