VPS वर AI agent चा खर्च कसा थांबवायचा

नेहमी चालू असलेला AI agent खर्च वाढवण्यापासून कसा थांबवायचा

VPS (virtual private server) वर AI agent चा खर्च नियंत्रित करण्याचा अर्थ agent सुरू होण्यापूर्वी तुम्ही ठरवलेल्या मर्यादा आहेत, कारण agent चालू असताना कोणीही खर्चावर लक्ष ठेवत नाही. प्रत्येक प्रतिसाद max_tokens सह मर्यादित करा, तुमच्या स्वतःच्या कोडमधील loop पुनरावृत्तींना बंधिस्त करा, prompt मधील कधीही बदलणार नाही असा भाग cache करा, आणि प्रत्येक प्रतिसादाचे usage आकडे log करा जेणेकरून कोणत्या job मध्ये खर्च होत आहे हे दिसेल. सर्व्हर भाड्याची रक्कम दरमहा निश्चित आहे. model API चे आकारन प्रति token असते, आणि लक्ष न ठेवलेला loop शांतपणे token खर्च करण्यात अतिशय कुशल असतो.

हे agent आधीपासून अस्तित्वात असून तुमच्याच मालकीच्या box वरून Messages API ला कॉल करत असल्याची गृहीतके मांधते. VPS वर Claude सह AI agent तयार करणे हे यंत्रणा स्वतःच स्पष्ट करते.

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

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

वारंवारता हा गुणक आहे जो लोक विसरतात. पाच मिनिटांच्या शेड्यूलवर असलेले एक काम दिवसातून 288 वेळा आणि महिन्यातून सुमारे 8,640 वेळा चालते. एका रनचा जो कितीही खर्च असेल, तीच संख्या तुम्ही गुणाकार करता. अनेक "अल्वेज-ऑन" एजंटना सतत चालू असण्याची गरज नसते. त्यांना काही मिनिटांच्या आत उत्तर द्यायचे असते, हा एक शेड्यूल आहे.

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

• टूल व्याख्या प्रत्येक विनंतीसोबत पाठवल्या जातात. Claude Opus 4.8 वर auto किंवा none सह tool_choice असताना टूल-यूज सिस्टम प्रॉम्प्टचा 290 टोकन्सचा खर्च येतो, आणि any किंवा tool सह 410 टोकन्सचा. bash टूल त्यात 325 टोकन्स जोडते. तुम्ही जोडलेला प्रत्येक MCP सर्व्हर त्या वजनात आपले स्कीमा जोडते, MCP म्हणजे मॉडेल कॉन्टेक्स्ट प्रोटोकॉल.
• टूल परिणामे हे इनपुट टोकन्स असतात. 8,000 ओळी छापणारा एक कमांड पुढच्या विनंतीत 8,000 ओळी टाकतो, आणि त्या फेरीत त्यानंतरच्या प्रत्येक विनंतीतही.
• आणलेले पेज हे इनपुट टोकन्स असतात. सरासरी 10 kB वेब पेज सुमारे 2,500 टोकन्स असते आणि 500 kB संशोधन PDF सुमारे 125,000 टोकन्स. max_content_tokens फक्त मजकूरालाच छोटे करते, कारण ते "मजकूरावर लागू होते, PDF सारख्या बायनरी मजकूरावर नाही". त्याऐवजी max_uses आणि allowed_domains सह PDF ला मर्यादित करा.
• वेब शोध प्रति शोधाला किमतीने आकारला जातो, 1,000 शोधांसाठी $10, कितीही निकाल परत आले तरी. त्रुटी देणारा शोध बिल केला जात नाही.

एकदाच हे काहीही महाग नसते. 8,640 वेळा हे सर्व महाग असते.

कठोर मर्यादा आणि सौम्य मर्यादा वेगवेगळ्या समस्या सोडवतात

max_tokens लागू केले जाते. ही एका विनंतीच्या एकूण आउटपुटवरील कठोर मर्यादा आहे, ज्यामध्ये विचार आणि प्रतिसाद मजकूर एकत्र येतो. 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 सत्र हे सत्राच्या स्वच्छतेवर अवलंबून असते.

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

प्रति-काम मॉडेल निवड, आणि प्रयत्न प्रत्यक्षात काय बदलतो

