Jinsi ya kukokotoa gharama za Claude prompt caching

Gharama za prompt caching kabla ya kuleta akiba

Prompt caching inaruhusu Claude kutumia tena sehemu ya mwanzo ya prompt yako badala ya kuisoma upya katika kila ombi, na uamuzi wote unategemea vizidishi viwili kwenye bei ya msingi ya input ya model yako. Kufikia Agosti 2026, gharama ya kuandika kwenye cache (cache write) ni 1.25x ya bei ya msingi ya input kwa muda wa maisha wa dakika 5, au 2x kwa muda wa saa 1. Kusoma kutoka kwenye cache (cache read) kunagharimu 0.1x. Vizidishi hivi vinabaki vilevile katika orodha nzima ya model, kwa hivyo kiwango cha kufidia gharama (break-even) hakibadiliki bei ya kila token inapobadilika.

Huu ni ubadilishaji wa gharama ya ziada sasa dhidi ya punguzo baadaye. Unalipa ziada mara moja ili kuhifadhi prefix. Kila ombi la baadaye linaloanza na byte zilezile hasa, hulipa sehemu ya kumi ya bei ya kawaida ya input kwa sehemu hiyo. Prefix ambayo haijawahi kutumiwa tena ndani ya muda wake wa maisha imekugharimu asilimia 25 ya ziada bila faida yoyote.

Kiwango cha kufidia gharama, kwa mlinganyo mmoja wa aljebra

Ikiwa B ni gharama ya msingi ya kuingiza prefix kama utaituma bila caching. Bila caching, maombi N yanagharimu N mara B. Kwa cache ya dakika 5, ombi la kwanza huandika prefix kwa 1.25B na maombi mengine N kutoa 1 huisoma kwa 0.1B. Weka viwili hivi sawa na utapata 0.9N = 1.15, hivyo N = 1.28. Ombi la pili tayari ni nafuu kuliko kutotumia cache kabisa.

Rudia hilo kwa uandishi wa 2x wa cache ya saa 1 na utapata 0.9N = 1.9, hivyo N = 2.11. Cache ya muda mrefu inahitaji usomaji miwili kabla ya kufidia gharama, ndiyo maana si chaguo chaguo-msingi.

Chati hapa chini inaweka bei hii kwa prefix ya token 20,000 kwenye Claude Opus 5, ambayo kiwango chake cha msingi cha uingizaji ni $5 kwa kila token milioni kufikia Agosti 2026. Zidisha kila takwimu kwa 0.6 kwa modeli ya $3 kwa kila milioni. Umbo la mkondo halibadiliki.

[
  {
    "requests": 1,
    "uncached_usd": "0.10",
    "cached_5m_usd": "0.125",
    "cached_1h_usd": "0.20"
  },
  {
    "requests": 2,
    "uncached_usd": "0.20",
    "cached_5m_usd": "0.135",
    "cached_1h_usd": "0.21"
  },
  {
    "requests": 3,
    "uncached_usd": "0.30",
    "cached_5m_usd": "0.145",
    "cached_1h_usd": "0.22"
  },
  {
    "requests": 5,
    "uncached_usd": "0.50",
    "cached_5m_usd": "0.165",
    "cached_1h_usd": "0.24"
  },
  {
    "requests": 10,
    "uncached_usd": "1.00",
    "cached_5m_usd": "0.215",
    "cached_1h_usd": "0.29"
  },
  {
    "requests": 20,
    "uncached_usd": "2.00",
    "cached_5m_usd": "0.315",
    "cached_1h_usd": "0.39"
  }
]

Ombi moja pekee linagharimu $0.10 bila cache na $0.125 likiwa na cache, kwa hivyo kuweka cache kwenye prompt ya mara moja ni hasara tupu. Kufikia ombi la pili, cache ya dakika 5 iko kwenye $0.135 dhidi ya $0.20. Cache ya saa 1 bado iko nyuma wakati huo, $0.21 dhidi ya $0.20 ile ile, na inavuka mstari wa bila cache kwenye ombi la tatu pekee: $0.22 dhidi ya $0.30. Kufikia maombi 20, pengo ni $2.00 dhidi ya $0.315.

