Jinsi Paritok inavyopunguza gharama za token za wakala

Jinsi Paritok inavyoshughulikia ombi

Paritok ni lango la token (token gateway): seva mbadala (proxy) inayokaa kati ya wakala wako wa uandishi wa programu (coding agent) na API ya modeli, na kubana kila ombi kabla ya kulisambaza. Wakala wako huwasiliana na http://127.0.0.1:8080 badala ya mtoa huduma. Seva mbadala hii huandika upya skema za zana (tool schemas), usomaji wa faili, matokeo ya zana na mazungumzo ya awali, hutuma mzigo (payload) mdogo zaidi kwenda juu, na kurudisha jibu bila kulibadilisha.

Mtoa huduma hukutoza kulingana na kile kinachowasili kwake, kwa hivyo mzigo mdogo unamaanisha ankara ndogo. Hiyo ndiyo dhana nzima. Hii ni madai tofauti na "muktadha wako unadumu kwa muda mrefu zaidi", na ndiyo sababu zana hii inavutia badala ya kuwa nadhifu tu.

Mradi huu bado ni mpya. Lebo zake za kwanza za umma zina tarehe ya Julai 2026 na lebo ya sasa ni v1.3.0, ya tarehe 5 Agosti 2026. Uzito (weights) na msimbo wa lango hili ziko chini ya leseni ya Apache 2.0. Modeli ya kubana ni adapta ya LoRA (low-rank adaptation) kwenye Qwen3-4B-Instruct-2507, iliyofunzwa kwa sampuli 45,000 zilizochujwa na mwalimu kutoka kwa mienendo halisi ya mawakala wa uandishi wa programu.

Kwa nini hii siyo kupunguza muktadha (context trimming)

Kupunguza muktadha (trimming) hufuta data. Wakati wakala anapokaribia kikomo cha muktadha wake na kuondoa mazungumzo ya zamani, faili aliyoisoma katika hatua ya 3 hupotea. Ikiwa atahitaji faili hiyo katika hatua ya 20, ataisoma faili hiyo tena, kwa hivyo unalipia token hizo kwa mara ya pili. Akiba hiyo ilikuwa ni mkopo tu.

Paritok hubadilisha sehemu fulani na fomu fupi pamoja na tag, [REF:id], na kuhifadhi maandishi kamili kwenye proxy. Model hurejesha sehemu hiyo kwa kuita read_original au expand_context. Hiyo hubadilisha namna ya kushindwa (failure mode). Kifaa cha kupunguza (trimmer) hushindwa kwa kusahau, na hakikuambii kamwe. Kifaa cha kubana (compressor) hushindwa kwa kuipa model muhtasari wenye upungufu, na model inaweza kuomba maandishi asilia wakati muhtasari hautoshi.

Kichujio cha zana (tool filter) hufanya kazi kwa njia ile ile. Schema za zana zilizochujwa huwekwa alama (stubbed) badala ya kuondolewa, na model hurejesha moja kwa kuita gateway_search_tools. Hii ni muhimu kwa sababu kichujio kinachoficha zana kabisa hubadilisha kile ambacho wakala wako anaweza kufanya, na ungejifunza kuhusu hilo kupitia kazi iliyoharibika kimya kimya.

Vilevile vitatu, na kipi kati ya hivyo ni cha bure

Lever ya kwanza ni kichujio cha tool-schema. Kila ombi hubeba safu nzima ya tools. Katika mzunguko wa Claude Code ukiwa na seva kadhaa za MCP (model context protocol) zilizounganishwa, mradi hupima kizuizi hicho kwa takriban token 29,000. Kichujio hicho hufanya embedding ya ombi la mtumiaji na maelezo ya kila zana kwa kutumia BAAI/bge-small-en-v1.5, modeli ya embedding ya 130 MB, huhifadhi zana zinazolingana, na kuzifanya zingine kuwa stubs. Kizuizi hicho hushuka hadi takriban token 8,000. Modeli hiyo ya embedding hufanya kazi kwenye CPU.

Lever ya pili ni ufinyazaji wa maudhui (content compression), na hii ndiyo sehemu inayohitaji modeli ya 4B kwenye GPU. Usomaji wa faili, matokeo ya zana na historia huandikwa upya hadi kufikia 25.7% ya ukubwa wake wa awali. Hapo ndipo takwimu ya 74% inapotoka. Isome kwa makini: 74% ni kiwango cha ufinyazaji kwenye maudhui yanayofinyazwa, si punguzo la bili yako.