मॉडेल निवड हा प्रति-काम निर्णय आहे. जुलै 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 सध्या त्याच्या जाहीर किमतीपेक्षा खाली आहे, कारण "दशलक्ष इनपुट/आउटपुट टोकन्सप्रमाणे $2/$10 ची परिचयात्मक किंमत 31 ऑगस्ट, 2026 पर्यंत लागू आहे". फक्त लॉग ओळींचे वर्गीकरण करणाऱ्या टप्प्याला Opus ची गरज नाही.

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

समस्या ही आहे की प्रयत्न कॅशशी संघर्ष करतो. विनंत्यांमध्ये मूल्य बदलल्यास प्रॉम्प्ट कॅशिंग रद्द होते. दस्तऐवजीकृत उदाहरणामध्ये, विनंती 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 टोकन बिल प्रत्यक्षात काय भरते मीटरचे विश्लेषण करते.

स्थिर प्रीफिक्स कॅशे करा, आणि तो नकळत खरडून टाकणे थांबवा

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

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

कॅशे नकळत गमावण्याच्या तीन वाटा.

बदलणारा प्रीफिक्स. "कॅशे प्रीफिक्स खालील क्रमाने तयार केले जातात: tools, system, नंतर messages." या क्रमात जर आधी कोणताही बायट बदलला, तर त्यानंतरचे सर्व काही रद्द होते, आणि टूल डेफिनिशन्समध्ये बदल केल्यास संपूर्ण कॅशे रद्द होते. सिस्टम प्रॉम्प्टमधील टाइमस्टॅम्प किंवा रन id हे याचे उत्तम स्वतःच केलेले नुकसान आहे: त्यानंतर प्रत्येक विनंती वेगळा प्रीफिक्स वाहून नेते, 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% दराने आकारला जातो", हे इनपुट आणि आउटपुट दोन्हीवर लागू होते. बॅच प्रक्रिया अतुल्यकालिक असते, "बहुतांश बॅच 1 तासापेक्षा कमी वेळात पूर्ण होतात", परिणाम तेव्हा मिळतात जेव्हा प्रत्येक विनंती पूर्ण होते किंवा 24 तासांनंतर, ज्यातूनही पहिले येईल ते. ही सामान्य वेळ आहे, हमी नाही.

processing_status ते ended वाचेपर्यंत त्याची चौकशी करत रहा. errored, canceled किंवा expired परत करणाऱ्या विनंत्यांचे बिलिंग होत नाही. तुम्ही खर्च मर्यादेवर अवलंबून असाल तर एक सूचना: "बॅच तुमच्या Workspace मध्ये सेट केलेल्या खर्च मर्यादेपेक्षा किंचित जास्त जाऊ शकतात."

सवलती एकत्र होतात, आणि बॅच पाच मिनिटांपेक्षा जास्त वेळ घेऊ शकतो म्हणून कागदपत्रे संदर्भ सामायिक करणाऱ्या बॅचसाठी एक-तासाच्या कॅशेची शिफारस करते. त्यामुळे काम विभाजित करा: व्यक्ती किंवा webhook ने ज्याची प्रतीक्षा करते ते लाइव्ह मार्गावर राहते, आणि दररोजचा सारांश किंवा कालचा लॉग वर्गीकरण अर्ध्या किमतीत बॅचमध्ये जाते.

प्रत्येक प्रतिसादाचे usage फील्ड तुमच्या स्वतःच्या स्टोअरमध्ये लॉग करा

तुम्ही जे कधीच रेकॉर्ड केले नाही, त्याचा खर्च तुम्ही आक्षेपार्ह करू शकत नाही. प्रत्येक प्रतिसाद तुम्हाला सांगतो की त्याची किंमत किती होती.

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 वर लक्ष ठेवा: शून्यांचा स्तंभ हा स्वतःच्या सर्व्हरवर चालवलेल्या एजंटमधील सर्वात सामान्य खर्चाचा दोष आहे.

एक फील्ड चुकीने वाचण्याची शक्यता असते. input_tokens फक्त शेवटच्या cache breakpoint नंतरचे tokens मोजते, म्हणून वास्तविक prompt आकार total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens असतो. मोठ्या promptवर input_tokens: 400 रिपोर्ट करणारा एजंट स्वस्त नसतो: बाकीचे cache मधून आले.