Cache hit pia hufanya upya (refresh) ingizo, ndiyo maana jedwali la bei lililochapishwa huita safu hiyo cache hits na refreshes. Endpoint yenye shughuli nyingi kwa hivyo huweka ingizo la dakika 5 likiwa hai bila kikomo kwa bei za usomaji, na muda wa maisha wa saa 1 hupata gharama yake ya uandishi ya 2x pale tu trafiki yako inapokuwa na mapengo halisi.

Gharama ya hit rate ndogo

Maombi halisi yanayokosa cache (misses) yana gharama. Ombi linalokosa cache lakini bado likiwa na breakpoint hutoza gharama kama ya uandishi (write), kwa hivyo njia sahihi ya kukokotoa hili ni kuona gharama kama kazi ya hit rate. Chati hapa chini inaonyesha hilo kwa maombi 1,000, kila moja ikiwa na prefix ya token 20,000.

[
  {
    "hit_rate_percent": 0,
    "cost_5m_usd": "125.00",
    "cost_1h_usd": "200.00",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 25,
    "cost_5m_usd": "96.25",
    "cost_1h_usd": "152.50",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 50,
    "cost_5m_usd": "67.50",
    "cost_1h_usd": "105.00",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 75,
    "cost_5m_usd": "38.75",
    "cost_1h_usd": "57.50",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 90,
    "cost_5m_usd": "21.50",
    "cost_1h_usd": "29.00",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 95,
    "cost_5m_usd": "15.75",
    "cost_1h_usd": "19.50",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 99,
    "cost_5m_usd": "11.15",
    "cost_1h_usd": "11.90",
    "uncached_usd": "100.00"
  }
]

Katika hit rate ya asilimia 0 unalipa $125.00 badala ya $100.00, na cache ya saa 1 huongeza bili mara mbili hadi $200.00. Tatua mlinganyo wa 1.25 kutoa 1.15h = 1 na utaona cache ya dakika 5 huanza kuokoa pesa katika hit rate ya takriban asilimia 22, ndiyo maana asilimia 25 tayari inaonyesha $96.25. Kokotoo hilohilo kwa uandishi wa 2x linatoa takriban asilimia 53 kwa cache ya saa 1, kwa hivyo hit rate ya asilimia 50 bado inagharimu $105.00, ikiwa juu ya mstari wa bila cache. Katika asilimia 90, viwango hivyo viwili vinafika $21.50 na $29.00. Katika asilimia 99, cache fupi inafika $11.15, karibu na kiwango cha chini cha sehemu ya kumi ya bei ya bila cache.

Hit rate ndiyo namba unayopaswa kuifuatilia (instrument), kwa sababu ndiyo ingizo pekee unaloweza kulidhibiti baada ya ukubwa wa prefix kuwekwa.

Prefix zipi zinafaa kuwekewa breakpoint

Ombi linaweza kubeba hadi cache breakpoint nne, kwa hivyo swali ni ni block zipi zinastahili kuwekewa moja. Wagombea ni block ambazo zinafanana kibaite (byte-identical) katika kila mwito na zina ukubwa wa kutosha kuleta tofauti. Chati hapa chini inaonyesha bei ya maumbo manne ya kawaida kwa maombi 1,000 kwa kiwango cha hit rate cha asilimia 90 kwenye cache ya dakika 5.

