VPS पर AI agent का खर्च कैसे कम करें

AI agent के खर्च को नियंत्रित कैसे रखें

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

यह एक ऐसे agent के लिए है जो पहले से मौजूद है और आपके अपने machine से Messages API को call करता है। VPS पर Claude के साथ AI agent बनाना में इसके बुनियादी ढांचे (machinery) के बारे में बताया गया है।

Unattended agent का cost shape अलग क्यों होता है

एक interactive session में इंसान शामिल होता है। जब model गलत दिशा में जाता है या 40,000-line वाली log पढ़ता है, तो देखने वाला व्यक्ति उसे रोक देता है। Unattended agent में ऐसा कोई brake नहीं होता: यह loop खत्म होने तक चलता रहता है, फिर timer इसे दोबारा शुरू कर देता है।

लोग Frequency को नजरअंदाज कर देते हैं। Five-minute schedule वाला job दिन में 288 बार और महीने में लगभग 8,640 बार चलता है। एक run की जितनी भी cost हो, आपको उसी figure को multiply करना होगा। कई "always-on" agents को हमेशा चालू रहने की आवश्यकता नहीं होती। उन्हें कुछ निश्चित मिनटों के भीतर जवाब देना होता है, जो कि एक schedule है।

एक agent उन चीजों के लिए भी भुगतान करता है जो chat window में नहीं होतीं।

• Tool definitions हर request के साथ जाते हैं। Claude Opus 4.8 पर tool-use system prompt की cost tool_choice of auto या none के साथ 290 tokens है, और any या tool के साथ 410 है। Bash tool 325 और जोड़ता है। आप जो भी MCP server attach करते हैं वह अपने schemas इस weight में जोड़ देता है, जहाँ MCP का मतलब model context protocol है।
• Tool results input tokens होते हैं। एक command जो 8,000 lines print करती है, वह अगली request में और उस turn की उसके बाद की हर request में 8,000 lines भेजती है।
• Fetched pages input tokens होते हैं। एक average 10 kB वेब page लगभग 2,500 tokens का होता है और 500 kB research PDF लगभग 125,000 tokens का। max_content_tokens केवल text वाले content को truncate करता है, क्योंकि यह "applies to text content, not to binary content such as PDFs" है। इसके बजाय PDF को max_uses और allowed_domains के साथ bind करें।
• Web search की pricing per search है, जो $10 per 1,000 searches है, चाहे कितने भी results मिलें। Error होने वाली search के लिए billing नहीं होती।

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

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

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

Task budget केवल एक advisory है। 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 के बीच में limit से आगे जा सकता है, और output पर लागू limit अभी भी max_tokens ही रहेगी। "Countdown केवल model को दिखाई देता है", और responses में remaining-budget field नहीं होता है। न्यूनतम स्वीकार्य task_budget.total 20,000 tokens है, और इससे कम होने पर 400 error मिलता है। यदि budget काम के लिए बहुत कम है, तो model काम करने से मना कर सकता है, जिससे वह task को छोटा कर देता है या जल्दी रुक जाता है।

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

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

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

Per-job model choice, aur actual effort mein kya badlav aata hai

Model ka chunav har job ke liye alag hota hai. July 2026 tak, per million tokens ke hisaab se, input aur output rates ye hain: Claude Fable 5 ke liye $10 aur $50, Claude Opus 4.8 aur Opus 4.7 ke liye $5 aur $25, Claude Sonnet 5 ke liye $3 aur $15, aur Claude Haiku 4.5 ke liye $1 aur $5. Sonnet 5 abhi apne sticker price se kam par hai, kyunki "Introductory pricing of $2/$10 per million input/output tokens is in effect through August 31, 2026". Agar kaam sirf log lines classify karna hai, to Opus ki zaroorat nahi hai.

Effort doosra lever hai. output_config.effort, low, medium, high, xhigh aur max ko accept karta hai, aur default value high hai, isliye high ko explicitly set karna use omit karne ke barabar hai. Kam effort se sirf reasoning length hi kam nahi hoti: documentation ke anusar, ye Claude ko kam tool calls karne aur operations ko ek saath combine karne ke liye kehta hai. Agent ke case mein ye zyada bachat karta hai, kyunki ek avoided tool call ka matlab hai ek poori request jo kabhi nahi hogi.