पाठवण्यापूर्वी मोजा. Token मोजणे मोफत असते आणि त्याचे rate limits message तयार करण्यापेक्षा वेगळे असतात, म्हणून अतिशय मोठे attachment शोधण्यासाठी पैसे देण्याऐवजी ते नाकारण्यासाठी count_tokens वापरा. हा परिणाम एक अंदाज आहे, म्हणून प्रति model पुन्हा मोजा आणि दुसऱ्या vendor च्या tokenizer मधील count कधीच पुन्हा वापरू नका. Claude Opus 4.7 आणि त्यानंतरचे Opus models, Claude Fable 5 आणि Claude Sonnet 5 एक नवीन tokenizer वापरतात जे "त्याच मजकुरासाठी अंदाजे 30% अधिक tokens तयार करते". Claude Sonnet 4.6 आणि त्यापूर्वीचे, त्यात Claude Haiku 4.5 समाविष्ट आहे, जुने tokenizer वापरतात.

अधिकृत मतासाठी, Admin API usage ची माहिती https://api.anthropic.com/v1/organizations/usage_report/messages वर आणि cost ची माहिती 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 सह प्रति key रिपोर्ट विभाजित करा. फिल्टर बहुवचनात आहे, गट करण्याचे माप एकवचनात आहे. कोडमध्ये न ठेवता environment मध्ये keys ठेवा, जसे VPS वरील पहिली Claude API ॲप त्यांना हाताळते.

लूपला मर्यादा द्या, कारण दुसऱ्या कोणत्याही गोष्टीत ते होणार नाही

येथे मर्यादित पुनरावृत्ती संख्या पर्यायी नाही. लूप तुमचा आहे, म्हणून काउंटर तुमचा आहे:

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 एका प्रतिसादाला मर्यादित करते, आणि मॉडेलला फक्त कार्य बजेटची माहिती दिली जाते.

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

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

AI एजंट खर्च नियंत्रण तुमच्याच संख्या वाचण्यापासून सुरू होते

कोणीही तुम्हाला सांगू शकत नाही की नेहमी-चालू असलेल्या एजंटची किंमत किती आहे, कारण हा खर्च प्रति-चालणी टोकन्स गुणिले प्रति-दिवस चालणी इतका असतो, आणि हे दोन्ही भाग तुमचे आहेत. ते एकदा चालवा, तुम्ही लॉग केलेली वापर पंक्ती वाचा, आणि तुमच्या वेळापत्रकाने गुणा करा. दोन दिवसांनी या अंकगणिताशी खर्च अहालाची तुलना करा. जेव्हा हे दोन एकमेकांशी जुळत नाहीत, तेव्हा हे अंतर जवळजवळ नेहमी एखादे खराब झालेले कॅशे किंवा तुम्ही धरल्यापेक्षा जास्त वेळ चाललेला लूप असतो.

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

FAQ

VPS वर नेहमी चालू असलेला AI agent चालवायला किती खर्च येतो?

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

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

max_tokens लागू केले जाते आणि ते मॉडेलला दिसत नाही. ते एका विनंतीचे आउटपुट, विचारांसह, मर्यादित करते आणि त्याला स्पर्श केल्यावर stop_reason: "max_tokens" मिळते. Task budget याच्या उलट आहे: मॉडेलला हा आकडा सांगितला जातो आणि ते agentic loop ला त्यानुसार गती देते, पण "Task budgets are a soft hint, not a hard cap" आणि लागू केलेली मर्यादा तरीही max_tokens आहे.

माझ्या agent साठी cache_read_input_tokens नेहमी शून्य का असते?

कारण कॉलमधील प्रीफिक्स बदलते, किंवा ते cache करण्यासाठी खूप लहान असते. सामान्य कारण म्हणजे सिस्टम प्रॉम्प्टमध्ये टाकलेला timestamp किंवा run id: cache प्रीफिक्सवर आधारित असते, म्हणून एक byte बदलल्यास त्यानंतरचे सर्व काही रद्द होते. Tool व्याख्या किंवा effort मूल्य बदलल्यासही तसेच होते. अन्यथा हे आकारामुळे असते, कारण लहान प्रॉम्प्ट cache होत नाहीत आणि कोणतीही त्रुटी परत केली जात नाही.

AI agent ला अनंत काळ लूप करण्यापासून कसे थांबवायचे?

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

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

दस्तऐवजीकृत खर्च मर्यादा प्रति workspace आहे ना की प्रति key, म्हणून agent ला स्वतःचे एक workspace द्या आणि तेथे त्याचा मासिक खर्च मर्यादित करा. "You cannot set limits on the Default Workspace". खर्च सूचना जोडा जेणेकरून एका थ्रेशोल्डवर तुम्हाला आधी सूचित केले जाईल. ओळखण्यासाठी, प्रत्येक जॉबला त्याची स्वतःची key द्या, मग वापर अहवालाला group_by[]=api_key_id सह गट करा.