VPS वर AI एजंटचा खर्च कसा नियंत्रित करावा?

नेहमी चालू असलेल्या AI एजंटचा खर्च कसा नियंत्रित करावा

VPS (virtual private server) वर AI एजंटचा खर्च नियंत्रित करण्यासाठी एजंट सुरू करण्यापूर्वीच मर्यादा निश्चित करणे आवश्यक आहे, कारण तो चालू असताना कोणीही मीटरवर लक्ष ठेवत नाही. प्रत्येक प्रतिसादासाठी max_tokens वापरून मर्यादा घाला, तुमच्या कोडमध्ये लूप इटरेशन्सवर बंधने ठेवा, प्रॉम्प्टचा जो भाग कधीही बदलत नाही तो कॅश (cache) करा आणि कोणत्या कामासाठी किती खर्च होतो हे पाहण्यासाठी प्रत्येक प्रतिसादाच्या वापराची आकडेवारी लॉग करा. सर्व्हरचे भाडे दरमहा निश्चित असते. मॉडेल API चा खर्च प्रति टोकन (token) मोजला जातो आणि विना देखरेख चालणारा लूप शांतपणे खूप टोकन्स खर्च करू शकतो.

हे गृहीत धरते की एजंट आधीच अस्तित्वात आहे आणि तुमच्या मालकीच्या सर्व्हरवरून Messages API ला कॉल करतो. VPS वर Claude सह AI एजंट तयार करणे मध्ये या यंत्रणेची माहिती दिली आहे.

अनअटेंडेड एजंटचा खर्चाचा आराखडा वेगळा का असतो

इंटरअॅक्टिव्ह सत्रात एक माणूस उपस्थित असतो. जेव्हा मॉडेल चुकीच्या मार्गावर जाते किंवा 40,000 ओळींचा लॉग वाचते, तेव्हा पाहणारी व्यक्ती त्याला थांबवते. अनअटेंडेड एजंटकडे असा कोणताही ब्रेक नसतो: तो लूप संपेपर्यंत चालतो आणि त्यानंतर टायमर त्याला पुन्हा सुरू करतो.

वारंवारता (frequency) हा असा घटक आहे जो लोकांच्या लक्षात येत नाही. पाच मिनिटांच्या वेळापत्रकावर चालणारे काम दिवसातून 288 वेळा आणि महिन्यातून सुमारे 8,640 वेळा चालते. एका रनचा जो खर्च असेल, त्याला या संख्येने गुणायचे असते. अनेक "always-on" एजंट्सना सतत चालू ठेवण्याची गरज नसते. त्यांना काही मिनिटांच्या आत प्रतिसाद देणे आवश्यक असते, जे एका वेळापत्रकाद्वारे साध्य करता येते.

एजंट अशा गोष्टींसाठीही पैसे मोजतो ज्या चॅट विंडोसाठी लागत नाहीत.

• टूल डेफिनिशन्स प्रत्येक विनंतीसोबत जातात. Claude Opus 4.8 वर tool_choice ऑफ 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 फक्त मजकूर असलेल्या फाइल्सना ट्रंकेट करते, कारण ते "PDF सारख्या बायनरी कंटेंटला नाही, तर फक्त टेक्स्ट कंटेंटला लागू होते". त्याऐवजी PDF ला max_uses आणि allowed_domains ने मर्यादित करा.
• वेब सर्चचे मूल्य प्रति सर्च आकारले जाते, जे प्रति 1,000 सर्चसाठी $10 इतके आहे, मग कितीही रिझल्ट्स आले तरीही. ज्या सर्चमध्ये एरर येते, त्याचे बिल आकारले जात नाही.

यातील कोणतीही गोष्ट एकदा करताना महाग वाटत नाही. पण 8,640 वेळा करताना या सर्वांचा खर्च मोठा होतो.

हार्ड सीलिंग आणि सॉफ्ट सीलिंग वेगवेगळ्या समस्या सोडवतात