[
  {
    "label": "System prompt",
    "prefix_size_tokens": "2,000",
    "uncached_usd": "10.00",
    "cached_usd": "2.15",
    "saved_usd": "7.85"
  },
  {
    "label": "System plus tools",
    "prefix_size_tokens": "8,000",
    "uncached_usd": "40.00",
    "cached_usd": "8.60",
    "saved_usd": "31.40"
  },
  {
    "label": "Policy document",
    "prefix_size_tokens": "25,000",
    "uncached_usd": "125.00",
    "cached_usd": "26.88",
    "saved_usd": "98.12"
  },
  {
    "label": "Codebase context",
    "prefix_size_tokens": "120,000",
    "uncached_usd": "600.00",
    "cached_usd": "129.00",
    "saved_usd": "471.00"
  }
]

Mfumo wa token 2,000 wa kawaida huokoa $7.85 kwa kila maombi 1,000 dhidi ya $10.00 bila cache. Hii ni pesa halisi kwa ujazo mkubwa, lakini siyo kitu kinachofanya caching kuvutia. Ongeza ufafanuzi wa tool na utafikia token 8,000 na $31.40 zilizookolewa. Hati ya sera ya token 25,000 ambayo kila ombi huuliza maswali kuihusu huokoa $98.12. Mstari wa mwisho ndio unaobadilisha usanifu: token 120,000 za codebase au muktadha wa transcript hugharimu $600.00 bila cache na $129.00 zikiwa na cache, ikiwa ni akiba ya $471.00.

Akiba huongezeka kulingana na ukubwa wa prefix na kiwango cha hit rate, na si kitu kingine chochote. Hilo hubadilisha kile kinachostahili kuwekwa kwenye prompt: gharama halisi ya token milioni moja za Claude hushuka hadi sehemu ya kumi ya bei ya kawaida kwa chochote unachotuma zaidi ya mara moja.

Muonekano wake kwenye ankara ya kila mwezi

Chati iliyo hapa chini inachukua 8,000 token prefix kutoka hapo juu, pamoja na prompt ya mfumo na ufafanuzi wa zana, kwa kiwango cha mafanikio cha asilimia 90, na kuipima kulingana na idadi ya maombi ya kila mwezi.

[
  {
    "label": "10k requests",
    "uncached_usd": "400.00",
    "cached_usd": "86.00",
    "saved_usd": "314.00"
  },
  {
    "label": "100k requests",
    "uncached_usd": "4,000.00",
    "cached_usd": "860.00",
    "saved_usd": "3,140.00"
  },
  {
    "label": "1M requests",
    "uncached_usd": "40,000.00",
    "cached_usd": "8,600.00",
    "saved_usd": "31,400.00"
  }
]

Kwa maombi 10,000 kwa mwezi, akiba ni $314.00, ambayo ni tofauti kati ya $400.00 na $86.00. Kwa maombi 100,000, akiba ni $3,140.00. Kwa maombi milioni moja, ankara ya input isiyohifadhiwa kwenye cache ni $40,000.00 na utumiaji wa cache unaondoa $31,400.00 ya gharama hiyo. Hizi ni token za input pekee. Output hupangiwa bei kivyake na cache haisaidii kupunguza gharama zake, jambo la kukumbuka kabla ya kumwahidi mtu yeyote punguzo la asilimia 90 kwenye ankara. Caching inafanya kazi sambamba na mbinu nyingine za kudhibiti gharama za AI agent kwenye VPS.

Jinsi ya kuthibitisha kuwa cache inafanya kazi

Usiuamini usanifu pekee. Soma sehemu ya matumizi (usage block) kwenye jibu. Kila jibu la Messages API (application programming interface) huripoti tokeni zilizohifadhiwa kwenye cache ilizoandika, tokeni zilizohifadhiwa ilizosoma, na tokeni mpya ilizopaswa kuchakata.

from anthropic import Anthropic

client = Anthropic()

