Editor's Note: Marami sa mga gumagamit ng Claude Code ang nadarama na mabilis ang pagkawala ng mga token, at madaling mabawasan ang quota sa mahabang sesyon. Ngunit mula sa pananaw ng mga inhinyero ng Anthropic, ang tunay na nakakaapekto sa gastos ay hindi ang dami ng code na isinulat mo, kundi kung gumagamit ba ang sistema ng patuloy na paggamit ng mga nakaraang naprosesang konteksto.

Ang pangunahing mensahe ng artikulong ito ay kung paano gamitin ang caching mechanism upang i-save ang mga Token. Sa loob ng isang linggo, nag-reuse ang may-akda ng higit sa 300 milyong Token sa caching, na umabot sa 91 milyon sa isang araw. Dahil ang gastos sa caching ng Token ay lamang 10% ng karaniwang gastos sa input Token, ang 91 milyong cached Token ay katumbas lamang ng halos 9 milyong karaniwang Token sa pagkalkula. Ang kahusayan ng Claude Code sa mahabang sesyon ay hindi dahil libre ang modelo, kundi dahil matagumpay na na-reuse ang malaking bilang ng paulit-ulit na konteksto.

Ang susi sa prompt caching ay ang «huwag pansinin ang cache». Ang Claude Code ay nag-iimbak ng mga sistema, mga depinisyon ng kasangkapan, ang CLAUDE.md, mga patakaran ng proyekto, at kasaysayan ng pag-uusap sa mga antas; habang ang panimula ng susunod na kahilingan ay nananatiling pareho, maaaring direktang basahin ng Claude ang cache nang hindi kailangang muli pang prosesuhin ang buong konteksto. Ang Anthropic ay nagmomonitor din ng rate ng paggamit muli ng prompt cache, dahil hindi lamang ito nakakaapekto sa quota ng user kundi direktang nakakaapekto rin sa gastos ng serbisyo ng modelo at efficiency ng pagpapatakbo.

Hindi kailangang maunawaan ng karaniwang gumagamit ang lahat ng mga detalye sa ilalim, kailangan lang nilang maunawaan ang ilang mahahalagang gawi: huwag hayaang mawalan ng aktibidad ang session nang higit sa 1 oras; gawin ang session handoff kapag nagbabago ng gawain; iwasan ang madalas na pagbabago ng model; isama ang mga malalaking dokumento sa Projects kaysa paulit-ulit na i-paste sa usapan.

Hindi ito tungkol sa pag-save ng Token, kundi isang paraan ng paggamit ng Claude Code na mas malapit sa pag-iisip ng isang inhinyero: gamitin ang konteksto bilang pagpapamahala ng mga asset, panatilihin ang paggamit muli ng cache, at iwasan ang paulit-ulit na pagkalkula sa mahabang sesyon.

Ang sumusunod ay ang orihinal:

Naiipon ko ang 300 milyong Token sa linggong ito, 91 milyon sa isang araw, higit sa 300 milyon sa isang linggo.

Hindi ko binago ang anumang setting. Ito ay nagtatrabaho nang maayos sa background ang prompt caching.

Ngunit nung unawain ko nang husto kung ano ang cache at paano maiiwasan ang pagpaputol nito, mas matagal ang aking session sa parehong limitasyon ng paggamit. Kaya, ito ang isang 80/20 guide sa pag-cache ng Claude Code, na walang malalim na detalye sa antas ng API.

TL;DR

Ang gastos sa pag-cache ng Token ay lamang 10% ng gastos sa karaniwang input na Token. Ang 91 milyong cache na Token, ang tunay na pagkaltas ay katumbas ng halos 9 milyong Token.

Ang TTL ng cache para sa subscription na bersyon ng Claude Code ay 1 oras; ang default ng API ay 5 minuto; ang Sub-agent ay palaging 5 minuto.

Ang cache ay nahahati sa tatlong antas: sistema, proyekto, at diyalogo.

Ang pagpapalit ng model sa gitna ng sesyon ay magpapabagsak sa cache, kabilang ang pagpapagana ng mode na «opus plan».

Paano ba nakakalkula ang cache?

Ang bawat cached Token ay may gastos na 10% ng karaniwang input Token.

Kaya, kapag ipinapakita ng aking dashboard na 91 milyong Token ang naka-cache sa isang araw, ang tunay na pagkakaltas ay katumbas lamang ng pagproseso ng 9 milyong Token. Ito ang dahilan kung bakit habang ginagamit ang Claude Code nang matagal, mas maraming pakiramdam na ang sesyon ay 'free' na lumalawak kumpara sa walang cache.

May dalawang numero sa dashboard na dapat pansinin:

Cache create: Isang isang-time cost na nagaganap habang isinusulat ang nilalaman sa cache. Ito ay magiging epektibo sa susunod na pag-uusap.
Cache read: Mga Token na muling ginamit ni Claude mula sa cache, tulad ng iyong CLAUDE.md, mga depinisyon ng kasangkapan, at mga nakaraang mensahe. Mas mura ng 10 beses kaysa sa pagtrato nito bilang bagong input.

