Kudhibiti gharama za AI agent kwenye VPS

Jinsi ya kuzuia agent ya AI inayofanya kazi muda wote isiongeze gharama

Udhibiti wa gharama za agent ya AI kwenye VPS (virtual private server) unategemea viwango unavyoweka kabla ya agent kuanza, kwa sababu hakuna anayefuatilia matumizi wakati inafanya kazi. Weka kikomo cha max_tokens kwa kila jibu, weka mipaka ya mzunguko (loop iterations) kwenye kodi yako, hifadhi (cache) sehemu ya prompt isiyobadilika, na rekodi takwimu za matumizi ya kila jibu ili kuona kazi inayotumia zaidi. Renti ya server ni bei ya kudumu ya kila mwezi. API ya model inatozwa kwa token, na mzunguko usiofikiwa (unattended loop) una uwezo mkubwa wa kutumia token kwa siri.

Hii inahusisha agent ambayo tayari ipo na inaita Messages API kutoka kwenye kifaa unachomiliki. Kujenga AI agent kwa kutumia Claude kwenye VPS inaelezea mifumo yenyewe.

Kwa nini agent asiyefuatiliwa ana gharama tofauti

Kikao cha kibaashara kina binadamu. Modeli ikielekea njia isiyo sahihi au ikisoma log ya mistari 40,000, mtu anayetazama huizuia. Agent asiyefuatiliwa hana breki kama hiyo: huendelea kufanya kazi hadi mzunguko uishe, kisha kishika muda (timer) humuanzisha tena.

Masafa (frequency) ni kigezo ambacho watu hupuuza. Kazi yenye ratiba ya kila dakika tano hufanya kazi mara 288 kwa siku na takriban mara 8,640 kwa mwezi. Gharama ya mzunguko mmoja ndiyo namba unayopaswa kuzilipa mara kadhaa. Agent nyingi za "always-on" hazihitaji kuwa hewani wakati wote. Zinahitaji kujibu ndani ya dakika fulani, ambayo ni ratiba.

Agent pia hulipia vitu ambavyo dirisha la chat halilipii.

• Tool definitions huambatana na kila ombi. System prompt ya matumizi ya tool ina gharama ya token 290 kwenye Claude Opus 4.8 kwa tool_choice ya auto au none, na 410 kwa any au tool. Tool ya bash inaongeza 325 zaidi. Kila MCP server unayounganisha huongeza schema zake kwenye uzito huo; MCP ni model context protocol.
• Matokeo ya tool ni input tokens. Amri inayochapisha mistari 8,000 huweka mistari 8,000 kwenye ombi linalofuata, na kwenye kila ombi linalofuata katika mzunguko huo.
• Kurasa zilizopatikana ni input tokens. Ukurasa wa web wenye wastani wa 10 kB ni takriban token 2,500 na PDF ya utafiti ya 500 kB ni takriban 125,000. max_content_tokens hukata maandishi pekee, kwa sababu "inatumika kwenye maudhui ya maandishi, si kwenye maudhui ya binary kama PDFs". Badala yake, tumia max_uses na allowed_domains kwenye PDF.
• Web search inatozwa kwa kila utafutaji, kwa $10 kwa kila utafutaji 1,000, bila kujali matokeo mangapi yanayorudishwa. Utafutaji unaofeli haitozwi.

Hakuna kati ya hayo ambacho ni ghali kwa mara moja. Yote hayo ni ghali mara 8,640.

Hard ceilings na soft ceilings hutatua matatizo tofauti

max_tokens inatiliwa utekelezaji. Hii ni kikomo kigumu cha jumla ya matokeo ya ombi moja, ikijumuisha maandishi ya kufikiri na majibu. Claude haitengenezi zaidi ya kiwango hicho, na modeli haiwezi kuona namba hiyo. Kufikia kiwango hicho husababisha stop_reason: "max_tokens" na jibu lililokatwa. Changamoto kwa agent: kila ombi katika mzunguko wa matumizi ya zana hubeba max_tokens yake, hivyo hukata jibu moja badala ya kazi nzima. Simu kumi za zana za 4,000 ni kikomo cha 40,000-token kwa mzunguko huo.

Bajeti ya kazi ni ya kushauriwa. task_budget ipo ndani ya output_config na inaambia modeli idakaliwe tokeni ngapi kwa mzunguko mzima wa agent, ikijumuisha kufikiri, simu za zana, matokeo ya zana na matokeo ya mwisho.

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