Lever ya tatu ni muhtasari wa historia. Bajeti ya muktadha ikijaa, mizunguko inayozidi dirisha la hivi karibuni hufupishwa ili kikao kirefu kiendelee kufanya kazi badala ya kufika kikomo.

Lever ya pili pekee ndiyo inayohitaji GPU. Hiyo ndiyo sentensi yenye manufaa zaidi kwenye ukurasa huu. pip install "paritok[toolselect]" inakupa kichujio cha zana kwenye VPS ya kawaida ya CPU, na hiyo ndiyo nusu ya bidhaa ambayo haikugharimu chochote kwa mwezi. Ijaribu kabla ya kukodisha kadi.

Vipimo vya mradi na mfumo uliotumika

[
  {
    "label": "Paritok-4B-v1",
    "compressed_to_pct": 25.7,
    "quality_retained_pct": 86.5
  },
  {
    "label": "gpt-4.1-mini",
    "compressed_to_pct": 50.2,
    "quality_retained_pct": 85.6
  },
  {
    "label": "gpt-5",
    "compressed_to_pct": 61.9,
    "quality_retained_pct": 93.6
  }
]

Hizi ni takwimu zilizochapishwa na mradi wenyewe, zilizopimwa kwenye mfumo wake dhidi ya SWE-bench Lite. Paritok-4B-v1 hubana maudhui hadi 25.7% ya ukubwa wa awali huku ikihifadhi 86.5% ya kiwango cha utatuzi cha maudhui yasiyobanwa. Kutumia gpt-5 kama kikandamizaji huhifadhi ubora zaidi, 93.6%, lakini hubana hadi 61.9% pekee, na utakuwa ukilipa gharama za kiwango cha juu ili kuokoa gharama za kiwango cha juu.

Soma safu ya ubora kwa umakini. Kuhifadhi 86.5% ya kiwango cha utatuzi inamaanisha kuwa majaribio yaliyobanwa yalishindwa kutatua matatizo ambayo majaribio yasiyobanwa yaliweza kuyatatua, karibu tatizo moja kati ya saba. Kwenye benchmark, hiyo ni nambari tu kwenye jedwali. Kwenye repository yako, hiyo ni kazi unayoiendesha mara mbili.

[
  {
    "label": "Turn 1",
    "saved_pct": 25
  },
  {
    "label": "Turn 5",
    "saved_pct": 39
  },
  {
    "label": "Turn 12",
    "saved_pct": 57
  },
  {
    "label": "Turn 20",
    "saved_pct": 63
  }
]

Akiba ya mwisho hadi mwisho huongezeka kadiri kikao kinavyoendelea, kwa sababu historia hujilimbikiza na historia ndiyo inayobanwa. Mradi unaripoti takriban 25% katika hatua moja, 39% kufikia hatua ya 5, na 63% kufikia hatua ya 20. Pia unaeleza mahali ambapo ukuaji huo husimama: kwenye bajeti ya token 200,000, akiba kamili husimama katika takriban token 48,000 kwa kila hatua, mahali fulani kati ya hatua ya 8 na 12, kwa sababu muktadha unapojaa, historia huacha kukua. Takwimu ya "zaidi ya 85%" inayotajwa sana inaelezea vikao vilivyojaa muktadha. Hiyo ndiyo hali bora zaidi, kwa hivyo usipange mipango yako kulingana nayo.

Je, GPU ya 24GB inalipa gharama za Paritok?

Kadi ya 24 GB ndiyo kizio cha kawaida cha kukodisha kwa ajili ya modeli ya ukubwa huu. Kufikia tarehe 7 Agosti 2026, wastani wa bei ya soko ya RTX 4090 yenye 24 GB ilikuwa $0.44 kwa saa, huku bei nafuu zaidi zikiwa karibu $0.20. Chukua $0.44. Ikiachwa iwake mwezi mzima, hiyo ni saa 730, hivyo ni $321. Ikiwashwa wakati wa saa za kazi pekee, saa 8 kwa siku kwa siku 22, ni saa 176, hivyo ni $77.

