Jinsi ya kuzuia gharama za wakala wa AI kwenye VPS

Jinsi ya kuzuia wakala wa AI anayefanya kazi kila wakati asisababishe gharama kubwa

Udhibiti wa gharama za wakala wa AI kwenye VPS (virtual private server) unahusu mipaka unayoweka kabla ya wakala kuanza, kwa sababu hakuna mtu anayefuatilia matumizi wakati unaendelea. Punguza kila jibu kwa max_tokens, weka ukomo wa marudio ya loop katika msimbo wako mwenyewe, hifadhi kwenye cache sehemu ya prompt isiyobadilika, na uweke kumbukumbu (log) ya idadi ya token zilizotumika kwa kila jibu ili kuona ni kazi ipi inayotumia gharama. Kodi ya seva ni bei isiyobadilika kila mwezi. API ya modeli hutoza kulingana na idadi ya token, na loop isiyosimamiwa ina uwezo mkubwa wa kutumia token kimya kimya.

Hii inachukulia kuwa wakala tayari yupo na anaita Messages API kutoka kwenye seva unayomiliki. Kujenga wakala wa AI kwa kutumia Claude kwenye VPS inashughulikia mfumo wenyewe.

Kwa nini wakala asiye na msimamizi ana muundo tofauti wa gharama

Kikao cha maingiliano kina binadamu ndani yake. Wakati modeli inapopotea njia au kusoma logi ya mistari 40,000, mtu anayeitazama huizuia. Wakala asiye na msimamizi hana breki kama hiyo: huendelea kufanya kazi hadi kitanzi kimalizike, kisha kipima muda huianzisha tena.

Mzunguko ndio kizio ambacho watu hukosa kukiona. Kazi inayopangwa kila dakika tano huendeshwa mara 288 kwa siku na takriban mara 8,640 kwa mwezi. Gharama ya kila uendeshaji mmoja ndiyo namba unayopaswa kuzidisha. Wakala wengi wa "always-on" hawahitaji kuwa hai muda wote. Wanahitaji tu kujibu ndani ya dakika kadhaa, jambo ambalo ni ratiba.

Wakala pia hulipia vitu ambavyo dirisha la gumzo halilipii.

• Ufafanuzi wa zana huambatana na kila ombi. Prompt ya mfumo wa matumizi ya zana hugharimu token 290 kwenye Claude Opus 4.8 ikiwa na tool_choice ya auto au none, na 410 ikiwa na any au tool. Zana ya bash huongeza 325 zaidi. Kila seva ya MCP unayounganisha huongeza schema zake kwenye uzito huo, ambapo MCP ni model context protocol.
• Matokeo ya zana ni token za pembejeo. Amri inayochapisha mistari 8,000 huweka mistari 8,000 kwenye ombi linalofuata, na kwenye kila ombi baada ya hapo katika zamu hiyo.
• Kurasa zilizorejeshwa ni token za pembejeo. Ukurasa wa wavuti wa 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 kwa maudhui ya maandishi, si kwa maudhui ya binary kama vile PDF". Punguza PDF kwa kutumia max_uses na allowed_domains badala yake.
• Utafutaji wa wavuti hutoza bei kwa kila utafutaji, kwa $10 kwa kila utafutaji 1,000, bila kujali matokeo mangapi yanayorejeshwa. Utafutaji unaopata hitilafu hautozwi.

Hakuna kati ya hayo yaliyo ghali yakifanyika mara moja. Yote huwa ghali yakifanyika mara 8,640.

Vikomo vya juu na vikomo vya chini hutatua matatizo tofauti

max_tokens hutekelezwa. Hiki ni kikomo cha juu cha jumla ya matokeo ya ombi moja, ikijumuisha maandishi ya kufikiri na ya majibu. Claude hawezi kuzalisha maandishi zaidi ya hapo, na modeli haiwezi kuona namba hiyo. Kufikia kikomo hiki husababisha stop_reason: "max_tokens" na jibu kukatwa. Changamoto kwa mawakala: kila ombi katika mzunguko wa matumizi ya zana hubeba max_tokens yake yenyewe, kwa hivyo inazuia jibu moja na si kazi nzima. Miito kumi ya zana kwa 4,000 ni kikomo cha token 40,000 kwa kila hatua.