"Bajeti za kazi ni ishara laini, si kikomo kigumu." Claude inaweza kuvuka moja katikati ya kitendo, na kikomo cha matokeo kinachotiliwa utekelezaji bado ni max_tokens. "Hesabu ya kinyume inaonekana na modeli pekee", na majibu hayana uwanja wa bajeti iliyobaki. task_budget.total ya chini inayokubalika ni tokeni 20,000, na chini ya hapo hutoa kosa la 400. Bajeti ndogo mno kwa kazi husababisha tabia inayofanana na kukataa, hivyo modeli hupunguza ukubwa wa kazi au kusimama mapema.

Kipengele kimoja kinagharimu pesa badala ya kuokoa. Ikiwa mteja wako anapunguza task_budget.remaining kwenye kila ombi linalofuata, thamani iliyobadilika hufuta prefix yoyote iliyohifadhiwa (cached) yenye thamani hiyo. Iweke mara moja, kwenye ombi la kwanza.

Bajeti za kazi zipo kwenye beta kwenye Claude Fable 5, Claude Opus 4.8 na Claude Opus 4.7. Claude Sonnet 5 na Claude Haiku 4.5 zimeorodheshwa kama Not supported, na bajeti za kazi hazitumiki kwenye Claude Code, hivyo Claude Code session detached in tmux inategemea usafi wa session.

Kikomo cha tatu kipo kwenye Claude Console: mpe agent workspace yake, kisha uweke kikomo cha matumizi ya kila mwezi na vikomo vya kasi kwa kila dakika. "Hauwezi kuweka vikomo kwenye Default Workspace", na "Vikomo vya shirika (Organization-wide) vinatumika kila wakati, hata kama vikomo vya workspace vinajumlisha zaidi". Ongeza arifa za matumizi ili kilele kikupe taarifa kabla ya kikomo kufika.

Uchaguzi wa modeli kwa kila kazi, na juhudi zinazobadilika

Uchaguzi wa modeli ni uamuzi wa kila kazi. Kufikia Julai 2026, kwa kila milioni ya tokens, ingizo kisha toleo: Claude Fable 5 ni $10 na $50, Claude Opus 4.8 na Opus 4.7 ni $5 na $25, Claude Sonnet 5 ni $3 na $15, Claude Haiku 4.5 ni $1 na $5. Sonnet 5 iko chini ya bei yake ya sasa kwa sasa, kwa sababu "Bei ya utangulizi ya $2/$10 kwa kila milioni ya tokens za ingizo/toleo inatumika hadi Agosti 31, 2026". Hatua inayopanga mistari ya log pekee haihitaji Opus.

Juhudi ni lever ya pili. output_config.effort inakubali low, medium, high, xhigh na max, na chaguo la kawaida ni high, hivyo kuweka high wazi ni sawa na kutoiweka. Juhudi ndogo inapunguza zaidi ya urefu wa ufikiri: hati inasema inamfanya Claude afanye idadi ndogo ya tool calls na kuunganisha operesheni kuwa moja. Kwa agent, hili ni uokozi mkubwa zaidi, kwa sababu tool call iliyoepukwa ni ombi lote ambalo halitafanyika.

Mtego ni kwamba juhudi zinapingana na cache. Kubadilisha thamani kati ya maombi inafuta prompt caching. Katika mfano uliowekwa, ombi la 2 liliripoti cache_read_input_tokens: 3546; ombi la 3, likiwa na juhudi iliyobadilishwa kutoka high kwenda medium, liliripoti cache_creation_input_tokens ya 3546 na cache_read_input_tokens ya 0. Kwa hivyo badilisha juhudi kwenye mizigo ya kazi tofauti, usifanye hivyo ndani ya mazungumzo moja yaliyohifadhiwa (cached). Ili kuongoza kina bila kuvunja cache, fanya hivyo kwenye prompt: mstari kama "Jibu moja kwa moja bila kutafakari" kwenye ujumbe mpya wa mtumiaji huacha sehemu za awali (breakpoints) bila kubadilika.