Sasa badilisha punguzo la tokeni kuwa punguzo la dola. Punguzo hili linahusu tokeni za kuingiza (input tokens). Tokeni za kutoa (output tokens) hupita kwenye proxy bila kuguswa, kwa hivyo hazibadiliki hata kidogo. Chukua dhana kwamba tokeni za kuingiza ni 80% ya jumla ya dola zako, jambo ambalo ni la kawaida kwa wakala wa uandishi wa programu (coding agent), na uhakikishe dhana hiyo dhidi ya bili yako mwenyewe. Akiba yako ya dola basi ni punguzo la tokeni likizidishwa kwa 0.8.

[
  {
    "label": "Turn 5 (39% saved)",
    "bill_always_on_usd": "1,030",
    "bill_workday_only_usd": 248
  },
  {
    "label": "Turn 20 (63% saved)",
    "bill_always_on_usd": 637,
    "bill_workday_only_usd": 154
  },
  {
    "label": "Saturated (85% saved)",
    "bill_always_on_usd": 472,
    "bill_workday_only_usd": 114
  }
]

Katika takwimu ya 85% ya session iliyojaa, unahifadhi 68% ya bili, kwa hivyo kadi iliyoachwa ikiwaka inajilipia yenyewe pindi matumizi yako ya kila mwezi ya wakala yanapozidi takriban $472, au takriban $114 ikiwa utazima instance hiyo nje ya saa za kazi. Katika takwimu ya 63% ya turn-20, hizo huwa $637 na $154. Katika takwimu ya 39% ya turn-5, ambayo ndiyo hali halisi ya session fupi, unahitaji takriban $1,030 kwa mwezi kabla ya kadi hiyo kuwa na thamani ya kukodiwa hata kidogo.

Mambo mawili hufanya hili kuwa bora zaidi kuliko jedwali linavyopendekeza. Modeli haihitaji 24 GB: toleo la q4 ni takriban 2.5 GB na toleo la bf16 ni takriban 8 GB, kwa hivyo kadi ndogo, au kisanduku cha GPU unachotumia kwa kitu kingine, hupunguza kila namba kwenye chati hiyo. Na kuzima instance wakati hakuna anayeandika programu ndiyo njia kuu ya kuokoa gharama, kwa sababu hupunguza kodi kwa takriban robo tatu.

Jambo moja hufanya hali kuwa mbaya zaidi. Mchakato wa compression ni kazi halisi. Kila tokeni ambayo modeli ya 4B inafanya compression ni tokeni ambayo lazima isome kisha iandike, jambo linaloongeza latency kwenye kila turn ya wakala. Kwenye kadi unayokodi kwa saa, gharama hiyo huonekana kama muda wa kusubiri, si kama mstari kwenye ankara, kwa hivyo ni rahisi kuikosa hadi pale unapoihisi.

Ikiwa unapima saa za GPU zilizokodiwa dhidi ya tokeni za API kwa ujumla, kikomo cha faida kati ya GPU VPS na tokeni za API hufuata hesabu ileile kwa ajili ya inference yenyewe.

Kuendesha Paritok gateway kwenye VPS

Python 3.10 au toleo jipya zaidi linahitajika. Ubuntu 24.04 inakuja na Python 3.12, kwa hivyo image ya kawaida ya VPS inatosha kwa ajili ya sehemu inayotumia CPU pekee.

sudo apt update && sudo apt install -y python3-venv curl
python3 -m venv /opt/paritok/venv
source /opt/paritok/venv/bin/activate
pip install "paritok[proxy]==1.3.0"
pip install "paritok[toolselect]==1.3.0"

Funga toleo (pin the version). Repository ilitoa tag ya v1.2.8 tarehe 29 Julai 2026 na v1.3.0 tarehe 5 Agosti 2026, na mradi unaoenda kwa kasi hiyo hubadilisha majina ya config keys kati ya releases. pip install paritok tupu, au git clone ya main, itakupa gateway tofauti wiki ijayo na haitaacha kumbukumbu ya toleo lipi lililozalisha namba ulizopima.

Backend chaguo-msingi ni Ollama. Vuta (pull) model, kisha uipe jina fupi ambalo proxy inalitafuta.

ollama pull paritok/paritok-4b-v1
ollama cp paritok/paritok-4b-v1 paritok-4b-v1

Andika paritok.yaml pembeni yake. use_gpu_server: false ndicho kinachoweka compression kwenye vifaa vyako mwenyewe.

use_gpu_server: false
local_model:
  base_url: http://localhost:11434

paritok proxy --port 8080 --config-file paritok.yaml