Ek trap ye hai ki effort, cache ke saath conflict karta hai. Requests ke beech mein value badalne se prompt caching invalid ho jati hai. Documented example mein, request 2 ne cache_read_input_tokens: 3546 report kiya; request 3 mein, jisme effort high se medium kar diya gaya tha, cache_creation_input_tokens 3546 aur cache_read_input_tokens 0 report kiya gaya. Isliye, alag-alag workloads ke beech effort badlein, ek hi cached conversation ke andar nahi. Cache ko break kiye bina depth control karne ke liye, ise prompt mein karein: sabse naye user message mein "Answer directly without deliberating." jaisi line likhne se pehle ke breakpoints intact rehte hain.

Thinking tokens output rates par bill hote hain aur max_tokens mein count hote hain, isliye aksar truncated answer ka matlab hota hai ki thinking ne budget khatam kar diya. Number ke liye usage.output_tokens_details.thinking_tokens padhein. Claude token bill mein asliyat mein kya bharta hai iska vistaar se vivaran deta hai.

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

Five-minute cache पर cache write की लागत base input price का 1.25 गुना है, और one-hour cache पर यह 2 गुना है। Cache read की लागत 0.1 गुना है, इसलिए "5-minute duration (1.25x write) के लिए केवल एक cache read के बाद caching फायदेमंद हो जाती है, या 1-hour duration (2x write) के लिए दो cache reads के बाद फायदेमंद हो जाती है।"

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

बिना पता चले cache खोने के तीन तरीके।

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

एक prefix जो बहुत छोटा है। प्रत्येक model की एक minimum cacheable length होती है, और उससे नीचे request बिना caching के process होती है और "कोई error return नहीं होता है"। इन आंकड़ों में 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 है।" System प्रत्येक breakpoint पर अधिकतम 20 positions चेक करता है, फिर रुक जाता है। दस्तावेज़ में दिए गए उदाहरण में, block 35 पर breakpoint के साथ 35 blocks वाला एक turn, block 35 से 16 तक के blocks को चेक करता है, और block 15 पर पिछले turn की entry window से बाहर होती है, इसलिए कोई hit नहीं मिलता है। एक agent जो प्रति turn कई tool-use और tool-result blocks जोड़ता है, वह दो या तीन turns में 20 की सीमा पार कर जाता है। आपको प्रति request चार breakpoints मिलते हैं, इसलिए एक breakpoint हालिया messages के लिए उपयोग करें।

जो काम इंतज़ार कर सकते हैं उन्हें Batches API पर भेजें

Input और output दोनों पर "सभी उपयोग के लिए standard API कीमतों का 50% शुल्क लिया जाता है"। Batch processing asynchronous है, "ज्यादातर batches 1 hour से कम समय में पूरे हो जाते हैं"। परिणाम तब मिलते हैं जब सभी requests पूरी हो जाती हैं या 24 hours बाद, जो भी पहले हो। यह एक सामान्य प्रक्रिया है, इसकी गारंटी नहीं है।

processing_status को तब तक poll करें जब तक वह ended न हो जाए। errored, canceled या expired लौटाने वाली requests का बिल नहीं लिया जाता है। यदि आप spend cap का उपयोग करते हैं, तो एक सावधानी: "batches आपके Workspace की configured spend limit से थोड़ा अधिक हो सकते हैं।"

Discounts एक साथ लागू होते हैं। चूंकि एक batch में पांच मिनट से अधिक का समय लग सकता है, इसलिए documentation एक ही context साझा करने वाले batches के लिए one-hour cache की सलाह देता है। इसलिए काम को विभाजित करें: जिस काम के लिए व्यक्ति या webhook का इंतज़ार करना पड़ता है, उसे live path पर रखें, और nightly digest या yesterday's log classification को आधे दाम पर batch में भेजें।

प्रत्येक response के usage fields को अपने स्वयं के store में log करें

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

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 call के लिए JSON-lines file में एक row जोड़ें, और उसे अपने job name से tag करें। एक सप्ताह बाद आप बता पाएंगे कि किस job ने कितना खर्च किया और कौन सा केवल busy दिखा। cache_read पर ध्यान दें: self-hosted agent में zeros का column सबसे आम cost bug है।

एक field को पढ़ना आसान है लेकिन गलत हो सकता है। input_tokens केवल अंतिम cache breakpoint के बाद के tokens को गिनता है, इसलिए वास्तविक prompt size total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens है। यदि कोई agent बड़े prompt पर input_tokens: 400 report करता है, तो वह सस्ता नहीं है: बाकी हिस्सा cache से आया था।