Thinking tokens hutozwa kwa viwango vya toleo na huhesabiwa dhidi ya max_tokens, ndiyo maana jibu fupi mara nyingi inamaanisha ufikiri umeitumia bajeti. Soma usage.output_tokens_details.thinking_tokens kwa namba hiyo. Nini hasa kinajaza bili ya token ya Claude kinaelezea mchakato huo kwa kina.

Hifadhi prefix ya stable, na usiharibu kwa bahati mbaya

Gharama ya kuandika kwenye cache ni mara 1.25 ya bei ya msingi kwenye cache ya dakika tano, na mara 2 kwenye cache ya saa moja. Kusoma kwenye cache kuna gharama ya mara 0.1, hivyo "caching inafaa baada ya kusoma cache mara moja tu kwa muda wa dakika 5 (1.25x write), au baada ya kusoma cache mara mbili kwa muda wa saa 1 (2x write)".

Mstari mmoja unaelezea kwa nini hii inafaa kwa agent anayefanya kazi muda wote: "Cache inafanyiwa upya bila gharama ya ziada kila wakati maudhui yaliyohifadhiwa yanapotumika." Kazi inayofanya kazi kila baada ya dakika mbili dhidi ya cache ya dakika tano huweka prefix yake ikiwa imepata joto mchana kutwa kwa kuandika mara moja tu.

Njia tatu za kupoteza cache bila kugundua.

Prefix inayobadilika. "Cache prefixes huundwa kwa mpangilio ufuatao: tools, system, kisha messages." Mabadiliko yoyote ya byte mapema katika mpangilio huo yanafuta kila kitu kinachofuata, na kuhariri maelezo ya zana (tool definitions) kunafuta cache nzima. Kosa la kawaida linalojitokeza ni timestamp au run id kwenye system prompt: kila ombi kisha hubeba prefix tofauti, huandika ingizo jipya kwa gharama ya 1.25x, na haisomi kitu. Dalili ni usage.cache_read_input_tokens ikiwa ni 0 kwenye simu zinazofanana. Hamisha maandishi yanayobadilika kwenda kwenye ujumbe mpya wa mtumiaji.

Prefix fupi mno. Kila model ina urefu wa chini unaoweza kuhifadhiwa, na chini ya urefu huo ombi linashughulikiwa bila caching na "hakuna kosa linalorudishwa". Takwimu zinajumuisha 1,024 tokens kwenye Claude Opus 4.8 na Claude Sonnet 5, na 4,096 kwenye Claude Haiku 4.5, hivyo kuhamisha kazi kutoka Sonnet kwenda Haiku kunaweza kuzima caching kimya kimya.

Mazungumzo yanayozidi urefu wa lookback. "Lookback window ni blocks 20." Mfumo unakagua hadi nafasi 20 kwa kila breakpoint, kisha unasimama. Katika mfano uliowekwa, zamu inayoshikilia blocks 35 ikiwa na breakpoint kwenye block 35 hukagua blocks 35 hadi 16, na ingizo la zamu iliyotangulia kwenye block 15 linatoka nje ya window, hivyo hakuna hit. Agent anayeongeza blocks kadhaa za tool-use na tool-result kwa kila zamu hufikia zaidi ya 20 ndani ya zamu mbili au tatu. Unapata breakpoints nne kwa kila ombi, hivyo tumia moja kwa ujumbe wa hivi karibuni.

Tuma vitu vyote vinavyoweza kusubiri kwenye Batches API

"Matumizi yote yanatozwa 50% ya bei ya kawaida ya API", kwa input na output. Usindikaji wa batch ni asynchronous, "karibu batch nyingi hukamilika ndani ya saa 1", matokeo yanapatikana kila ombi linapokamilika au baada ya saa 24, kulingana na lipo mapema. Hii ni hali ya kawaida, siyo uhakika.

Kagua processing_status hadi isome ended. Maombi yanayorudisha errored, canceled au expired hayatozwi. Angalizo moja ikiwa unatumia kikomo cha matumizi (spend cap): "batch zinaweza kuzidi kidogo kikomo cha matumizi kilichosanidiwa kwenye Workspace yako."

Punguzo la bei huongezeka, na kwa sababu batch inaweza kuchukua zaidi ya dakika tano, hati inayozingatia (documentation) inapendekeza kutumia cache ya saa moja kwa batch zinazoshiriki context moja. Hivyo gawanya kazi: kitu chochote ambacho mtu au webhook kinasubiri kikae kwenye njia ya moja kwa moja (live path), na muhtasari wa usiku au uainishaji wa logi za jana iwekwe kwenye batch kwa bei ya nusu.