paritok up ni njia ya mkato ya yote yaliyotajwa hapo juu: inavuta model ikiwa haipo na kuanzisha proxy kwenye port 8080. Hakiki proxy kabla ya kuelekeza agent kwake.

curl http://127.0.0.1:8080/health
curl http://127.0.0.1:8080/stats

/health inarudisha JSON object ndogo yenye "status":"ok" na kamba ya toleo (version string). /stats inarudisha jumla ya compression na makadirio ya proxy yenyewe ya kile ilichookoa. Chukulia makadirio hayo kama proxy kujipima kazi yake yenyewe, na uyathibitishe dhidi ya ukurasa wa matumizi wa mtoa huduma wako.

Kwa ajili ya throughput badala ya urahisi, vLLM hutumika kuendesha adapter juu ya base model.

vllm serve Qwen/Qwen3-4B-Instruct-2507 \
  --enable-lora \
  --lora-modules paritok-4b-v1=paritok/paritok-4b-v1 \
  --port 8000

Ollama ni ya haraka zaidi kusanidi. vLLM inashughulikia maombi mengi kwa wakati mmoja (concurrent requests) vizuri zaidi, jambo ambalo huanza kuwa muhimu mara tu zaidi ya agent mmoja anaposhiriki seva hiyo. Tofauti ya kiutendaji kati ya Ollama na vLLM ndiyo inayokusaidia kuamua hili.

Elekeza agent kwenye proxy kwa kutumia environment variables za base URL.

export ANTHROPIC_BASE_URL=http://127.0.0.1:8080
export OPENAI_BASE_URL=http://127.0.0.1:8080

Codex CLI hupuuza OPENAI_BASE_URL, kwa hivyo mradi huandika ~/.codex/config.toml kwa ajili yako wakati codex.enabled: true imewekwa kwenye paritok.yaml. Kusafirisha (export) variable hiyo pekee kutafanya Codex iwasiliane moja kwa moja na mtoa huduma, na ishara ya hilo ni counter ya /stats ambayo haisogei wakati unafanya kazi.

Weka listener kwenye 127.0.0.1, kamwe usiiweke kwenye 0.0.0.0. Proxy husambaza API key ya mtoa huduma wako kwenda juu (upstream), kwa hivyo proxy inayoweza kufikiwa kutoka Internet ni open relay kwa key hiyo: yeyote atakayegundua port hiyo atatumia pesa zako bila hata kuiona key yenyewe. Ifikie kutoka kwenye laptop kupitia SSH tunnel au VPN badala ya kufungua port hiyo.

Iendeshe chini ya systemd ili iendelee kufanya kazi baada ya reboot. Rekebisha njia (paths) ili zilingane na usakinishaji wako.

[Unit]
Description=Paritok compression proxy
After=network-online.target

[Service]
User=paritok
WorkingDirectory=/opt/paritok
ExecStart=/opt/paritok/venv/bin/paritok proxy --port 8080 --config-file /opt/paritok/paritok.yaml
Restart=on-failure

[Install]
WantedBy=multi-user.target

Iwezeshe kwa sudo systemctl enable --now paritok, kisha fanya curl kwenye /health tena. Unit inayoanza na kuzima mara moja kwa kawaida inamaanisha njia ya faili ya config si sahihi, na journalctl -u paritok -n 50 huchapisha sababu yake.

Chaguo la huduma inayopangishwa, na gharama zake

Mradi huu pia unauza huduma ya compression kama huduma. Weka use_gpu_server: true ukiwa na API key na modeli ya 4B itafanya kazi kwenye maunzi yao, kwa bei ya $0.30 kwa kila token milioni moja zinazochakatwa, huduma ambayo ni bure hadi mwisho wa Agosti 2026 kulingana na nyaraka zao. Hii inaondoa gharama ya kukodisha GPU na kazi zote za uendeshaji zilizotajwa hapo juu.

Hii pia inamaanisha kuwa prompts zako na faili ambazo wakala wako anazisoma zinaondoka kwenye mashine yako na kufika kwa wahusika wengine kabla hazijafika kwa mtoa huduma wa modeli yako. Self-hosting ipo ili kuepuka hatua hiyo hasa. Amua ni lipi kati ya hayo mawili unalolipa kipaumbele kabla ya kuweka flag hiyo, kwa sababu flag hiyo ni mabadiliko ya mstari mmoja tu lakini matokeo yake si madogo.

Jinsi ya kupima matokeo yako ya kabla na baada