Kung mataas ang iyong Cache read number, ibig sabihin ay epektibong nagagamit mo ang cache; kung mababa ito, ibig sabihin ay bumabayad ka muli at muli para sa magkakaparehong konteksto.

Ang isang pahayag ni Thariq mula sa Anthropic ang nag-iwan ng malalim na epekto sa akin: “Totoo naming sinusubaybayan ang hit rate ng prompt cache, at kapag mababa ang hit rate, maaaring mag-trigger ng alert, o kaya’y ipahayag ang isang SEV-level incident.”

Isinulat niya ang isang napakagandang X article. Kapag mataas ang cache hit rate, mangyayari ang apat na bagay nang sabay-sabay: mas mabilis ang pakiramdam ni Claude Code, bumababa ang gastos sa serbisyo ni Anthropic, mas matagal ang iyong subscription quota, at mas realistiko ang mga mahabang sesyon ng pag-code.

Ngunit kung mababa ang accuracy rate, lahat ay magkakaroon ng pagkawala.

Kaya ang pagkikita ng parehong panig ay magkakatulad: nais ng Anthropic na mas mataas ang iyong cache hit rate, at nais din ng iyong sarili na mas mataas ang hit rate. Ang tanging nagpapabagal ay ilang simpleng gawi na tila walang halaga, ngunit maaaring mag-reset ng cache nang tahimik.

Paano nagtatagumpay ang cache sa bawat bilang ng usapan?

Ang cache ay nakasalalay sa prefix matching, o kaya ay “prefix matching”.

Huwag magsisiguro sa sobrang teknikal na detalye; kailangan mo lang maintindihan ang isang bagay: kung ang nakaraang nilalaman sa isang posisyon ay ganap na magkakapareho sa naka-cache, maaaring gamitin muli ni Claude ang mga cache token na ito.

Isang bagong sesyon, ganito ang pagkakasunod-sunod:

Ayon sa dokumentasyon ng Claude Code, karaniwang tumatakbo ang isang bagong sesyon ganito:

Hindi pa may cache sa unang pagkakataon. Ang system prompt, ang iyong project context (tulad ng CLAUDE.md, memory, at mga patakaran), at ang iyong unang mensahe ay muling pagsasamantalahan at isusulat sa cache.

Ikalawang pag-uusap: Ang lahat ng nilalaman sa unang pag-uusap ay naka-cache na. Kailangan lang ni Claude na tratuhin ang iyong bagong sagot at ang susunod na mensahe. Mas mababa ang gastos sa pag-uusap na ito.

Ikatlong pag-uusap: Parehong lohika. Ang mga nakaraang pag-uusap ay nananatili sa cache, at ang pinakabagong pag-uusap lamang ang kailangang muli pang penelosin.

Ang cache mismo ay maaaring hatiin sa tatlong antas:

Mula sa X post ni Thariq:

System layer: Kasama ang mga pangunahing utos, depinisyon ng mga kasangkapan (read, write, bash, grep, glob), at istilo ng output. Ang layer na ito ay global na cache.

Project layer: Kasama ang CLAUDE.md, memory, at mga patakaran ng proyekto. Ibinabawas ang layer ayon sa proyekto.

Layer ng Pakikipag-uusap (Conversation): Kasama ang mga sagot at mensahe, na lalaki habang tumutuloy ang bawat round ng pakikipag-uusap.

Kung may pagbabago sa anumang bahagi ng sistema o proyekto sa gitna ng sesyon, kailangan mong i-cache muli ang lahat ng mga ito mula sa simula. Ito ang pinakamahal na operasyon. Isipin mo ito: nasa ika-16 na mensahe ka na, tapos biglang nagbago ang system prompt, o nag-stop ng isang oras sa gitna — ang lahat ng mga Token mula sa unang mensahe ay kailangang muli pang prosesuhin.

1 oras at 5 minuto ng kalituhan

Ito ang pinakamadaling maliitin.

Claude Code subscription: ang default na TTL ay 1 oras.

Claude API: Ang default na TTL ay 5 minuto. Maaari mong gawing mas mataas ang gastos upang itaas ito sa 1 oras.
Anumang sub-agent sa anumang plano: palaging 5 minuto.

Web chat sa Claude.ai: Walang opisyal na dokumentasyon. Maaaring pareho sa subscription version, ngunit hindi pa ako nakakatotoo.

Ilang buwan na ang nakalipas, marami ang nagsasalita tungkol sa mabilis na pagkawala ng kanilang subscription quota sa Claude. Noong panahong iyon, may ilan na naniniwala na tinurunko nang lihim ni Anthropic ang TTL mula sa 1 oras patungo sa 5 minuto nang walang abiso sa mga user. Ngunit hindi totoo ito—ang TTL ng Claude Code ay nananatiling 1 oras.

Ang problema ay ang mga dokumentasyon ng Claude Code at API ay hiwalay, at ang dalawa ay ganap na iba’t ibang bagay, kaya nagkakaroon ng maraming kalituhan.