भेजने से पहले गणना करें। Token counting मुफ्त है और इसकी rate limits message creation से अलग होती हैं, इसलिए oversized attachment के लिए भुगतान करने के बजाय उसे अस्वीकार करने हेतु count_tokens का उपयोग करें। परिणाम एक estimate है, इसलिए प्रत्येक model के लिए पुन: मापें और किसी अन्य vendor के tokenizer के count का उपयोग कभी न करें। Claude Opus 4.7 और बाद के Opus models, Claude Fable 5 और Claude Sonnet 5 एक नए tokenizer का उपयोग करते हैं जो "उसी text के लिए लगभग 30% अधिक tokens produce करता है"। Claude Sonnet 4.6 और उससे पहले के, Claude Haiku 4.5 सहित, पिछले tokenizer का उपयोग करते हैं।

सटीक जानकारी के लिए, Admin API https://api.anthropic.com/v1/organizations/usage_report/messages पर usage और https://api.anthropic.com/v1/organizations/cost_report पर cost report करता है। दोनों anthropic-version: 2023-06-01 के साथ x-api-key: $ANTHROPIC_ADMIN_KEY के रूप में admin key (sk-ant-admin01-...) लेते हैं, और bucket_width=1d, group_by[]=model और api_key_ids[]= स्वीकार करते हैं। एक सीमा: "The Admin API is unavailable for individual accounts."

यह अंतिम parameter attribution का एक सस्ता तरीका है: प्रत्येक job को अपनी स्वयं की API key दें, api_key_ids[] के साथ filter करें, और group_by[]=api_key_id के साथ key के अनुसार report को विभाजित करें। Filter plural है, grouping dimension singular है। Keys को code के बजाय environment में रखें, जैसे a first Claude API app on a VPS उन्हें handle करता है।

Bound the loop, because nothing else will

A bounded iteration count is not optional here. The loop is yours, so the counter is yours:

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)

Neither ceiling above does it for you: max_tokens caps one response, and the model is only advised of a task budget.

Put a second brake outside the process. Run the job from a systemd timer instead of a permanent process, and set RuntimeMaxSec= on its service unit. With RuntimeMaxSec=600, a hung run is killed after ten minutes instead of spinning until you notice. Running a program as a systemd service and timer covers the unit files themselves. Read what a run did with journalctl -u triage-agent.service --since "1 hour ago".

Cap retries as well, because a handler that retries forever bills every attempt. A 429 or a 500 deserves a few tries with backoff. A 400 deserves none, since the same request fails the same way.

AI agent cost control की शुरुआत अपने स्वयं के आंकड़ों को पढ़ने से होती है

कोई भी आपको यह नहीं बता सकता कि एक always-on agent की लागत क्या होगी। इसका कारण यह है कि लागत, प्रति run tokens और प्रति day runs का गुणनफल होती है, और ये दोनों आपके नियंत्रण में होते हैं। इसे एक बार चलाएं, अपने द्वारा log किए गए usage row को पढ़ें, और अपने schedule से गुणा करें। दो दिन बाद उस arithmetic के विरुद्ध cost report की जांच करें। जब दोनों में अंतर हो, तो वह अंतर लगभग हमेशा किसी broken cache या ऐसे loop के कारण होता है जो आपकी अपेक्षा से अधिक समय तक चला।

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

FAQ

VPS पर always-on AI agent चलाने का खर्च कितना आता है?

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

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

max_tokens को लागू (enforce) किया जाता है और यह 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 हमेशा zero क्यों रहता है?

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

मैं AI agent को अनंत काल तक looping करने से कैसे रोकूँ?

अपने loop code में iterations को count करें और एक fixed maximum पर रुक जाएँ, क्योंकि max_tokens केवल एक response को सीमित करता है और एक agent कई requests करता है। Process के बाहर एक wall-clock limit जोड़ें: job को RuntimeMaxSec= के साथ systemd timer से शुरू करें, ताकि फँसा हुआ (wedged) run schedule के अनुसार बंद हो जाए। Retries को भी सीमित करें, क्योंकि retry loop में हर attempt का बिल आता है।

क्या मैं एक single Claude API key पर spending limit सेट कर सकता हूँ?

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