max_tokens सक्तीने लागू केले जाते. ही एका विनंतीच्या एकूण आउटपुटवर, विचार (thinking) आणि प्रतिसाद मजकूर मिळून असलेली एक हार्ड मर्यादा आहे. Claude या मर्यादेपलीकडे कधीही जनरेट करत नाही आणि मॉडेलला हा आकडा दिसत नाही. ही मर्यादा गाठल्यास stop_reason: "max_tokens" मिळते आणि उत्तर अपूर्ण राहते. एजंट्ससाठी अडचण अशी की: टूल-यूझ लूपमधील प्रत्येक विनंती स्वतःची max_tokens सोबत नेते, त्यामुळे ती एका प्रतिसादाला मर्यादित करते, संपूर्ण कार्याला नाही. 4,000 टोकन्सवर दहा टूल कॉल्स म्हणजे त्या टर्नसाठी 40,000 टोकन्सची मर्यादा असते.

टास्क बजेट हे सल्लागार स्वरूपाचे असते. task_budget हे output_config च्या आत असते आणि मॉडेलला संपूर्ण एजंट लूपसाठी, ज्यामध्ये विचार, टूल कॉल्स, टूलचे निकाल आणि आउटपुट यांचा समावेश होतो, किती टोकन्स उपलब्ध आहेत हे सांगते.

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,
)

"टास्क बजेट ही एक सॉफ्ट सूचना आहे, हार्ड मर्यादा नाही." Claude कृती दरम्यान ती ओलांडू शकते आणि आउटपुटवर सक्तीची मर्यादा अजूनही max_tokens असते. "काऊंटडाऊन फक्त मॉडेललाच दिसतो", आणि प्रतिसादांमध्ये उर्वरित बजेट दर्शवणारे कोणतेही फील्ड नसते. किमान स्वीकार्य task_budget.total हे 20,000 टोकन्स आहे, त्यापेक्षा कमी असल्यास 400 एरर मिळते. कामासाठी बजेट खूपच कमी असल्यास मॉडेल नकार देण्यासारखे वर्तन करते, त्यामुळे मॉडेल कार्याची व्याप्ती कमी करते किंवा लवकर थांबते.

एक तपशील पैसे वाचवण्याऐवजी खर्च वाढवतो. जर तुमचा क्लायंट प्रत्येक फॉलो-अप विनंतीवर task_budget.remaining कमी करत असेल, तर बदललेले मूल्य त्यामध्ये समाविष्ट असलेल्या कोणत्याही कॅश्ड प्रीफिक्सला अवैध ठरवते. हे मूल्य एकदाच, पहिल्या विनंतीवर सेट करा.

टास्क बजेट हे Claude Fable 5, Claude Opus 4.8 आणि Claude Opus 4.7 वर बीटा आवृत्तीत आहेत. Claude Sonnet 5 आणि Claude Haiku 4.5 हे Not supported म्हणून सूचीबद्ध आहेत आणि टास्क बजेट Claude Code ला लागू होत नाहीत, त्यामुळे tmux मध्ये वेगळे केलेले Claude Code सत्र हे सत्र स्वच्छतेवर (session hygiene) अवलंबून असते.

तिसरी मर्यादा Claude Console मध्ये असते: एजंटला स्वतःचे वर्कस्पेस द्या, त्यानंतर त्यावर मासिक खर्च मर्यादा आणि प्रति-मिनिट दर मर्यादा सेट करा. "तुम्ही Default Workspace वर मर्यादा सेट करू शकत नाही", आणि "संस्था-व्यापी मर्यादा नेहमी लागू होतात, जरी वर्कस्पेस मर्यादांची बेरीज त्यापेक्षा जास्त असली तरीही". खर्चाच्या सूचना (spend notifications) जोडा जेणेकरून मर्यादा गाठण्यापूर्वीच तुम्हाला थ्रेशोल्डबद्दल अलर्ट मिळेल.

प्रत्येक जॉबसाठी मॉडेलची निवड आणि प्रत्यक्ष प्रयत्नांचा (effort) परिणाम

मॉडेलची निवड हा प्रत्येक जॉबसाठी स्वतंत्र निर्णय असतो. जुलै 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 मध्ये कोणतीही मोफत श्रेणी (free tier) नाही, केवळ साइनअपच्या वेळी दिलेले छोटे क्रेडिट वगळता.

प्रयत्न (effort) हे दुसरे महत्त्वाचे साधन आहे. output_config.effort हे low, medium, high, xhigh आणि max स्वीकारते, आणि डीफॉल्ट मूल्य high आहे, त्यामुळे high स्पष्टपणे सेट करणे हे ते न लिहिण्यासारखेच आहे. कमी प्रयत्न केल्याने केवळ विचार करण्याची लांबी (reasoning length) कमी होत नाही: दस्तऐवजानुसार, यामुळे Claude कमी टूल कॉल्स घेते आणि ऑपरेशन्स एकत्र करते. एजंटच्या बाबतीत ही मोठी बचत आहे, कारण टाळलेला टूल कॉल म्हणजे एक पूर्ण विनंती जी कधीच होत नाही.