Bajeti ya kazi ni ushauri. task_budget iko ndani ya output_config na huiambia modeli ni token ngapi inazo kwa mzunguko mzima wa wakala, ikijumuisha kufikiri, miito ya 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 dokezo la upole, si kikomo cha juu." Claude anaweza kuzidi bajeti katikati ya hatua, na kikomo kilichotekelezwa cha matokeo bado ni max_tokens. "Hesabu ya kurudi nyuma inaonekana kwa modeli pekee", na majibu hayabebi sehemu ya bajeti iliyobaki. task_budget.total ya chini kabisa inayokubalika ni token 20,000, na kiasi kidogo kuliko hicho hurejesha hitilafu ya 400. Bajeti ndogo sana kwa kazi husika husababisha tabia ya kukataa, kwa hivyo modeli hupunguza wigo wa kazi au kusimama mapema.

Maelezo moja hugharimu pesa badala ya kuokoa. Ikiwa mteja wako anapunguza task_budget.remaining kwenye kila ombi la ufuatiliaji, thamani iliyobadilishwa hubatilisha kiambishi awali chochote kilichohifadhiwa (cached prefix) kinachoiweka. Iweke mara moja, kwenye ombi la kwanza.

Bajeti za kazi ziko katika hatua ya 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 kwa Claude Code, kwa hivyo kikao cha Claude Code kilichotenganishwa katika tmux hutegemea usafi wa kikao badala yake.

Kikomo cha tatu kiko katika Claude Console: mpe wakala nafasi yake ya kazi, kisha weka kikomo cha matumizi ya kila mwezi na vikomo vya viwango kwa kila dakika juu yake. "Huwezi kuweka vikomo kwenye Default Workspace", na "Vikomo vya shirika zima hutumika kila wakati, hata kama vikomo vya nafasi ya kazi vikijumlishwa vitazidi". Ongeza arifa za matumizi ili kizingiti kikuonye kabla ya kikomo kufikiwa.

Uchaguzi wa modeli kwa kila kazi, na nini kinabadilisha gharama

Uchaguzi wa modeli ni uamuzi unaofanywa kwa kila kazi. Kufikia Julai 2026, kwa kila token milioni moja, input ikifuatiwa na output: Claude Fable 5 kwa $10 na $50, Claude Opus 4.8 na Opus 4.7 kwa $5 na $25, Claude Sonnet 5 kwa $3 na $15, Claude Haiku 4.5 kwa $1 na $5. Sonnet 5 inauzwa chini ya bei yake rasmi kwa sasa, kwa sababu "Bei ya utangulizi ya $2/$10 kwa kila token milioni moja za input/output inatumika hadi Agosti 31, 2026". Hatua inayofanya kazi ya kuainisha mistari ya logi pekee haihitaji Opus. Hakuna posho ya bure ya kufidia ratiba yenye shughuli nyingi, kwa sababu Claude API haina tier ya bure zaidi ya mkopo mdogo unaotolewa wakati wa kujisajili.

Juhudi (effort) ndiyo lever ya pili. output_config.effort inakubali low, medium, high, xhigh na max, na chaguo-msingi ni high, kwa hivyo kuweka high kwa uwazi ni sawa na kutoiweka kabisa. Juhudi ndogo hupunguza zaidi ya urefu wa kufikiri: nyaraka zinasema inafanya Claude kutumia wito wa zana (tool calls) wachache na kuchanganya operesheni kuwa moja. Kwenye wakala (agent), hii ndiyo akiba kubwa zaidi, kwa sababu wito wa zana unaozuiwa ni ombi zima ambalo halifanyiki kamwe.

Mtego ni kwamba juhudi hupingana na cache. Kubadilisha thamani kati ya maombi kunabatilisha prompt caching. Katika mfano uliowekwa kwenye nyaraka, ombi la 2 liliripoti cache_read_input_tokens: 3546; ombi la 3, likiwa na juhudi iliyobadilishwa kutoka juu kwenda wastani, liliripoti cache_creation_input_tokens ya 3546 na cache_read_input_tokens ya 0. Kwa hivyo, badilisha juhudi kulingana na mzigo wa kazi, usibadilishe kamwe ndani ya mazungumzo yaliyohifadhiwa kwenye cache. Ili kuongoza kina cha majibu bila kuvunja cache, fanya hivyo kwenye prompt: mstari kama "Jibu moja kwa moja bila kutafakari." kwenye ujumbe mpya zaidi wa mtumiaji huacha sehemu za awali za cache zikiwa salama.

Token za kufikiri (thinking tokens) hutoza kwa viwango vya output na huhesabiwa dhidi ya max_tokens, ndiyo maana jibu lililokatwa mara nyingi humaanisha kuwa kufikiri kumemaliza bajeti. Soma usage.output_tokens_details.thinking_tokens kwa namba husika. Nini hasa kinachojaza bili ya token ya Claude huchambua mita hiyo kwa kina.