Log kila sehemu ya matumizi ya jibu kwenye hifadhi yako

Huwezi kuainisha gharama ambayo haukuirekodi. Kila jibu linakuambia gharama yake.

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

Ongeza mstari mmoja kwa kila mwito wa API kwenye faili ya JSON-lines, ukiwa umeandikwa kwa jina la kazi yako. Wiki moja baadaye unaweza kujua kazi gani inadumisha matumizi na gani ilionekana kuwa na shughuli nyingi tu. Angalia cache_read: safu ya sifuri ndiyo hitilafu ya gharama inayojitokeza zaidi kwenye agent anayeojiendesha (self-hosted).

Sehemu moja ni rahisi kusomwa vibaya. input_tokens inahesabu tokeni baada ya breakpoint ya mwisho ya cache, hivyo ukubwa halisi wa prompt ni total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens. Agent anayetoa input_tokens: 400 kwenye prompt kubwa si rahisi: sehemu nyingine ilitokana na cache.

Hesabu kabla ya kutuma. Kuhesabu tokeni ni bure na mipaka yake ya kiwango (rate limits) ni tofauti na utengenezaji wa ujumbe, hivyo tumia count_tokens kukataa kiambatisho kilichozidi ukubwa badala ya kulipia kukigundua. Matokeo ni makadirio, hivyo pima tena kwa kila model na usitumie hesabu kutoka kwa tokenizer ya vendor mwingine. Claude Opus 4.7 na model za Opus za baadaye, Claude Fable 5 na Claude Sonnet 5 zinatumia tokenizer mpya ambayo "inazalisha takriban tokeni 30% zaidi kwa maandishi yaleyo". Claude Sonnet 4.6 na za mapema, ikiwemo Claude Haiku 4.5, zinatumia ile ya awali.

Kwa maelezo rasmi, Admin API inatoa ripoti ya matumizi kwenye https://api.anthropic.com/v1/organizations/usage_report/messages na gharama kwenye https://api.anthropic.com/v1/organizations/cost_report. Zote zinahitaji admin key (sk-ant-admin01-...) kama x-api-key: $ANTHROPIC_ADMIN_KEY pamoja na anthropic-version: 2023-06-01, na zinakubali bucket_width=1d, group_by[]=model na api_key_ids[]=. Kikomo kimoja: "Admin API haipatikani kwa akaunti binafsi."

Parameter hiyo ya mwisho ni mbinu rahisi ya kuainisha: toa kila kazi API key yake, tumia api_key_ids[] kama kichujio, na gawanya ripoti kwa kila key kwa kutumia group_by[]=api_key_id. Kichujio ni cha wingi, lakini kigezo cha uunganishaji (grouping dimension) ni cha umoja. Weka keys kwenye mazingira (environment) badala ya kwenye kodi, kama app ya kwanza ya Claude API kwenye VPS inavyofanya.

Weka kikomo kwenye loop, kwa sababu hakuna kingine kitafanya hivyo

Idadi ya marudio iliyowekewa kikomo ni ya lazima hapa. Loop ni yako, hivyo kigezo cha kuhesabu (counter) ni chako:

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)

Hakuna kikomo kilichotajwa hapo juu kinachokufanyia kazi hiyo: max_tokens huweka kikomo kwenye jibu moja, na modeli hupewa tu bajeti ya kazi.

Weka kikomo cha pili nje ya mchakato. Run kazi hiyo kwa kutumia systemd timer badala ya mchakato wa kudumu, na uweke RuntimeMaxSec= kwenye unit ya huduma yake. Kwa kutumia RuntimeMaxSec=600, kazi iliyokwama itakatwa baada ya dakika kumi badala ya kuendelea kuendesha hadi utagundua. Kuendesha programu kama systemd service na timer inaelezea faili za unit. Soma matokeo ya kazi kwa kutumia journalctl -u triage-agent.service --since "1 hour ago".

Weka kikomo kwenye majaribio ya marudio (retries) pia, kwa sababu mshughulikiaji (handler) unaojaribu mara nyingi bila mwisho utatumia gharama katika kila jaribio. Hitilafu ya 429 au 500 inastahili majaribio machache yenye backoff. Hitilafu ya 400 haistahili majaribio yoyote, kwa sababu ombi lilelile litashindwa kwa njia ileile.