यातील धोका असा की, 'effort' हे कॅशेच्या (cache) विरोधात काम करते. विनंत्यांच्या दरम्यान हे मूल्य बदलल्यास प्रॉम्प्ट कॅशिंग अवैध ठरते. दस्तऐवजीकरण केलेल्या उदाहरणात, विनंती 2 ने cache_read_input_tokens: 3546 नोंदवले; विनंती 3 मध्ये, 'effort' हायवरून मीडियम केल्यावर cache_creation_input_tokens पैकी 3546 आणि cache_read_input_tokens पैकी 0 नोंदवले गेले. त्यामुळे 'effort' हे वर्कलोडनुसार बदला, पण एकाच कॅश केलेल्या संभाषणात कधीही बदलू नका. कॅशे न तोडता खोली (depth) नियंत्रित करण्यासाठी, ते प्रॉम्प्टमध्ये करा: नवीन वापरकर्त्याच्या संदेशावर "विना विलंब थेट उत्तर द्या" अशी ओळ लिहिल्याने आधीचे ब्रेकपॉइंट्स सुरक्षित राहतात.

थिंकिंग टोकन्सचे बिल आउटपुट दराने आकारले जाते आणि ते max_tokens च्या मर्यादेत मोजले जातात, म्हणूनच अर्धवट उत्तर मिळणे म्हणजे थिंकिंगने बजेट संपवले आहे असा अर्थ होतो. संख्येसाठी usage.output_tokens_details.thinking_tokens वाचा. Claude टोकन बिल कशामुळे भरले जाते हे या प्रक्रियेचे सविस्तर विश्लेषण करते.

स्थिर प्रीफिक्स कॅश करा आणि ते चुकून खराब करणे थांबवा

कॅश राईटची किंमत 5-मिनिटांच्या कॅशसाठी मूळ इनपुट किमतीच्या 1.25 पट आणि 1-तासाच्या कॅशसाठी 2 पट असते. कॅश रीडची किंमत 0.1 पट असते, त्यामुळे "5-मिनिटांच्या कालावधीसाठी (1.25x राईट) केवळ एका कॅश रीडनंतर किंवा 1-तासाच्या कालावधीसाठी (2x राईट) दोन कॅश रीडनंतर कॅशचा फायदा होतो".

नेहमी चालू असलेल्या एजंटसाठी हे का योग्य आहे, हे एका ओळीत स्पष्ट केले आहे: "कॅश केलेली सामग्री प्रत्येक वेळी वापरली जाते तेव्हा कोणतीही अतिरिक्त किंमत न देता कॅश रिफ्रेश केली जाते." 5-मिनिटांच्या कॅशवर दर दोन मिनिटांनी चालणारे जॉब एका राईटमध्ये दिवसभर प्रीफिक्स गरम (warm) ठेवतात.

कॅश न समजता गमावण्याचे तीन मार्ग.

बदलणारे प्रीफिक्स. "कॅश प्रीफिक्स खालील क्रमाने तयार केले जातात: tools, system, त्यानंतर messages." त्या क्रमाने आधी झालेला कोणताही बाइट बदल त्यानंतरच्या सर्व गोष्टी अवैध ठरवतो आणि टूल डेफिनिशन संपादित केल्याने संपूर्ण कॅश अवैध ठरते. सिस्टिम प्रॉम्प्टमध्ये टाइमस्टॅम्प किंवा रन आयडी असणे ही स्वतःहून ओढवून घेतलेली एक सामान्य चूक आहे: प्रत्येक विनंती त्यानंतर एक वेगळा प्रीफिक्स घेऊन येते, 1.25x वर नवीन एन्ट्री लिहिते आणि काहीही वाचत नाही. सारख्या दिसणाऱ्या कॉल्सवर usage.cache_read_input_tokens चे मूल्य 0 असणे हे याचे लक्षण आहे. अस्थिर मजकूर सर्वात नवीन युजर मेसेजमध्ये हलवा.

