Ni Claude prompt caching: kailan ito sulit?
Cache write ay 1.25x at read ay 0.1x ng base input price, kaya sulit ang prefix sa ikalawang gamit. Alamin ang break-even at patunayan sa API.
Ang halaga ng prompt caching bago ito makatipid
Hinahayaan ng prompt caching na gamitin muli ni Claude ang simula ng iyong prompt sa halip na basahin itong muli sa bawat call. Nakabatay ang buong desisyon sa dalawang multiplier ng base input price ng iyong model. Noong August 2026, ang cache write ay nagkakahalaga ng 1.25x ng base input para sa 5 minute lifetime, o 2x para sa 1 hour lifetime. Ang cache read ay nagkakahalaga ng 0.1x. Pareho ang mga multiplier na ito sa buong model list, kaya hindi nagbabago ang break-even sa ibaba kapag nagbago ang per-token price.
Ang kapalit ay surcharge ngayon kapalit ng discount sa susunod. Isang beses kang magbabayad nang mas mataas para i-store ang isang prefix. Ang bawat susunod na request na nagsisimula sa eksaktong parehong bytes ay magbabayad lamang ng ikasampu ng normal na input price para sa bahaging iyon. Kung hindi kailanman gagamitin muli ang isang prefix habang aktibo ang lifetime nito, nagbayad ka ng 25 percent na dagdag nang walang napala.
Ang break-even sa isang linya ng algebra
Itakda ang B bilang base input cost ng prefix kung ipapadala mo ito nang walang cache. Kung walang caching, ang N requests ay nagkakahalaga ng N na beses ng B. Sa 5 minute cache, isinusulat ng unang request ang prefix sa halagang 1.25B, at binabasa ito ng iba pang N minus 1 requests sa halagang 0.1B. Ihambing ang dalawang halaga at makukuha ang 0.9N = 1.15, kaya N = 1.28. Mas mura na agad ang ikalawang request kaysa sa hindi paggamit ng cache.
Ulitin ito gamit ang 2x write ng 1 hour cache at makukuha ang 0.9N = 1.9, kaya N = 2.11. Kailangan ng long cache ng dalawang read bago ito mag-break even. Kaya hindi ito ang default na pagpipilian.
Ipinapakita ng chart sa ibaba ang halaga nito para sa 20,000 token prefix sa Claude Opus 5, na may base input rate na $5 bawat million tokens noong August 2026. I-scale ang bawat figure nang 0.6 para sa modelong nagkakahalaga ng $3 bawat million. Hindi nagbabago ang hugis ng curve.
The data behind this chart
[
{
"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"
}
]Ang isang request lamang ay nagkakahalaga ng $0.10 kapag walang cache at $0.125 kapag naka-cache. Kaya purong lugi ang pag-cache ng prompt na minsan lang ginagamit. Sa ikalawang request, ang 5 minute cache ay nasa $0.135 kumpara sa $0.20. Mas mataas pa rin ang halaga ng 1 hour cache sa puntong iyon: $0.21 kumpara sa parehong $0.20. Malalampasan lamang nito ang uncached line sa ikatlong request: $0.22 kumpara sa $0.30. Sa 20 requests, ang agwat ay $2.00 kumpara sa $0.315.
Nire-refresh rin ng cache hit ang entry. Kaya tinatawag na cache hits and refreshes ang column na iyon sa published price table. Dahil dito, maaaring manatiling buhay nang walang takdang hangganan ang 5 minute entry ng isang busy endpoint sa read prices. Samantala, nagkakaroon lamang ng saysay ang 2x write ng 1 hour lifetime kapag may tunay na pagitan ang traffic.
Ang Gastos ng Mababang Hit Rate
May mga request na hindi nagkaka-cache hit sa aktuwal na traffic. Kapag hindi nag-hit sa cache ang isang request pero may dala pa ring breakpoint, sinisingil ito bilang write. Kaya ang tamang pagmomodelo ay ang pagkalkula ng gastos batay sa hit rate. Ipinapakita ito ng chart sa ibaba para sa 1,000 request, na bawat isa ay may parehong 20,000-token prefix.
The data behind this chart
[
{
"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"
}
]Sa 0 percent na hit rate, magbabayad ka ng $125.00 sa halip na $100.00, at dinodoble ng 1 hour cache ang bill sa $200.00. Kapag sinolve ang 1.25 minus 1.15h = 1, nagsisimulang makatipid ang 5 minute cache sa hit rate na humigit-kumulang 22 percent. Kaya sa 25 percent, lumalabas na agad ang $96.25. Sa parehong pagkalkula para sa 2x write, humigit-kumulang 53 percent ang kailangan para sa 1 hour cache. Kaya sa 50 percent na hit rate, nagkakahalaga pa rin ito ng $105.00, na mas mataas sa uncached na halaga. Sa 90 percent, umaabot ang mga ito sa $21.50 at $29.00. Sa 99 percent, umaabot ang short cache sa $11.15, na malapit sa pinakamababang halagang isang ikasampu ng uncached na presyo.
Ang hit rate ang kailangang i-instrument, dahil ito lamang ang input na makokontrol mo kapag naitakda na ang laki ng prefix.
Aling prefix ang sulit lagyan ng breakpoint
Ang isang request ay maaaring maglaman ng hanggang apat na cache breakpoint, kaya ang tanong ay kung aling mga block ang nararapat lagyan nito. Ang mga kandidato ay mga block na eksaktong magkakapareho sa bawat call at sapat ang laki para maging makabuluhan. Ipinapakita ng chart sa ibaba ang halaga ng apat na karaniwang anyo sa 1,000 request, na may 90 percent hit rate sa 5 minute cache.
The data behind this chart
[
{
"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"
}
]Ang payak na 2,000 token system prompt ay nakakatipid ng $7.85 sa bawat 1,000 request kumpara sa $10.00 kapag walang cache. Makabuluhan itong halaga kapag mataas ang volume, pero hindi ito ang dahilan kung bakit kawili-wili ang caching. Idagdag ang tool definitions at magiging 8,000 tokens ito, na may matitipid na $31.40. Ang 25,000 token policy document na tinatanungan sa bawat request ay nakakatipid ng $98.12. Ang huling row ang nagbabago sa architecture: ang 120,000 tokens ng codebase o transcript context ay nagkakahalaga ng $600.00 kapag walang cache at $129.00 kapag naka-cache, kaya $471.00 ang natitipid.
Nakasalalay ang matitipid sa laki ng prefix at sa hit rate, at wala nang iba. Dahil dito, nagbabago rin kung ano ang sulit ilagay sa prompt: ang aktuwal na halaga ng isang milyong Claude token ay bumababa sa isang-sampu ng nakalistang presyo para sa anumang ipinapadala mo nang higit sa isang beses.
Ano ang hitsura nito sa buwanang bill
Kinukuha ng chart sa ibaba ang 8,000 token prefix mula sa itaas, kasama ang isang system prompt at mga tool definition, sa 90 percent na hit rate, at ina-adjust ito para sa mga buwanang request volume.
The data behind this chart
[
{
"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"
}
]Sa 10,000 request bawat buwan, ang matitipid ay $314.00, ang diperensya sa pagitan ng $400.00 at $86.00. Sa 100,000 request, ito ay $3,140.00. Sa isang milyong request, ang uncached input bill ay $40,000.00, at inaalis ng caching ang $31,400.00 mula rito. Input tokens lamang ang kasama rito. Hiwalay ang pricing ng output, at walang epekto rito ang caching. Tandaan ito bago ka mangako sa sinuman ng 90 percent na bawas sa bill. Ang caching ay bahagi ng mas malawak na mga gawain sa pagpapanatiling kontrolado ng bill ng AI agent sa isang VPS.
Paano mapapatunayang gumagana ang cache
Huwag umasa sa disenyo lamang. Basahin ang usage block sa response. Iniuulat ng bawat Messages API (application programming interface) reply ang mga cached token na isinulat nito, ang mga cached token na binasa nito, at ang mga bagong token na kinailangan nitong i-process.
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)Patakbuhin ito nang dalawang beses gamit ang parehong document at ibang tanong. Sa unang call, non-zero ang cache_creation_input_tokens at zero ang cache_read_input_tokens. Sa ikalawang call, kabaligtaran ang resulta dahil nakita ang prefix. Binibilang lamang ng input_tokens ang mga token pagkatapos ng huling breakpoint, kaya maliit ito sa maayos na ikalawang call—karaniwan, ang bagong user message lamang. Parehong may bayad ang dalawang call dahil walang libreng tier ang Claude API, bagama't ang pair para sa 20,000-token prefix na may presyong nakasaad sa itaas ay humigit-kumulang labing-apat na sentimo.
Pareho ring pagsusuri mula sa shell, gamit ang request body na na-save sa 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'Ganito ang karaniwang ipinapakita ng maayos na ikalawang call:
{
"input_tokens": 42,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 20143,
"output_tokens": 187
}Isang linya ang nagbibigay ng tunay na resulta. Kung nananatili sa 0 ang cache_read_input_tokens sa bawat call, binabayaran mo ang 1.25x write sa bawat pagkakataon at wala kang natatanggap na cache hit.
Para sa 1 hour na lifetime, may time to live (TTL) ang breakpoint:
{
"type": "text",
"text": "your stable prefix",
"cache_control": {"type": "ephemeral", "ttl": "1h"}
}May automatic caching din: maglagay ng isang cache_control field sa top level ng request, at pagkatapos nito, ang API na ang mamamahala sa mga breakpoint habang lumalaki ang conversation. Kumokonsumo ito ng isa sa apat mong breakpoint slot. Magsimula rito. Gumamit ng explicit breakpoint kapag kailangan mong eksaktong tukuyin kung saan ilalagay ang boundary.
Ang ordering rule na sumisira sa hit rate
Tumutugma ang cache sa prefix byte for byte mula sa simula ng request. Binubuo ang request sa fixed na pagkakasunod-sunod: tools, pagkatapos ay system, at pagkatapos ay messages. Kapag may nagbago sa isang level, nagiging invalid ang level na iyon at lahat ng kasunod nito. Kapag nag-edit ka ng isang tool description, nagiging invalid pati ang system prompt at buong message history, kahit hindi mo binago ang mga ito.
Nagreresulta ito sa isang rule na walang exception. Anumang nagbabago sa pagitan ng mga call ay dapat ilagay pagkatapos ng lahat ng hindi nagbabago.
Karaniwang sanhi nito ang timestamp. Ang linyang may Current time: 2026-08-03T14:07:11Z sa itaas ng system prompt ay garantisadong magbibigay ng 0 percent hit rate, dahil nag-iiba ang prefix hash sa bawat call at walang naunang entry ang kailanman makatutugma rito. Ilipat ito sa user message, sa pinakahuli. Ganito rin ang epekto ng session identifier o per-request nonce, at ganoon din ang solusyon. Ang retrieved documents na nag-iiba sa bawat request ay dapat ding ilagay pagkatapos ng cached block. Kung hindi, itinutulak ng mga ito sa likod ng nagbabagong boundary ang lahat ng stable token.
Ang ikalawang sanhi ay ang paglalagay ng breakpoint sa block na nagbabago. Sa breakpoint nagaganap ang cache writes. Kaya kung naiiba ang block sa bawat pagkakataon, walang stable na content ang nase-save. Sa lookback, mga entry lamang na isinulat ng mga naunang request sa sarili nilang nagbabagong breakpoint ang makikita. Ilagay ang cache_control sa huling block na magkapareho ang content sa lahat ng request.
Ang ikatlong sanhi ay parameter change na hindi mo itinuturing na prompt content. May ibang cache ang bawat model. Kapag binago ang tool choice, nagiging invalid ang cache mula sa system level pataas. Kapag nagdagdag o nag-alis ka ng tool, nagiging invalid ang lahat.
Ang minimum prefix at ang tahimik na walang epekto
Hindi naka-cache ang prefix na mas maikli kaysa sa minimum ng model, at walang magsasabi nito sa iyo. Walang error o warning. Matagumpay ang request, at parehong 0 ang counter. Noong August 2026, ang mga minimum na inilathala ay:
- 512 tokens sa Claude Opus 5 at Claude Fable 5
- 1,024 tokens sa Claude Sonnet 5 at Claude Opus 4.8
- 4,096 tokens sa Claude Haiku 4.5
Kung parehong 0 ang counter sa isang request na sa tingin mo ay naka-cache, suriin muna ang haba ng prefix bago ang iba pang bagay. Ito rin ang dahilan kung bakit hindi awtomatikong pinakamura para sa caching workload ang pinakamurang model. Kailangan ng Haiku 4.5 ng prefix na walong beses na mas mahaba kaysa sa Opus 5 bago tuluyang gumana ang caching, kaya naka-cache ang 2,000-token system prompt sa isa ngunit tahimik itong binabalewala sa isa pa.
Saan nagca-cache ang Claude Code para sa iyo, at saan hindi ito makatutulong
Nina-cache ng Claude Code ang sarili nitong prefix. Nasa unahan ng bawat request ang system prompt at mga tool definition at hindi nagbabago ang puwesto ng mga ito, kaya isang beses lamang isinusulat ang mga ito at pagkatapos ay binabasa na lang sa natitirang bahagi ng session. Dahil dito, mas mababa nang malaki ang per-turn na gastos ng mahabang session kaysa sa ipinahihiwatig ng laki ng context. Makikita rin ito sa mga counter na inilalarawan sa kung paano iniuulat ng Claude Code ang paggamit ng token.
Hindi ito makatutulong kapag may binago malapit sa simula ng context. Append-only ang conversation history, kaya ang mga karaniwang bagong turn ay nagdaragdag sa prefix na naka-cache na. Kapag nag-edit ka ng file na maagang binasa sa session, nagbabago ang content sa gitna ng prefix na iyon, at kailangang isulat muli ang bawat token pagkatapos ng pagbabago. Ganito rin ang nangyayari kapag mahaba ang idle gap, dahil nag-e-expire ang entry at kailangang bayaran ng susunod na turn ang buong write. Hindi bug ang alinman sa mga ito. Pareho lamang itong eksaktong epekto ng prefix rule.
Kung sarili mong client ang isinusulat mo, gamitin ang layout mula sa unang request sa halip na i-retrofit ito: buuin ang call gaya ng ginagawa sa unang Claude API app sa isang VPS, kung saan nauuna ang stable blocks at nasa hulihan ang volatile blocks.
Mga failure mode at kung ano ang makikita mo
Write ang bawat call. Hindi zero ang cache_creation_input_tokens sa bawat request, habang nananatiling 0 ang cache_read_input_tokens. May nagbabago sa isang bahagi ng request bago o sa breakpoint sa pagitan ng mga call. I-print ang unang 200 character ng binuong prefix sa dalawang magkasunod na request at ihambing ang mga ito nang manu-mano.
Parehong 0 ang dalawang counter. Mas maikli sa minimum ng model ang prefix, o hindi nakarating sa API ang field na cache_control. Bilangin muna ang mga token ng prefix, pagkatapos ay i-log ang aktuwal na request body na ipinadala mo.
Gumagana ang reads, pagkatapos ay tumitigil. May magkakasunod na hit, kasunod ang isang write, at pagkatapos ay muli ang mga hit. Mas mahaba sa lifetime ang pagitan ng mga request. Tanggapin ang write, o lumipat sa 1 hour TTL kapag nakumpirma mong lumampas sa 53 percent ang hit rate.
Bumababa ang hit rate pagkatapos ng deploy. Na-edit ang tool description o nagbago ang model. Parehong nag-i-invalidate sa buong prefix. Asahan ang isang magastos na round ng writes pagkatapos ng bawat deploy na nakaaapekto sa prompt.
Tumaas ang bill pagkatapos mong i-enable ang caching. Mas mababa sa break-even ang hit rate mo. Sa mas mababa sa humigit-kumulang 22 percent para sa 5 minute cache, mas mura ang pagpapadala ng prefix nang walang cache. Gayundin, sa mas mababa sa humigit-kumulang 53 percent para sa 1 hour cache.
FAQ
Ilang beses kailangang gamitin muli ang isang prompt bago maging sulit ang caching?
Isang beses, sa 5 minute cache. Ang write ay nagkakahalaga ng 1.25x ng base input at ang read ay 0.1x, kaya ang N uncached request ay nagkakahalaga ng N, samantalang ang N cached request ay nagkakahalaga ng 1.25 plus 0.1 times N minus 1. Nagtatagpo ang dalawang halaga sa N = 1.28, kaya mas sulit na agad sa ikalawang request. Ang 1 hour cache ay may write cost na 2x at nagtatagpo sa N = 2.11, kaya kailangan nito ng dalawang read.
Bakit palaging zero ang cache_read_input_tokens?
Suriin muna ang prefix length: kapag mas mababa ito sa minimum ng model, 512 tokens sa Claude Opus 5 at 4,096 sa Claude Haiku 4.5 noong August 2026, tahimik na nilalaktawan ang caching at parehong 0 ang lumalabas sa dalawang counter. Kung sapat ang haba ng prefix, hanapin ang content na nagbabago sa pagitan ng mga call at nasa breakpoint o bago nito, gaya ng timestamp o session identifier sa system prompt. Kung gumagana dati ang mga counter at biglang tumigil, mas mahaba sa cache lifetime ang pagitan ng mga request.
Binabago ba ng prompt caching ang mga sagot ni Claude?
Hindi. Iniimbak ng cache ang processed form ng mga token na naipadala mo na, at pareho pa rin ang prompt na nakikita ng model. Feature ito para sa billing at latency, hindi pagbabago sa behaviour. Dahil dito, maaari mo itong i-enable sa gumaganang prompt nang hindi muling pinapatakbo ang iyong mga evaluation.
Dapat ba akong magbayad para sa 1 hour cache?
Tanging kapag may mga pagitan na mas mahaba sa 5 minutes ang iyong traffic at mananatiling humigit-kumulang 53 percent o mas mataas ang hit rate. Doble ang downside ng 2x write kumpara sa 1.25x write kapag walang hit. Nire-refresh ang 5 minute entry sa bawat hit, kaya napapanatili ito ng steady traffic sa read prices nang hindi kailanman nagbabayad para sa mas mahabang lifetime.