Hifadhi prefix thabiti kwenye cache, na uache kuivunja bila kukusudia

Uandishi wa cache unagharimu mara 1.25 ya bei ya msingi ya input kwenye cache ya dakika tano na mara 2 kwenye cache ya saa moja. Usomaji wa cache unagharimu mara 0.1, kwa hivyo "kuhifadhi kwenye cache kunalipa baada ya usomaji mmoja tu kwa muda wa dakika 5 (1.25x ya uandishi), au baada ya usomaji miwili kwa muda wa saa 1 (2x ya uandishi)".

Mstari mmoja unaeleza kwa nini hii inafaa wakala anayefanya kazi kila wakati: "Cache inaburudishwa bila gharama ya ziada kila wakati maudhui yaliyohifadhiwa yanapotumiwa." Kazi inayotekelezwa kila baada ya dakika mbili dhidi ya cache ya dakika tano huweka prefix yake ikiwa hai siku nzima kwa uandishi mmoja tu.

Njia tatu za kupoteza cache bila kutambua.

Prefix inayobadilika. "Prefix za cache huundwa kwa mpangilio ufuatao: tools, system, kisha messages." Mabadiliko yoyote ya byte mapema katika mpangilio huo hubatilisha kila kitu kinachofuata, na kuhariri ufafanuzi wa zana hubatilisha cache nzima. Kosa la kawaida la kujisababishia ni kuweka timestamp au run id kwenye system prompt: kila ombi basi hubeba prefix tofauti, huandika entry mpya kwa 1.25x, na haisomi chochote. Ishara ya hili ni usage.cache_read_input_tokens kuwa 0 kwenye wito unaoonekana kufanana. Hamisha maandishi yanayobadilika-badilika kwenye ujumbe mpya zaidi wa mtumiaji.

Prefix ambayo ni fupi mno. Kila model ina urefu wa chini kabisa unaoweza kuhifadhiwa kwenye cache, na chini ya hapo ombi huchakatwa bila kutumia cache na "hakuna error inayorejeshwa". Takwimu hizi ni pamoja na token 1,024 kwenye Claude Opus 4.8 na Claude Sonnet 5, na 4,096 kwenye Claude Haiku 4.5, kwa hivyo kuhamisha kazi kutoka Sonnet kwenda Haiku kunaweza kuzima cache kimyakimya.

Mazungumzo yanayozidi uwezo wa lookback. "Dirisha la lookback ni block 20." Mfumo hukagua angalau nafasi 20 kwa kila breakpoint, kisha huacha. Katika mfano uliotolewa, zamu yenye block 35 ikiwa na breakpoint kwenye block 35 hukagua block 35 hadi 16, na entry ya zamu iliyotangulia kwenye block 15 huanguka nje ya dirisha, kwa hivyo hakuna hit. Wakala anayeongeza block kadhaa za matumizi ya zana na matokeo ya zana kwa kila zamu huvuka 20 katika zamu mbili au tatu. Unapata breakpoint nne kwa kila ombi, kwa hivyo tumia moja kwenye ujumbe wa hivi karibuni.

Tuma kazi yoyote inayoweza kusubiri kwenye Batches API

"Matumizi yote yanatozwa kwa 50% ya bei za kawaida za API", kwa data ya kuingiza na ya kutoa. Uchakataji wa batch ni wa asynchronous, "huku batch nyingi zikimalizika ndani ya chini ya saa 1", na matokeo hupatikana kila ombi linapokamilika au baada ya saa 24, kulingana na kipi kitatangulia. Hiyo ni hali ya kawaida, siyo ahadi ya uhakika.

Fuatilia processing_status hadi usome ended. Maombi yanayorejesha errored, canceled au expired hayatozwi ada. Tahadhari moja ikiwa unategemea kikomo cha matumizi (spend cap): "batch zinaweza kuzidi kidogo kikomo cha matumizi kilichowekwa kwenye Workspace yako."

Punguzo hizi hujumlishwa, na kwa sababu batch inaweza kuchukua muda mrefu zaidi ya dakika tano, nyaraka zinapendekeza cache ya saa moja kwa batch zinazoshiriki muktadha (context). Kwa hivyo gawanya kazi: chochote ambacho mtu au webhook inasubiri kinapaswa kubaki kwenye njia ya moja kwa moja (live path), na muhtasari wa usiku au uainishaji wa logi za jana uingizwe kwenye batch kwa nusu bei.