खूप लहान प्रीफिक्स. प्रत्येक मॉडेलची किमान कॅश करण्यायोग्य लांबी असते आणि त्यापेक्षा कमी लांबी असल्यास विनंती कॅशिंगशिवाय प्रक्रिया केली जाते आणि "कोणतीही त्रुटी परत केली जात नाही". यामध्ये Claude Opus 4.8 आणि Claude Sonnet 5 वर 1,024 टोकन्स आणि Claude Haiku 4.5 वर 4,096 टोकन्सचा समावेश आहे, त्यामुळे जॉब Sonnet वरून Haiku वर हलवल्यास कॅशिंग नकळत बंद होऊ शकते.

लुकबॅकच्या बाहेर जाणारे संभाषण. "लुकबॅक विंडो 20 ब्लॉक्सची आहे." सिस्टिम प्रत्येक ब्रेकपॉईंटवर जास्तीत जास्त 20 पोझिशन्स तपासते आणि नंतर थांबते. दस्तऐवजीकरण केलेल्या उदाहरणात, 35 ब्लॉक्स असलेला टर्न आणि 35 व्या ब्लॉकवर ब्रेकपॉईंट असल्यास 35 ते 16 ब्लॉक्स तपासले जातात आणि 15 व्या ब्लॉकवरील मागील टर्नची एन्ट्री विंडोच्या बाहेर पडते, त्यामुळे कोणताही हिट मिळत नाही. प्रति टर्न अनेक टूल-युज आणि टूल-रिझल्ट ब्लॉक्स जोडणारा एजंट दोन किंवा तीन टर्नमध्ये 20 ची मर्यादा ओलांडतो. तुम्हाला प्रति विनंती चार ब्रेकपॉईंट्स मिळतात, त्यामुळे एक अलीकडील मेसेजेसवर खर्च करा.

जे काम त्वरित होणे आवश्यक नाही ते Batches API कडे पाठवा

"सर्व वापरासाठी मानक API किमतीच्या 50% शुल्क आकारले जाते", हे इनपुट आणि आउटपुट दोन्हीसाठी लागू आहे. बॅच प्रोसेसिंग हे असिंक्रोनस (asynchronous) असते, "बहुतेक बॅचेस 1 तासापेक्षा कमी वेळात पूर्ण होतात". सर्व विनंत्या पूर्ण झाल्यावर किंवा 24 तासांनंतर, यापैकी जे आधी घडेल तेव्हा निकाल मिळतात. ही एक सामान्य स्थिती आहे, याची खात्री दिली जात नाही.

processing_status जोपर्यंत ended असे वाचत नाही तोपर्यंत पोल (poll) करत राहा. errored, canceled किंवा expired देणाऱ्या विनंत्यांसाठी शुल्क आकारले जात नाही. जर तुम्ही स्पेंड कॅप (spend cap) वापरत असाल, तर एक गोष्ट लक्षात ठेवा: "बॅचेस तुमच्या वर्कस्पेसच्या निर्धारित खर्च मर्यादेपेक्षा थोड्या जास्त जाऊ शकतात."

सवलती एकत्रित होतात आणि बॅचला पाच मिनिटांपेक्षा जास्त वेळ लागू शकत असल्याने, दस्तऐवजीकरण समान संदर्भ (context) असलेल्या बॅचेससाठी एक तासाच्या कॅशेची (cache) शिफारस करते. त्यामुळे कामाचे विभाजन करा: ज्या गोष्टीसाठी एखादी व्यक्ती किंवा webhook वाट पाहत आहे, ती लाइव्ह पाथवर ठेवा. तर रात्रीचा सारांश (nightly digest) किंवा कालच्या लॉगचे वर्गीकरण यांसारखी कामे अर्ध्या किमतीत बॅचमध्ये पूर्ण करा.

प्रत्येक प्रतिसादाचे 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 फक्त शेवटच्या cache breakpoint नंतरचे टोकन्स मोजते, त्यामुळे प्रत्यक्ष प्रॉम्प्टचा आकार 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 वर खर्च रिपोर्ट करते. दोन्हीसाठी admin key (sk-ant-admin01-...) ही x-api-key: $ANTHROPIC_ADMIN_KEY म्हणून anthropic-version: 2023-06-01 सोबत लागते आणि ती bucket_width=1d, group_by[]=model आणि api_key_ids[]= स्वीकारते. एक मर्यादा: "Admin API वैयक्तिक खात्यांसाठी उपलब्ध नाही."

