Paano Talaga Mga Inhinyero ng Anthropic ay Nagliligtas ng Mga Token
May-akda: Nate Herk
Isinalin ni Peggy, BlockBeats

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 kung gaano karaming code ang isinulat mo, kundi kung gumagamit ba ang sistema ng patuloy na paggamit ng mga naka-process na 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 nangangahulugan ng 91 milyong caching Token sa isang araw. Dahil ang gastos sa caching Token ay lamang 10% ng karaniwang input Token, ang 91 milyong caching Token ay katumbas lamang ng halos 9 milyong karaniwang Token sa pagkalkula. Ang pagiging mas "matibay" ng Claude Code sa mahabang sesyon ay hindi dahil libre ang modelong gumagana, kundi dahil matagumpay na na-reuse ang malaking dami ng paulit-ulit na konteksto.

Ang susi sa prompt caching ay ang «hindi pagpapahinto sa 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 mga panimula ng susunod na kahilingan ay nananatiling pareho, maaaring direktang basahin ng Claude ang cache nang hindi muling prosesuhin ang buong konteksto. Ang Anthropic ay nagmomonitor din ng rate ng paggamit muli ng prompt cache, dahil ito ay hindi lamang nakakaapekto sa quota ng user kundi direktang nakakaapekto rin sa gastos ng serbisyo ng modelo at efisiyensiya ng pagpapatakbo.

Hindi kailangang maintindihan ng karaniwang gumagamit ang lahat ng mga detalye sa ilalim, kailangan lang nilang maunawaan ang ilang mahahalagang gawi: huwag hayaan ang session na walang gawain nang higit sa 1 oras; gawin ang session handoff kapag nagbabago ng gawain; iwasan ang madalas na pagpapalit ng model; isama ang 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 na teksto:

Nakatipid ako ng 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 ang prompt caching na gumagana nang maayos sa background.

Ngunit nang unawain ko nang husto kung ano ang cache at kung paano maiiwasan ang pagpapabagsak nito, mas matagal ang aking session sa parehong bilang ng credits. Kaya dito ay isinama ang 80/20 beginner’s guide sa Claude Code prompt caching, nang hindi kinabibilangan ng mga detalye sa antas ng API.

TL;DR

Ang gastos sa pag-cache ng Token ay lamang 10% ng gastos sa karaniwang pag-input ng Token. Ang 91 milyong cache na Token, ang tunay na pagkalkula 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 cache na Token ay may gastos na 10% ng karaniwang input na 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 parang libre ang pagpapalawig ng session kumpara sa walang cache.

May dalawang numero sa dashboard na dapat tandaan:

Cache create: Isang isang-time cost na nabubuo kapag 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 tukoy ng kasangkapan, at mga nakaraang mensahe. Mas mura 10 beses kaysa pagtratuhin bilang input.

Kung mataas ang iyong Cache read number, ibig sabihin ay epektibong nagpapakilala ka ng cache; kung mababa ang bilang na ito, ibig sabihin ay nagbabayad ka muli at muli para sa magkakaparehong konteksto.

May isang pahayag si Thariq mula sa Anthropic na nag-iwan ng malalim na epekto sa akin: «Totoo naming sinusubaybayan ang hit rate ng prompt cache, at kapag mababa ang hit rate, magsisimula ang alerto, kahit na isasabuhay ang 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 credit, at mas realistiko ang mga mahabang coding session.

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

Kaya ang insentibo ng parehong panig ay magkakatulad: nais ng Anthropic na mas mataas ang iyong cache hit rate, at nais mo rin ito. Ang tanging nagpapabagal ay ilang simpleng gawi na tila walang halaga, ngunit nagpapareset ng cache nang tahimik.

Paano naglalago ang cache sa bawat round ng pag-uusap?

Ang cache ay nakabatay sa prefix matching, o kung saan ay "prefix matching".

Huwag masyadong magpapaloob sa mga teknikal na detalye; kailangan mo lang maintindihan ang isang bagay: kung ang nakaraang nilalaman sa isang posisyon ay tugma nang buo sa naka-cache na nilalaman, maaari ng gamitin muli ni Claude ang mga naka-cache na Token na ito.

Isang bagong sesyon, ganito ang pagkakasunod-sunod nito:

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 pagkakataon sa pag-uusap: Ang lahat ng nilalaman sa unang pagkakataon ay naka-cache na. Kailangan lang ni Claude na tratuhin ang iyong bagong sagot at ang susunod na mensahe. Mas mababa ang gastos sa pagkakataong 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 prosesuhin.

Ang cache mismo ay maaaring hatiin sa tatlong antas:

Mula sa X post ni Thariq:

System layer: Kasama ang mga pangunahing utos, mga 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-usap (Conversation): Kasama ang mga sagot at mensahe, na lalawak habang tumataas ang bawat round ng pakikipag-usap.

Kung may pagbabago sa anumang bahagi ng sistema o proyekto sa gitna ng sesyon, kailangang i-cache muli ang lahat ng nilalaman 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 nagsara ang sesyon nang isang oras — 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 ibayad ang mas mataas na gastos upang itaas ito sa 1 oras.
Anumang sub-agent sa anumang plano: laging 5 minuto.

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

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

Ang problema ay ang pagkakahiwalay ng dokumentasyon ng Claude Code at API, na pareho ay magkakaibang 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 tandaan ay ang 1-oras na window.

Tatlong karaniwang gawi na nakakapalibot sa 95% ng mga user

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

Kung naka-free ka na ng higit sa isang oras, ang mga nakaraang mensahe ay karamihan ay nabigo na sa cache. Ang iyong susunod na mensahe ay magbabangon muli ng cache. Sa ganitong sitwasyon, mas mababa ang gastos kung gagawin mo ang malinaw na pagpapasa at magsisimula ng bagong sesyon kaysa magpatuloy sa pagbabalik 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 para palitan ang /compact. Ipinapaliwanag nito kung ano na ang natapos, anong mga desisyon pa ang naka-antay, anong mga file ang pinakamahalaga, at kung saan dapat magpatuloy. Pagkatapos, ipinapatawag ko ang /clear at isinusulat ko ang summary na ito, kaya maaari kong magpatuloy nang parang walang paghinto.

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

Hindi detalyadong ipinapaliwanag ng Claude.ai ang mekanismo ng cache, ngunit malinaw na iba ang pag-optimize ng Projects kaysa sa karaniwang mga serye ng pag-uusap. Kaya, kung gagawin mong i-paste ang isang malaking dokumento, mas mabuti na ilagay ito sa Project kaysa i-paste nang direkta sa pag-uusap.

Ano-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-optimiza 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 magiging epektibo ang pagbabago, kailangan ang susunod na pag-restart para ma-apply. Kaya, ang kasalukuyang nagpapatakbo na cache ay hindi aapektuhan.

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

https://github.com/nateherkai/token-dashboard

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

Ngunit 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 statistikal na pananaw bawat device.

Buod

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 makatanggap 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”.

[Original link]

Klik para malaman ang mga posisyon na hinahanap ng BlockBeats

Maligayang pagdating sa opisyal na komunidad ng BlockBeats:

Telegram subscription group: https://t.me/theblockbeats

Telegram group: https://t.me/BlockBeats_App

Twitter official account: https://twitter.com/BlockBeatsAsia