Kung ikaw ay nagpapatakbo ng malaking bilang ng Sub-agent workflows, o direktang gumagamit ng API, mahalaga ang numero na 5 minuto. Ngunit para sa 95% ng mga user ng Claude Code, ang tanging bagay na dapat mong pagtuunan ng pansin ay ang 1-oras na window lamang.

Tatlong karaniwang gawi na nakakapalipat sa 95% ng mga gumagamit

Ang mga sumusunod ay ang mga bahaging tunay na kapaki-pakinabang sa aking pang-araw-araw na paggamit.

Kung nagkakaroon ka na ng higit sa isang oras na walang gawain, ang mga nakaraang nilalaman ay karamihan ay nasa expiration na sa cache. Ang iyong susunod na mensahe ay magbabago ng cache. Sa ganitong sitwasyon, mas mababa ang gastos kung gagawin mo ang malinaw na pagpapasa at magsisimula ng bagong sesyon kaysa magpatuloy sa pagpapalit ng isang naging 'malamig' na nakaraang usapan.

Ang /compact o /clear ay nagpapabagsak ng cache, kaya mas mabuti na i-reset ito nang tama sa point na ito.

Gumawa ako ng isang session handoff skill upang palitan ang /compact. Ito ay nagpapaliwanag kung ano na ang natapos natin, anong mga desisyon pa ang naka-antay, anong mga file ang pinakamahalaga, at kung saan dapat tayong magpatuloy. Pagkatapos, ipinapatawag ko ang /clear at isinusulat ko ang summary na ito, kaya maaari naming tuloy-tuloy ang pag-unlad nang parang walang paghinto.

Ang komando na compact ay minsan ay mabilis din. Ang handoff skill na ito ay karaniwang natatapos sa loob ng isang minuto.

Hindi gaanong detalyado ang pormal na paliwanag ng cache mechanism sa Claude.ai, ngunit malinaw na iba ang pinagpapahusay ng Projects kaysa sa karaniwang mga serye ng usapan. Kaya, kung gagawin mong i-paste ang isang malaking dokumento, mas mabuti na ilagay ito sa Project kaysa direktang i-paste sa usapan.

Ano ang mga pagkilos na nagpapabagsak ng cache nang tahimik?

May ilang bagay na magrereset sa buong cache nang walang malinaw na paalala.

Magpalit ng modelo: Dahil sa cache na nakadepende sa pagkakatugma ng prefix, at bawat modelo ay may sariling cache, ang bawat pagpalit ng modelo ay magdudulot ng pagbasa muli ng buong kasaysayan nang walang cache hit sa susunod na request.

Ang mode na «Opus plan»: Ginagamit ang Opus sa pagpaplano at ang Sonnet sa pagpapatupad. Ito ay inirerekomenda ko na dati sa ilang video tungkol sa pag-optimize ng token, at may dahilan kung bakit. Ngunit kailangan mong maunawaan na bawat pagbabago ng plan ay isang pagbabago ng modelo, na nangangahulugan na kailangang muling itayo ang cache. Sa mahabang panahon, nakakatulong pa rin ito upang palawigin ang quota ng session, ngunit kailangan mong malaman kung ano ang nangyayari sa ilalim.

Maaaring i-edit ang CLAUDE.md sa gitna ng sesyon: hindi agad makikita ang pagbabago, kailangan ang susunod na pag-restart para maimplimenta. Kaya, ang kasalukuyang nagpapatakbo na cache ay hindi maapektuhan.

Ang screenshot na ipinakita ko ay galing sa isang token dashboard.

Isang simpleng GitHub repository. Ibinibigay mo ang link sa Claude Code, at ito ay magde-deploy sa lokal na localhost, at babasahin nito ang lahat ng iyong nakaraang session record, hindi mula sa blank state. Agad mong makikita ang data ng daily input, output, cache create, at cache read.

Subalit may isang bagay na dapat tandaan: ang dashboard na ito ay nagtatantiya ng Token data sa lokal na device. Kung ikaw ay magpapalit mula sa desktop sa laptop, ang mga numero ay hindi magkakatulad. May sariling set ng statistical view bawat device.

Summary

Ang prompt caching ay isang bagay na maaaring pag-aralan nang malalim. Mas kompletong ipinaliwanag ni Thariq sa kanyang artikulo; kung gusto mong makita ang buong larawan, worth it basahin.

Ngunit hindi mo kailangang lubos na maintindihan ang lahat ng detalye upang makakuha ng benepisyo. Kailangan mo lang malaman ang pinakamahalagang 80/20: mas mura ang cache Token nang 10 beses kaysa sa karaniwang Token; ang TTL ng Claude Code ay 1 oras; ang pagpapalit ng model ay magpapabagsak sa cache; ang paggawa ng malinaw na pagpapasa sa pagitan ng mga gawain ay karaniwang mas mabuting pagsisikap kaysa sa pagpapatuloy sa isang lumang sesyon hanggang sa ito ay «mag-expire».