तो शेवटचा पॅरामीटर म्हणजे खर्चाचे विभाजन करण्याची एक स्वस्त युक्ती आहे: प्रत्येक जॉबला स्वतःची API key द्या, api_key_ids[] ने फिल्टर करा आणि group_by[]=api_key_id वापरून रिपोर्टचे विभाजन करा. फिल्टर अनेक असू शकतात, परंतु ग्रुपिंग डायमेंशन एकच असते. कीज कोडमध्ये ठेवण्याऐवजी environment मध्ये ठेवा, ज्याप्रमाणे 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 फक्त एका प्रतिसादावर मर्यादा घालते आणि मॉडेलला फक्त टास्क बजेटबद्दल सूचित केले जाते. एखादे hosted उत्पादन तुम्हाला येथे थांबवेल, ज्याप्रमाणे Claude's cap on tool calls within a single turn एका सत्राला थांबवते ज्यामध्ये खूप जास्त कॉल्स झाले आहेत, परंतु तुम्ही स्वतः लिहिलेल्या लूपमध्ये जोपर्यंत तुम्ही स्वतः एखादी मर्यादा घालत नाही, तोपर्यंत कोणताही बॅकस्टॉप नसतो.

प्रक्रियेच्या बाहेर एक दुसरा ब्रेक लावा. जॉब कायमस्वरूपी प्रक्रियेऐवजी systemd timer वरून चालवा आणि त्याच्या service unit वर RuntimeMaxSec= सेट करा. RuntimeMaxSec=600 मुळे, एखादी अडकलेली प्रक्रिया दहा मिनिटांनंतर आपोआप बंद होईल, अन्यथा ती तुमच्या लक्षात येईपर्यंत चालूच राहील. Running a program as a systemd service and timer मध्ये युनिट फाइल्सबद्दल माहिती दिली आहे. प्रक्रियेने काय केले हे पाहण्यासाठी journalctl -u triage-agent.service --since "1 hour ago" वापरा.

रीट्राय (retries) वरही मर्यादा घाला, कारण जो हँडलर सतत रीट्राय करतो तो प्रत्येक प्रयत्नासाठी बिल आकारतो. 429 किंवा 500 एरर आल्यास backoff सह काही प्रयत्न करणे योग्य आहे. 400 एरर आल्यास कोणताही प्रयत्न करू नका, कारण तीच विनंती पुन्हा पुन्हा त्याच प्रकारे अपयशी ठरेल.

AI एजंटच्या खर्चावर नियंत्रण मिळवण्यासाठी स्वतःच्या आकडेवारीचे विश्लेषण करा

नेहमी चालू असलेल्या एजंटचा खर्च किती असेल हे कोणीही सांगू शकत नाही, कारण हा खर्च 'प्रति रन टोकन्स' आणि 'दिवसातील एकूण रन' यांच्या गुणाकारावर अवलंबून असतो आणि या दोन्ही गोष्टी तुमच्या नियंत्रणात असतात. एकदा एजंट चालवा, तुम्ही नोंदवलेली वापराची आकडेवारी (usage row) वाचा आणि तुमच्या वेळापत्रकानुसार त्याचा गुणाकार करा. दोन दिवसांनंतर खर्चाचा अहवाल तपासा आणि तुमच्या गणिताशी त्याची पडताळणी करा. जेव्हा या दोन्ही आकड्यांमध्ये तफावत आढळते, तेव्हा त्याचे मुख्य कारण बहुधा खराब झालेला कॅशे (broken cache) किंवा तुमच्या अपेक्षेपेक्षा जास्त काळ चाललेला लूप (loop) हे असते.

हे विश्लेषण API key वर आधारित आहे, कारण एजंट हा तुमचा स्वतःचा प्रोग्राम आहे जो Messages API ला कॉल करतो. तुमच्या वैयक्तिक संवादात्मक कामासाठी, तुमच्या कामाच्या पद्धतीनुसार कोणता Claude प्लॅन योग्य आहे यामध्ये सबस्क्रिप्शनच्या बाजूने माहिती दिली आहे. जुलै 2026 मध्ये Anthropic च्या दस्तऐवजीकरणानुसार येथील प्रत्येक किंमत आणि मर्यादा तपासली गेली आहे, त्यामुळे बजेट तयार करण्यापूर्वी कृपया अधिकृत pricing पेज पुन्हा एकदा वाचा.

FAQ