resp = client.messages.create(
    model="claude-opus-5",
    max_tokens=512,
    system=[
        {
            "type": "text",
            "text": POLICY_DOCUMENT,
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[{"role": "user", "content": question}],
)

u = resp.usage
print("write:", u.cache_creation_input_tokens)
print("read: ", u.cache_read_input_tokens)
print("fresh:", u.input_tokens)

Iendeshe mara mbili kwa kutumia hati ileile na swali tofauti. Ombi la kwanza huripoti cache_creation_input_tokens isiyo sifuri na cache_read_input_tokens ya sifuri. Ombi la pili hubadilisha hali hiyo, kwa sababu prefix ilipatikana. input_tokens huhesabu tu tokeni zilizopo baada ya breakpoint ya mwisho, kwa hivyo kwenye ombi la pili lenye afya, namba hii huwa ndogo, kwa kawaida ni ujumbe mpya wa mtumiaji pekee.

Ukaguzi uleule kutoka kwenye shell, dhidi ya body ya ombi uliyohifadhi kwenye request.json:

curl -s https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d @request.json | jq '.usage'

Ombi la pili lenye afya huchapisha kitu kama hiki:

{
  "input_tokens": 42,
  "cache_creation_input_tokens": 0,
  "cache_read_input_tokens": 20143,
  "output_tokens": 187
}

Mstari mmoja hukuambia ukweli. Ikiwa cache_read_input_tokens itabaki kuwa 0 katika maombi yote, unalipa gharama ya 1.25x ya kuandika kila wakati na hupati chochote kama faida.

Kwa muda wa kuishi wa saa 1, breakpoint hubeba muda wa kuishi (TTL):

{
  "type": "text",
  "text": "your stable prefix",
  "cache_control": {"type": "ephemeral", "ttl": "1h"}
}

Pia kuna caching ya kiotomatiki: sehemu moja ya cache_control katika kiwango cha juu cha ombi, ambapo API hudhibiti breakpoints kadiri mazungumzo yanavyokua. Hii hutumia moja ya nafasi zako nne za breakpoint. Anzia hapo. Hamia kwenye breakpoints za wazi (explicit) pale unapohitaji kuamua hasa mahali ambapo mpaka huo unapaswa kukaa.

Kanuni ya mpangilio inayoharibu viwango vya hit

Cache hulinganisha prefix byte kwa byte kuanzia mwanzo wa ombi, na ombi hilo huunganishwa kwa mpangilio maalum: tools, kisha system, kisha messages. Mabadiliko katika kiwango chochote hubatilisha kiwango hicho na kila kitu kinachofuata. Hariri maelezo ya tool moja na system prompt pamoja na historia nzima ya ujumbe hubatilishwa nayo, hata kama hukuvigusa.

Hii inatoa kanuni moja isiyo na ubaguzi. Kitu chochote kinachobadilika kati ya wito (calls) lazima kiwe baada ya kila kitu kisichobadilika.

Mhalifu wa kawaida ni timestamp. Mstari unaosomeka Current time: 2026-08-03T14:07:11Z juu ya system prompt huhakikisha kiwango cha hit cha asilimia 0, kwa sababu prefix hash ni tofauti katika kila wito na hakuna ingizo la awali linaloweza kulingana nalo. Ihamishe kwenye user message, mwishoni. Kitambulisho cha session au nonce ya kila ombi huvuruga mambo kwa njia ile ile na ina suluhisho sawa. Nyaraka zilizorejeshwa (retrieved documents) zinazotofautiana kwa kila ombi pia ni lazima ziwekwe baada ya block iliyohifadhiwa kwenye cache, vinginevyo zitasukuma kila token thabiti nyuma ya mpaka unaohamahama.

Mhalifu wa pili ni kuweka breakpoint kwenye block inayobadilika. Uandikaji wa cache hutokea kwenye breakpoint, kwa hivyo ikiwa block hiyo ni tofauti kila wakati, hakuna kitu thabiti kinachohifadhiwa, na utafutaji wa nyuma (lookback) hupata tu maingizo ambayo maombi ya awali yaliandika kwenye breakpoint zao zinazohamahama. Weka cache_control kwenye block ya mwisho ambayo maudhui yake ni sawa katika maombi yote.

Ya tatu ni mabadiliko ya parameter ambayo hukuyazingatia kama maudhui ya prompt. Model tofauti ina cache tofauti. Kubadilisha chaguo la tool hubatilisha kuanzia kiwango cha system kuendelea. Kuongeza au kuondoa tool hubatilisha kila kitu.

Kiambishi awali cha chini kabisa, na hali ya kimya ya no-op

Kiambishi awali (prefix) ambacho ni kifupi kuliko kiwango cha chini cha modeli hakihifadhiwi kwenye cache, na hakuna taarifa yoyote inayotolewa. Hakuna kosa, hakuna onyo. Ombi linafanikiwa na kaunta zote mbili zinasoma 0. Kufikia Agosti 2026, viwango vya chini vilivyochapishwa ni:

• 512 tokens kwenye Claude Opus 5 na Claude Fable 5
• 1,024 tokens kwenye Claude Sonnet 5 na Claude Opus 4.8
• 4,096 tokens kwenye Claude Haiku 4.5

Ikiwa kaunta zote mbili zinasoma 0 kwenye ombi ambalo unaamini limehifadhiwa kwenye cache, kagua urefu wa kiambishi awali kabla ya jambo lingine lolote. Hii ndiyo sababu modeli ya bei nafuu zaidi si lazima iwe ya bei nafuu zaidi kwa kazi ya caching. Haiku 4.5 inahitaji kiambishi awali kirefu mara nane kuliko Opus 5 ili caching ianze kufanya kazi, kwa hivyo prompt ya mfumo ya 2,000 tokens inahifadhiwa kwenye moja na kupuuzwa kimya kimya kwenye nyingine.

Mahali ambapo Claude Code huhifadhi akiba (cache) kwa ajili yako, na mahali ambapo haiwezi

Claude Code huhifadhi prefix yake yenyewe kwenye cache. Prompt ya mfumo na ufafanuzi wa zana (tool definitions) hukaa mwanzoni mwa kila ombi na havibadiliki, kwa hivyo huandikwa mara moja na kusomwa tena kwa muda wote wa kikao. Hii ndiyo sababu gharama ya kila hatua (per-turn) katika kikao kirefu iko chini sana kuliko ukubwa wa muktadha (context size) unavyopendekeza, na hii huonekana kwenye vihesabio vilivyoelezwa katika jinsi Claude Code inavyoripoti matumizi ya token.

Mahali ambapo haiwezi kukusaidia ni pale unapofanya uhariri (edit) karibu na mwanzo wa muktadha. Historia ya mazungumzo huongezeka tu (append-only), kwa hivyo hatua mpya za kawaida huongeza prefix ambayo tayari imehifadhiwa kwenye cache. Kuhariri faili iliyosomwa mapema kwenye kikao hubadilisha maudhui yaliyopo katikati ya prefix hiyo, na kila token inayofuata mabadiliko hayo lazima iandikwe tena. Muda mrefu wa kutofanya kazi (idle gap) hufanya vivyo hivyo, kwa sababu ingizo hilo huisha muda wake na hatua inayofuata hulipia uandishi kamili. Hakuna kati ya haya lililo hitilafu (bug). Yote mawili ni kanuni ya prefix inayotekeleza kile inachosema hasa.

Ikiwa unaandika mteja (client) wako mwenyewe badala yake, tumia mpangilio kutoka kwa ombi la kwanza badala ya kuurekebisha baadaye: jenga mwito (call) kwa njia ambayo programu ya kwanza ya Claude API kwenye VPS inafanya, huku vizuizi thabiti (stable blocks) vikiwa mwanzo na vile vinavyobadilika (volatile) vikiwa mwisho.

Njia za kufeli, na utakachokiona

Kila ombi ni uandishi. cache_creation_input_tokens si sifuri katika kila ombi wakati cache_read_input_tokens inabaki 0. Kuna kitu kwenye au kabla ya breakpoint kinabadilika kati ya maombi. Chapisha herufi 200 za kwanza za prefix uliyokusanya kwenye maombi mawili mfululizo na uzilinganishe kwa macho.

Kaunta zote mbili ni 0. Prefix iko chini ya kiwango cha chini cha model, au sehemu ya cache_control haikufika kwenye API. Hesabu token za prefix kwanza, kisha weka kwenye logi mwili wa ombi uliotuma kweli.

Usomaji unafanya kazi, kisha unasimama. Mfululizo wa hits, kisha uandishi, kisha hits tena. Muda uliopita kati ya maombi ulikuwa mrefu kuliko muda wa uhai (lifetime). Kubali uandishi, au hamia kwenye TTL ya saa 1 baada ya kuhakikisha hit rate yako inavuka asilimia 53.

Hit rate inashuka baada ya deploy. Maelezo ya zana yamehaririwa au model imebadilishwa. Vyote viwili vinabatilisha prefix nzima. Tarajia mzunguko mmoja wa gharama wa uandishi baada ya kila deploy inayohusu prompt.

Bili imepanda baada ya kuwezesha caching. Hit rate yako iko chini ya kiwango cha faida. Chini ya asilimia 22 kwenye cache ya dakika 5, kutuma prefix bila cache ni nafuu zaidi, na chini ya asilimia 53 hali hiyo ni kweli kwa cache ya saa 1.

FAQ

Ni mara ngapi prompt inapaswa kutumika tena ili caching iwe na faida?

Mara moja, kwa cache ya dakika 5. Uandishi unagharimu 1.25x ya input ya msingi na usomaji unagharimu 0.1x, kwa hivyo maombi N yasiyo na cache yanagharimu N huku maombi N yaliyopo kwenye cache yakigharimu 1.25 pamoja na 0.1 mara N kutoa 1. Mahesabu haya hukutana kwenye N = 1.28, kwa hivyo ombi la pili tayari lina faida. Cache ya saa 1 huandika kwa 2x na hukutana kwenye N = 2.11, kwa hivyo inahitaji usomaji miwili.

Kwa nini cache_read_input_tokens huwa sifuri kila wakati?

Kwanza, kagua urefu wa prefix: chini ya kiwango cha chini cha model, token 512 kwenye Claude Opus 5 na 4,096 kwenye Claude Haiku 4.5 kufikia Agosti 2026, caching hurukwa kimya kimya na kaunta zote mbili husoma 0. Ikiwa prefix ni ndefu vya kutosha, tafuta maudhui yanayobadilika kati ya maombi yaliyopo kwenye au kabla ya breakpoint, kama vile timestamp au kitambulisho cha session kwenye system prompt. Ikiwa kaunta zilikuwa zikifanya kazi na zikaacha, pengo kati ya maombi lilikuwa refu kuliko muda wa kuishi wa cache.

Je, prompt caching hubadilisha majibu ya Claude?

Hapana. Cache huhifadhi umbo lililochakatwa la token ulizotuma tayari, na model huona prompt ile ile kwa njia yoyote ile. Hii ni kipengele cha malipo na latency, si mabadiliko ya tabia. Hii pia inamaanisha unaweza kuiwasha kwenye prompt inayofanya kazi bila kurudia tathmini zako.

Je, nilipe kwa ajili ya cache ya saa 1?

Pale tu ambapo trafiki yako ina mapengo marefu kuliko dakika 5 na kiwango chako cha hit kitafikia takriban asilimia 53. Uandishi wa 2x ni mara mbili ya hasara ya uandishi wa 1.25x unapokosa hit. Ingizo la dakika 5 hujionyesha upya kwenye kila hit, kwa hivyo trafiki thabiti huiweka hai kwa bei za usomaji bila kulipia muda mrefu wa kuishi.