Hifadhi sehemu za matumizi ya kila jibu kwenye hifadhi yako binafsi

Huwezi kufuatilia gharama ambazo hukuzirekodi. Kila jibu hukuambia 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 safu moja kwa kila API call kwenye faili ya JSON-lines, ukiweka tag ya jina la kazi yako. Baada ya wiki moja, utaweza kusema ni kazi ipi inayotumia gharama na ipi inayotumia muda bure. Fuatilia cache_read: safu ya sufuri ndiyo hitilafu ya kawaida ya gharama katika wakala (agent) unayojiendeshea mwenyewe.

Kuna sehemu moja ambayo ni rahisi kuisoma vibaya. input_tokens huhesabu tokeni baada ya cache breakpoint ya mwisho pekee, kwa hivyo ukubwa halisi wa prompt ni total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens. Wakala anayeripoti input_tokens: 400 kwenye prompt kubwa si wa bei nafuu: sehemu iliyobaki ilitoka kwenye cache.

Hesabu kabla ya kutuma. Kuhesabu tokeni ni bure na mipaka yake ya kiwango (rate limits) ni tofauti na ile ya kutengeneza ujumbe, kwa hivyo tumia count_tokens kukataa kiambatisho kikubwa badala ya kulipia ili kugundua kuwa ni kikubwa. Matokeo ni makadirio, kwa hivyo pima upya kwa kila model na usiwahi kutumia hesabu kutoka kwa tokenizer ya muuzaji mwingine. Claude Opus 4.7 na model za Opus za baadaye, Claude Fable 5 na Claude Sonnet 5 hutumia tokenizer mpya ambayo "hutoa takriban 30% ya tokeni zaidi kwa maandishi yaleyale". Claude Sonnet 4.6 na za awali, zikiwemo Claude Haiku 4.5, hutumia ile ya awali.

Kwa mtazamo rasmi, Admin API huripoti matumizi kwenye https://api.anthropic.com/v1/organizations/usage_report/messages na gharama kwenye https://api.anthropic.com/v1/organizations/cost_report. Zote huhitaji admin key (sk-ant-admin01-...) kama x-api-key: $ANTHROPIC_ADMIN_KEY yenye anthropic-version: 2023-06-01, na hukubali bucket_width=1d, group_by[]=model na api_key_ids[]=. Kikwazo kimoja: "Admin API haipatikani kwa akaunti za watu binafsi."

Kigezo hicho cha mwisho ni mbinu rahisi ya ugawaji gharama: ipe kila kazi API key yake yenyewe, chuja kwa kutumia api_key_ids[], na ugawanye ripoti kulingana na key kwa kutumia group_by[]=api_key_id. Kichujio ni cha wingi, na kigezo cha kupanga ni cha umoja. Hifadhi key kwenye mazingira (environment) badala ya kwenye msimbo, kama vile programu ya kwanza ya Claude API kwenye VPS inavyozishughulikia.

Weka kikomo kwenye mzunguko, kwa sababu hakuna kingine kitakachofanya hivyo

Idadi ya mizunguko iliyowekewa kikomo si ya hiari hapa. Mzunguko ni wako, kwa hivyo kaunta ni yako:

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 cha juu kinachokufanyia kazi hiyo: max_tokens hupunguza jibu moja tu, na modeli hupewa tu ushauri kuhusu bajeti ya kazi. Bidhaa inayohudumiwa ingekusimamisha hapa, kama vile kikomo cha Claude kwenye wito wa zana ndani ya zamu moja inavyositisha kipindi kilichofanya wito mwingi, lakini mzunguko uliouandika wewe mwenyewe hauji na kinga hiyo hadi utakapoiweka.

Weka breki ya pili nje ya mchakato. Endesha kazi kutoka kwa systemd timer badala ya mchakato wa kudumu, na uweke RuntimeMaxSec= kwenye kitengo chake cha huduma. Kwa RuntimeMaxSec=600, mchakato uliokwama huuwawa baada ya dakika kumi badala ya kuendelea kuzunguka hadi utakapogundua. Kuendesha programu kama huduma na timer ya systemd inashughulikia faili za kitengo zenyewe. Soma kile ambacho mchakato ulifanya kwa journalctl -u triage-agent.service --since "1 hour ago".

Weka kikomo kwenye majaribio ya kurudia pia, kwa sababu kishughulikiaji kinachorudia milele hutoza kila jaribio. Hitilafu ya 429 au 500 inastahili majaribio machache yenye backoff. Hitilafu ya 400 haistahili jaribio lolote, kwa sababu ombi lilelile litashindwa kwa njia ileile.