VPS वर नेहमी चालू असणारा AI एजंट चालवण्यासाठी किती खर्च येतो?

यामध्ये दोन प्रकारची बिले असतात, ज्यापैकी फक्त एकच निश्चित असते. सर्व्हरचा खर्च दरमहा ठराविक असतो. मॉडेल API चा खर्च टोकननुसार मोजला जातो, त्यामुळे एका रनचा खर्च आणि तो किती वेळा चालवला जातो, यावर एकूण खर्च अवलंबून असतो. Anthropic ने स्वतःहून होस्ट केलेल्या आणि नेहमी चालू असणाऱ्या एजंटसाठी कोणतीही निश्चित रक्कम जाहीर केलेली नाही, त्यामुळे कोणत्याही आकड्याला केवळ एक अंदाज समजावे. एका प्रत्यक्ष रनचा लॉग usage तपासा आणि तुमच्या वेळापत्रकानुसार त्याला गुणाकार करा.

max_tokens आणि task budget यामध्ये काय फरक आहे?

max_tokens हे सक्तीचे असते आणि ते मॉडेलला दिसत नाही. हे एका विनंतीच्या आउटपुटवर (विचार प्रक्रियेसह) मर्यादा घालते आणि ही मर्यादा ओलांडल्यास stop_reason: "max_tokens" मिळते. Task budget याच्या अगदी उलट आहे: मॉडेलला ही संख्या सांगितली जाते आणि त्यानुसार एजंटचा लूप नियंत्रित केला जातो, परंतु "Task budgets हे केवळ एक सूचक असतात, सक्तीची मर्यादा नाही" आणि अंमलात येणारी मर्यादा अजूनही max_tokens हीच असते.

माझ्या एजंटसाठी cache_read_input_tokens नेहमी शून्य का असतात?

कारण प्रत्येक कॉलच्या दरम्यान प्रीफिक्स बदलतो किंवा तो कॅश करण्यासाठी खूप लहान असतो. याचे सामान्य कारण म्हणजे सिस्टम प्रॉम्प्टमध्ये समाविष्ट केलेला टाइमस्टॅम्प किंवा रन आयडी: कॅश हे प्रीफिक्सवर आधारित असते, त्यामुळे त्यातील एक बाइट बदलला तरी त्यानंतरचा सर्व डेटा अवैध ठरतो. टूल डेफिनिशन किंवा effort व्हॅल्यू बदलल्यास असेच घडते. अन्यथा, हे आकारावर अवलंबून असते, कारण लहान प्रॉम्प्ट कॅश केले जात नाहीत आणि त्यासाठी कोणतीही त्रुटी (error) दिली जात नाही.

AI एजंटला कायमस्वरूपी लूपमध्ये जाण्यापासून कसे थांबवू?

तुमच्या लूप कोडमध्ये इटरेशन्स मोजा आणि एका ठराविक कमाल मर्यादेवर थांबवा, कारण max_tokens हे एका प्रतिसादावर मर्यादा घालते आणि एजंट अनेक प्रतिसाद देतो. प्रक्रियेच्या बाहेर एक वेळेची मर्यादा (wall-clock limit) जोडा: जॉबला systemd टायमरद्वारे सुरू करा आणि त्यात RuntimeMaxSec= सेट करा, जेणेकरून अडकलेली रन वेळेनुसार बंद होईल. रिट्राय (retries) वरही मर्यादा घाला, कारण प्रत्येक रिट्राय लूपसाठी शुल्क आकारले जाते.

मी एका Claude API की (key) वर खर्चाची मर्यादा सेट करू शकतो का?

दस्तऐवजीकरणानुसार खर्चाची मर्यादा ही की (key) नुसार नसून वर्कस्पेस (workspace) नुसार असते, म्हणून एजंटला स्वतंत्र वर्कस्पेस द्या आणि तिथे मासिक खर्चाची मर्यादा सेट करा. "तुम्ही Default Workspace वर मर्यादा सेट करू शकत नाही". खर्चाच्या सूचना (spend notifications) जोडा जेणेकरून ठराविक मर्यादेवर पोहोचल्यावर तुम्हाला अलर्ट मिळेल. खर्चाच्या वर्गीकरणासाठी, प्रत्येक जॉबला स्वतःची की द्या आणि त्यानंतर group_by[]=api_key_id वापरून वापराचा अहवाल गटबद्ध करा.