Udhibiti wa gharama za AI agent huanza kwa kusoma takwimu zako

Hakuna mtu anayeweza kukuambia gharama ya agent inayofanya kazi muda wote. Hii ni kwa sababu gharama ni tokens kwa kila run kaliwa na idadi ya run kwa siku, na pande zote mbili ni zako. Irun mara moja, soma mstari wa matumizi uliorekodiwa, na uzidishishe kwa ratiba yako. Linganisha ripoti ya gharama baada ya siku mbili na hesabu hiyo. Ikiwa matokeo hayatafanana, tofauti hiyo mara nyingi husababishwa na cache iliyoharibika au loop iliyojiendesha kwa muda mrefu kuliko ulivyodhania.

Hii inafanya kazi kwa kutumia API key, kwa sababu agent ni programu yako inayopiga simu kwenye Messages API. Kwa kazi zako za kawaida, mpango wa Claude unaoendana na namna unavyofanya kazi unaelezea upande wa usajili. Kila bei na kikomo hapa kililinganishwa na nyaraka za Anthropic mnamo Julai 2026, hivyo usome tena ukurasa wa bei kabla ya kuandaa bajeti.

FAQ

Gharama ya kuendesha AI agent inayofanya kazi muda wote kwenye VPS ni kiasi gani?

Kuna bili mbili na moja tu ndiyo inayotabirika. Server ina bei ya kudumu ya kila mwezi. Model API inatozwa kwa kila token, hivyo gharama ni kile kinachotumika kwenye mwendo mmoja multiplied na mara nyingi inavyofanya kazi. Anthropic haitoi takwimu kwa agent inayojiendesha inayofanya kazi muda wote, hivyo chukulia namba yoyote inayotolewa kama makadirio. Log usage kutoka mwendo mmoja halisi na uzidishie ratiba yako.

Tofauti kati ya max_tokens na task budget ni ipi?

max_tokens inatiliwa utekelezaji na haionekani na model. Inazuia matokeo ya ombi moja, ikiwemo fikra, na kuifikia inatoa stop_reason: "max_tokens". Task budget ni kinyume chake: model inaambiwa namba hiyo na inapanga mzunguko wa agent kulingana nayo, lakini "Task budgets are a soft hint, not a hard cap" na kikomo kinachotiliwa utekelezaji bado ni max_tokens.

Kwa nini cache_read_input_tokens huwa zero kila wakati kwa agent yangu?

Kwa sababu prefix hubadilika kati ya simu, au ni fupi mno kuhifadhi kwenye cache. Sababu ya kawaida ni timestamp au run id inayowekwa kwenye system prompt: cache imefungwa kwenye prefix, hivyo mabadiliko ya byte yoyote yanafuta kila kitu baada yake. Kubadilisha tool definitions au thamani ya effort hufanya hivyo hivyo. Vinginevyo ni ukubwa, kwa sababu prompts fupi hazihifadhiwi kwenye cache na hakuna kosa linalorudishwa.

Ninawezaje kuizuia AI agent isizunguke (looping) milele?

Hesabu iterations kwenye kodi yako ya loop na usimame kwenye kiwango cha juu kilichopangwa, kwa sababu max_tokens inazuia jibu moja na agent hufanya majibu mengi. Ongeza kikomo cha muda (wall-clock limit) nje ya mchakato: anza kazi kutoka kwenye systemd timer ikiwa RuntimeMaxSec= imewekwa, ili mwendo uliokwama ufe kulingana na ratiba. Weka kikomo cha majaribio (retries) pia, kwa sababu mzunguko wa majaribio unatoza kila jaribio.

Je, naweza kuweka kikomo cha matumizi kwenye Claude API key moja?

Kikomo cha matumizi kilichowekwa ni kwa kila workspace badala ya kila key, hivyo mpe agent workspace yake mwenyewe na uweke kikomo cha matumizi yake ya kila mwezi hapo. "You cannot set limits on the Default Workspace". Ongeza taarifa za matumizi ili kiwango fulani kikupe taarifa mapema. Kwa ajili ya utambulisho, toa kila kazi key yake, kisha uunganishe ripoti ya matumizi kwa group_by[]=api_key_id.