Nambari zilizochapishwa ni za mradi huu, zikipatikana kutoka kwenye mfumo wa majaribio wa mradi, kwenye SWE-bench Lite. Hazina yako (repository) si SWE-bench Lite. Pima matokeo yako mwenyewe.

• Endesha kazi kwa wiki moja ya kawaida bila proxy yoyote kwenye njia. Rekodi token za kuingiza (input tokens), token za kusoma kutoka kwenye cache (cache-read tokens), na token za kutoa (output tokens) kama mistari tofauti kutoka kwenye ukurasa wa matumizi wa mtoa huduma wako, si kama jumla ya dola moja.
• Endesha wiki inayofuata ukiwa na proxy mbele, ukifanya kazi ya aina ileile.
• Linganisha mistari ya input na cache-read. Output inapaswa kubaki karibu sawa, kwa sababu hakuna kinachoi-compress. Ikiwa output imebadilika sana, kuna kitu kingine kimebadilika isipokuwa proxy.
• Hesabu kazi ulizolazimika kurudia. Hiyo ndiyo nusu ya ubora wa biashara hiyo, na hakuna dashibodi yoyote inayoiripoti.
• Ongeza saa za GPU kwenye wiki ya pili kabla ya kulinganisha jumla.

Kutenganisha input na output ni muhimu kwa sababu bei zake ni tofauti sana na compressor inagusa moja tu kati ya hizo. Kufikia Agosti 2026, Claude Sonnet 4.6 inagharimu $3 kwa kila milioni ya input tokens na $15 kwa kila milioni ya output tokens, na usomaji wa prompt-cache ni 10% ya kiwango cha input, yaani $0.30 kwa kila milioni. Pengo kati ya gharama ya token za input na output ndilo linaloamua kama compressor ya upande wa input ina thamani yoyote kwako. Mahali ambapo token za Claude Code huenda kihalisi inakuambia ni sehemu gani ya context yako ni kubwa vya kutosha kuhangaika kuifanyia compression.

Prompt caching inafanya hesabu za tool-filter kuwa ngumu zaidi. Kizuizi cha zana (tool block) hukaa mwanzoni mwa ombi, kwa hivyo baada ya zamu ya kwanza kwa kawaida huwa ni cache hit kwa 10% ya bei ya input. Kukata token 21,000 kutoka kwenye kizuizi kilichohifadhiwa kwenye cache huokoa 21,000 kwa $0.30 kwa kila milioni, takriban $0.006 kwa kila zamu, badala ya $0.063 ambayo kiwango kisicho na cache kingependekeza. Mradi huu huweka kizuizi kilichochujwa kikiwa kimegandishwa kwa ajili ya kipindi hicho ili prefix iliyohifadhiwa kwenye cache isibadilike. Kichujio (filter) kinachochagua upya zana kila zamu kingefuta uhalali wa prefix hiyo na kingegharimu zaidi ya kile kilichookolewa.

Mambo ambayo bado hayajathibitishwa

Kila namba ya utendaji hapo juu inatoka kwa mradi wenyewe. Hakuna uthibitisho huru wa matokeo ya SWE-bench Lite, na kwa kuwa tag za kwanza zimeandikwa Julai 2026, hakuna historia kubwa ya kiutendaji nyuma ya code hiyo. Kiwango cha compression na takwimu ya ubora uliotunzwa vyote hupimwa na upande unaofaidika na namba hizo kuonekana nzuri. Hiyo haimaanishi kuwa ni makosa. Inamaanisha kuwa hazijathibitishwa, na unapaswa kuzichukulia tofauti na namba ulizozizalisha wewe mwenyewe.

Kuna tabia moja iliyoandikwa ambayo inafaa kuijua kabla ya kulaumu usanidi wako. Embedding model inayotumiwa na kichujio cha zana hupakiwa kwenye ombi la kwanza badala ya wakati wa kuanza (startup), kwa hivyo mradi unaelekeza muda wa maandalizi (warm-up) wa sekunde 10 hadi 15, kisha takriban 15 ms kwa kila mwito baada ya hapo. Tuma ombi moja la majaribio baada ya proxy kuanza na zamu yako ya kwanza ya kweli ya agent haitaonekana kama imekwama.