Udhibiti wa gharama za AI agent huanza kwa kusoma takwimu zako mwenyewe

Hakuna mtu anayeweza kukuambia gharama ya agent anayefanya kazi muda wote, kwa sababu gharama hiyo ni idadi ya tokens kwa kila mzunguko ikizidishwa na idadi ya mizunguko kwa siku, na sehemu zote mbili ni zako. Iendeshe mara moja, soma mstari wa matumizi uliouhifadhi kwenye log, kisha uzidishe kwa ratiba yako. Linganisha ripoti ya gharama baada ya siku mbili na hesabu hiyo. Pale ambapo takwimu hizo mbili hazilingani, pengo hilo karibu kila mara husababishwa na cache iliyoharibika au loop iliyoendelea kwa muda mrefu kuliko ulivyodhani.

Hii inachukulia kuwa unatumia API key, kwa sababu agent huyo ni programu yako mwenyewe inayopiga simu kwenye Messages API. Kwa kazi zako za maingiliano, mpango upi wa Claude unaofaa namna unavyofanya kazi inashughulikia upande wa usajili. Kila bei na kikomo hapa kilikaguliwa dhidi ya nyaraka za Anthropic mnamo Julai 2026, kwa hivyo soma upya ukurasa wa bei kabla ya kuandaa bajeti.

FAQ

Je, gharama ya kuendesha AI agent inayofanya kazi muda wote kwenye VPS ni kiasi gani?

Kuna bili mbili na moja tu ndiyo inayotabirika. Seva ina bei isiyobadilika ya kila mwezi. API ya model hupimwa kwa token, kwa hivyo gharama ni kiasi kinachotumiwa na mzunguko mmoja kikizidishwa na mara ngapi inafanya kazi. Anthropic haitoi takwimu kwa ajili ya agent inayojiendesha yenyewe muda wote, kwa hivyo chukulia namba yoyote unayopewa kama makadirio. Rekodi usage kutoka kwa mzunguko mmoja halisi na uzidishe kwa ratiba yako.

Kuna tofauti gani kati ya max_tokens na bajeti ya kazi (task budget)?

max_tokens hutekelezwa na haionekani na model. Inazuia matokeo ya ombi moja, ikijumuisha mawazo, na kuifikia kunasababisha stop_reason: "max_tokens". Bajeti ya kazi ni kinyume chake: model huambiwa namba hiyo na hupanga mzunguko wa agent kulingana nayo, lakini "Bajeti za kazi ni dokezo laini, si kikomo kigumu" na kikomo kinachotekelezwa bado ni max_tokens.

Kwa nini cache_read_input_tokens huwa sifuri kila wakati kwa agent wangu?

Kwa sababu prefix hubadilika kati ya maombi, au ni fupi mno kuweza kuhifadhiwa kwenye cache. Sababu ya kawaida ni timestamp au run id inayowekwa kwenye system prompt: cache hutegemea prefix, kwa hivyo mabadiliko yoyote ya byte hufuta kila kitu kinachofuata. Kubadilisha ufafanuzi wa zana au thamani ya effort hufanya vivyo hivyo. Vinginevyo ni ukubwa, kwa sababu prompt fupi hazihifadhiwi kwenye cache na hakuna kosa linalorejeshwa.

Ninawezaje kuzuia AI agent isizunguke milele?

Hesabu marudio katika msimbo wa loop yako na usimame kwenye upeo uliowekwa, kwa sababu max_tokens hupunguza jibu moja na agent hufanya mengi. Ongeza kikomo cha muda wa saa (wall-clock limit) nje ya mchakato: anzisha kazi kutoka kwa systemd timer ukiwa na RuntimeMaxSec= iliyowekwa, ili mzunguko uliokwama uuawe kwa ratiba. Punguza pia majaribio ya kurudia (retries), kwa sababu loop ya kurudia hutoza bili kila jaribio.

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

Kikomo cha matumizi kilichoelezwa ni kwa kila workspace badala ya kila key, kwa hivyo mpe agent workspace yake mwenyewe na uweke kikomo cha matumizi ya kila mwezi hapo. "Huwezi kuweka vikomo kwenye Default Workspace". Ongeza arifa za matumizi ili kizingiti kikuonye kwanza. Kwa ajili ya utambulisho, toa kila kazi key yake, kisha panga ripoti ya matumizi na group_by[]=api_key_id.