Mambo manne unayoweza kuyathibitisha mwenyewe katika mchana mmoja: kama proxy inaanza na kubaki ikiwa imewaka, kama /stats inasogea wakati unafanya kazi, kama laini ya input-token ya mtoa huduma wako inashuka kweli, na kama agent bado anamaliza kazi. Hayo ndiyo yanayoamua kwa usanidi wako vizuri zaidi kuliko benchmark yoyote iliyochapishwa.

Kuhusu mahali ambapo hii inakaa kando ya zana zako nyingine: gateway ya LiteLLM inayojiendesha yenyewe huelekeza na kupima maombi bila kubadilisha yaliyomo, kwa hivyo zana hizi mbili hutatua matatizo tofauti na zinaweza kuunganishwa, huku Paritok ikiwa karibu zaidi na agent. Ikiwa lengo la kweli ni bili ndogo badala ya zana hii mahususi, seti pana ya vidhibiti vya gharama kwa ajili ya agent kwenye VPS inajumuisha mabadiliko kadhaa ambayo hayagharimu chochote kujaribu kwanza.

FAQ

Je, Paritok inapunguza bili yangu ya API au matumizi ya context pekee?

Inapunguza bili, kwa sababu proxy hurekebisha ombi kabla halijafika kwa mtoa huduma, na mtoa huduma hutoza kulingana na kile anachopokea. Kiasi cha punguzo hilo ni kidogo kuliko inavyoonekana kwenye vichwa vya habari. Takwimu ya 74% ni kiwango cha compression kwenye maudhui yanayobanwa. Kwa ujumla, mradi unaripoti takriban 25% kwa zamu moja na 63% kufikia zamu ya 20, na input tokens pekee ndizo zinazobadilika. Output tokens hupita bila kuguswa.

Ninahitaji GPU kiasi gani ili ku-host model ya compression mwenyewe?

Toleo la q4 lina ukubwa wa takriban 2.5 GB na toleo la bf16 lina takriban 8 GB, kwa hivyo model inatosha kwenye kadi ya 24 GB ikiwa na nafasi kubwa iliyobaki. Kadi ndogo zaidi inafanya kazi, na hiyo inabadilisha hesabu za faida kwa upande wako. Kichujio cha tool-schema hakihitaji GPU kabisa: kinatumia BAAI/bge-small-en-v1.5, model ya embedding ya 130 MB inayofanya kazi kwenye CPU. Sakinisha paritok[toolselect] kwenye VPS ya kawaida na utapata punguzo la tool-block kwa gharama ya RAM kidogo tu.

Nini kinatokea ikiwa compressor itaondoa kitu ambacho agent alikihitaji?

Hakuna kinachoondolewa. Sehemu zilizobanwa hubeba tag ya [REF:id] na model hurejesha maandishi kamili kwa kutumia read_original au expand_context. Tool schemas zilizochujwa huwekewa alama badala ya kufutwa, na model hurejesha moja kwa kutumia gateway_search_tools. Hatari halisi ni tulivu zaidi kuliko faili iliyopotea: model hufanya kazi kutokana na muhtasari uliopoteza data (lossy) na haitambui kamwe kuwa inapaswa kuomba ile ya asili. Hicho ndicho takwimu ya 86.5% ya ubora uliorejeshwa kwenye SWE-bench Lite inapopima.

Kwa nini ombi langu la kwanza linachukua sekunde kumi na tano?

Model ya embedding iliyo nyuma ya kichujio cha tool hupakiwa kwenye ombi la kwanza badala ya wakati wa kuanza (startup). Mradi unaeleza muda wa kuwasha (warm-up) wa sekunde 10 hadi 15, kisha takriban 15 ms kwa kila mwito baada ya hapo. Tuma ombi moja la majaribio na curl baada ya kuanzisha proxy, na zamu ya kwanza ya kweli ya agent haitakwama.

Je, nitumie seva ya GPU iliyo-hostwa badala ya kuji-host mwenyewe?

Hiyo huondoa gharama ya kukodisha GPU na matengenezo, kwa bei ya $0.30 kwa kila milioni ya tokens zilizochakatwa kufikia Agosti 2026. Pia hutuma prompts zako na faili ambazo agent wako anasoma kwa mtu wa tatu kabla hazijafika kwa mtoa huduma wako wa model. Ikiwa unaji-host mwenyewe ili kuweka code kwenye miundombinu unayoimiliki, mpangilio huo unaharibu sababu iliyokufanya uanze. Kuji-host mwenyewe kunahifadhi context na API key ya mtoa huduma kwenye mashine yako mwenyewe.