Bagaimana Jurutera Anthropic Sebenarnya Menjimatkan Token
Penulis asal: Nate Herk
Dikompilasi oleh Peggy, BlockBeats

Catatan editor: Banyak pengguna Claude Code merasakan secara langsung bahawa penggunaan Token terlalu cepat, dan sesi panjang mudah menghabiskan kuota. Namun, dari perspektif jurutera Anthropic, faktor yang benar-benar mempengaruhi kos bukanlah berapa banyak kod yang anda tulis, tetapi sama ada sistem terus menggunakan semula konteks yang telah diproses sebelumnya.

Inti artikel ini ialah bagaimana menggunakan mekanisme cache untuk menghemat Token. Penulis berjaya mengguna semula lebih 300 juta Token dalam seminggu, dengan jumlah cache harian mencapai 91 juta. Oleh kerana kos Token cache hanya 10% daripada Token input biasa, ini bermakna 91 juta Token cache sebenarnya dihitung sebagai kira-kira 9 juta Token biasa. Perbualan panjang Claude Code kelihatan lebih "tahan lama" bukan kerana model bekerja secara percuma, tetapi kerana konteks berulang yang besar berjaya diguna semula.

Kunci pengurangan cache prompt ialah «jangan ganggu cache». Claude Code akan menyimpan sistem prompt, definisi alat, CLAUDE.md, peraturan projek, dan sejarah perbualan dalam cache bertingkat; selama awalan permintaan seterusnya tetap konsisten, Claude boleh membaca cache secara langsung tanpa memproses semula keseluruhan konteks. Anthropic juga memantau kadar penggunaan semula cache prompt secara dalaman, kerana ia tidak hanya mempengaruhi kuota pengguna, tetapi juga secara langsung berkaitan dengan kos perkhidmatan model dan kecekapan operasi.

Untuk pengguna biasa, tidak perlu memahami semua butiran asas; cukup kuasai beberapa kebiasaan utama: jangan biarkan sesi ditinggalkan lebih daripada 1 jam; lakukan session handoff apabila menukar tugas; elakkan sering menukar model; masukkan dokumen besar ke dalam Projects, bukan sekadar melekatkan berulang-ulang ke dalam perbualan.

Artikel ini lebih berupa penyediaan kaedah penggunaan Claude Code yang lebih mendekati pemikiran jurutera, daripada sekadar membincangkan trik menghemat token: anggap konteks sebagai pengurusan aset, biarkan cache digunakan semula secara berterusan, dan kurangkan pengiraan berulang dalam sesi panjang.

Berikut ialah teks asal:

Saya berjimat 300 juta Token seminggu ini, 91 juta sehari, lebih daripada 300 juta dalam seminggu.

Saya tidak mengubah sebarang tetapan. Ini hanyalah cache prompt yang berfungsi dengan betul di latar belakang.

Tetapi setelah saya benar-benar memahami apa itu cache dan bagaimana mengelakkan "mengganggu" cache, sesi saya boleh berlangsung lebih lama dengan kuota penggunaan yang sama. Oleh itu, di sini disediakan panduan permulaan 80/20 untuk cache prompt Claude Code, tanpa melibatkan butiran mendalam pada peringkat API.

TL;DR

Kos penyimpanan cache Token hanya 10% daripada Token input biasa. 91 juta Token cache, kos sebenar dikenakan kira-kira setara dengan 9 juta Token.

TTL cache untuk versi berlangganan Claude Code adalah 1 jam; API secara lalai adalah 5 minit; Sub-agent sentiasa 5 minit.

Cache dibahagikan kepada tiga lapisan: lapisan sistem, lapisan projek, dan lapisan perbualan.

Pertukaran model semasa sesi akan merosakkan cache, termasuk mod yang dinyalakan «opus plan».

Bagaimana cara pengiraan caj penyimpanan sementara?

Setiap Token yang disimpan, kosnya adalah 10% daripada Token input biasa.

Jadi, apabila dashboard saya menunjukkan 91 juta Token telah menghentikan cache pada satu hari, sebenarnya caj yang dikenakan hampir setara dengan pemprosesan hanya 9 juta Token. Inilah sebabnya mengapa, berbanding tanpa cache, penggunaan jangka panjang Claude Code memberikan kesan sesi hampir「percuma」diperpanjang.

Dua nombor di dashboard perlu diperhatikan:

Cache create: Kos sekali jadi yang timbul apabila kandungan ditulis ke cache. Ia akan bermula berfungsi dalam perbualan seterusnya.
Pembacaan cache: Token yang digunakan semula dari cache oleh Claude, seperti CLAUDE.md anda, definisi alat, mesej sebelumnya, dll. Lebih murah 10 kali berbanding memproses semula sebagai input.

Jika nombor Cache read anda tinggi, ia menunjukkan anda sedang memanfaatkan cache secara efektif; jika nombor ini rendah, ia bermakna anda membayar berulang-ulang untuk konteks yang sama.

Thariq daripada Anthropic mengatakan satu perkara yang sangat meninggalkan kesan: "Kami sebenarnya memantau kadar kejayaan prompt cache, dan sekiranya kadar kejayaan terlalu rendah, ia akan memicu amaran, bahkan mengisytiharkan insiden tahap SEV."

Dia juga menulis satu artikel X yang sangat baik. Apabila kadar capaian cache tinggi, empat perkara berlaku serentak: Claude Code dirasakan lebih pantas, kos perkhidmatan Anthropic berkurang, kuota langgan anda kelihatan lebih tahan lama, dan sesi penulisan kod jangka panjang menjadi lebih realistik.

Tetapi jika kadar ketepatan sangat rendah, semua orang akan rugi.

Jadi, insentif kedua-dua belah sebenarnya selari: Anthropic ingin kadar kejayaan cache anda lebih tinggi, dan anda juga ingin kadar kejayaan cache yang lebih tinggi. Satu-satunya perkara yang benar-benar akan menghambat ialah beberapa kebiasaan kelihatan kecil yang secara perlahan-lahan menetapkan semula cache.

Bagaimana cache bertambah dalam setiap sesi perbualan?

Cache bergantung pada pencocokan awalan, iaitu «pencocokan awalan».

Jangan terperangkap dalam butiran teknikal yang terlalu mendalam, anda hanya perlu memahami satu perkara: selama kandungan sebelum kedudukan tertentu sama persis dengan kandungan yang telah disimpan dalam cache, Claude boleh semula gunakan Token cache ini.

Sesi baharu sekali, lebih kurang seperti ini berlaku:

Menurut dokumen Claude Code, sesi baru biasanya berjalan seperti ini:

Perbincangan pertama: Tiada cache sebelum ini. Petunjuk sistem, konteks projek anda (seperti CLAUDE.md, memori, peraturan), serta mesej pertama anda akan diproses semula dan disimpan ke dalam cache.

Sesi kedua: Semua kandungan dalam sesi pertama kini telah disimpan dalam cache. Claude hanya perlu memproses balasan baru anda dan mesej seterusnya. Kos sesi ini akan jauh lebih rendah.

Sesi ketiga: Logik sama. Perbincangan sebelumnya masih disimpan dalam cache, hanya interaksi terkini yang perlu diproses semula.

Cache itu sendiri boleh dibahagikan kepada tiga lapisan:

Dari artikel X Thariq:

Lapisan sistem (System layer): Termasuk arahan asas, definisi alat (read, write, bash, grep, glob), dan gaya output. Lapisan ini disimpan dalam cache global.

Lapisan projek (Project layer): Termasuk CLAUDE.md, memory, peraturan projek. Lapisan ini disimpan dalam cache mengikut projek.

Lapisan perbualan (Conversation): termasuk balasan dan mesej, yang akan terus bertambah sepanjang setiap putaran perbualan.

Jika sebarang perkara berubah pada peringkat sistem atau projek di tengah sesi, semua kandungan mesti disimpan semula dari awal. Ini adalah operasi yang paling «mahal». Bayangkan: anda sudah berbual hingga mesej ke-16, tiba-tiba petunjuk sistem diubah, atau sesi terhenti selama satu jam, maka semua Token dari mesej pertama perlu diproses semula.

Kebingungan antara 1 jam dan 5 minit

Ini adalah tempat yang paling mudah disalahfahami.

Versi langgan Claude Code: TTL lalai ialah 1 jam.

Claude API: TTL lalai ialah 5 minit. Anda boleh membayar kos yang lebih tinggi untuk meningkatkannya kepada 1 jam.
Sub-agent di bawah mana-mana rancangan: selalunya 5 minit.

Perbualan laman web Claude.ai: Tidak ada rekod rasmi. Mungkin sama seperti versi berlanggan, tetapi saya belum mengesahkan.

Beberapa bulan yang lalu, ramai orang mengeluh bahawa kuota langganan Claude habis terlalu cepat. Pada masa itu, ada yang menyangka bahawa Anthropic secara diam-diam telah mengurangkan TTL dari 1 jam kepada 5 minit tanpa memberitahu pengguna. Namun, kenyataannya tidak begitu; TTL Claude Code masih 1 jam.

Masalahnya ialah, dokumen Claude Code dan API dipisahkan, dan keduanya sebenarnya adalah dua perkara yang sama sekali berbeza, menyebabkan banyak kekeliruan.

Jika anda menjalankan alur kerja Sub-agent dalam jumlah besar, atau menggunakan API secara langsung, nombor 5 minit ini penting. Tetapi bagi 95% pengguna Claude Code, yang perlu diperhatikan sebenarnya hanyalah jendela 1 jam.

Tiga kebiasaan yang menjangkau 95% pengguna

Berikut ini adalah bahagian-bahagian yang saya rasa benar-benar berguna dalam penggunaan harian.

Jika anda telah tidak aktif selama lebih dari satu jam, kandungan sebelumnya kebanyakannya telah tamat tempoh dalam cache. Mesej seterusnya anda akan membina semula cache. Dalam kes ini, lebih rendah kos untuk melakukan serahan yang jelas dan memulakan sesi baharu, berbanding meneruskan sesi lama yang sudah 「sejuk」.

/compact atau /clear sudah menghancurkan cache, jadi lebih baik gunakan titik ini untuk menetapkan semula secara sebenar.

Saya membuat kemahiran serah sesi sendiri untuk menggantikan /compact. Ia akan meringkaskan apa yang telah kami selesaikan, keputusan apa yang masih tertunda, fail-fail mana yang paling penting, dan di mana sepatutnya kami meneruskan seterusnya. Kemudian saya jalankan /clear, tampal ringkasan ini, dan boleh teruskan maju seolah-olah tiada gangguan.

Perintah compact kadang-kadang berjalan perlahan. Manakala kemahiran handoff ini biasanya selesai dalam masa kurang dari satu minit.

Mekanisme cache di Claude.ai tidak mempunyai penjelasan rasmi yang terperinci, tetapi Projek jelas menggunakan pendekatan pengoptimuman yang berbeza berbanding talian perbualan biasa. Oleh itu, jika anda ingin melekatkan dokumen yang sangat besar, lebih baik letakkannya ke dalam Projek, bukan secara langsung dimasukkan ke dalam perbualan.

Apakah tindakan yang secara senyap merosakkan cache?

Beberapa perkara akan menetapkan semula semua cache tanpa pemberitahuan yang jelas.

Tukar model: Kerana cache bergantung pada kecocokan awalan, dan setiap model mempunyai cache sendiri. Setiap kali menukar model, permintaan seterusnya akan membaca sejarah penuh semula tanpa sebarang cache berjaya.

Modus "Opus plan": Tetapan ini akan menggunakan Opus pada peringkat perancangan dan Sonnet pada peringkat pelaksanaan. Saya sebelumnya merekomendasikannya dalam beberapa video pengoptimuman token, dan ada sebabnya. Namun, perlu dipahami bahawa setiap peralihan plan pada dasarnya adalah peralihan model, yang bermakna cache perlu dibina semula. Dari perspektif jangka panjang, ia masih membantu memperpanjang kuota sesi, tetapi anda perlu memahami apa yang sebenarnya berlaku di lapisan bawah.

Anda boleh mengedit CLAUDE.md semasa sesi: perubahan ini tidak akan berkesan segera, tetapi akan diterapkan semasa restart seterusnya. Oleh itu, cache yang sedang berjalan tidak akan terjejas.

Skrin yang saya tunjukkan sebelum ini berasal daripada sebuah dashboard token.

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

Ini adalah repositori GitHub yang sangat mudah. Anda berikan pautan kepada Claude Code, dan ia akan melaksanakan penghantaran secara tempatan di localhost, lalu ia akan membaca semua rekod sesi anda yang lepas, bukan bermula dari keadaan kosong. Anda boleh melihat data input, output, ciptaan cache, dan bacaan cache setiap hari sejak mula.

Namun, ada satu perkara yang perlu diperhatikan: dashboard ini mengira data Token pada peranti tempatan. Jika anda beralih dari komputer desktop ke laptop, nombor-nombor tersebut tidak akan sama sepenuhnya. Setiap peranti mempunyai tampilan pengiraan sendiri.

Ringkasan

Pengurangan cache pemuatan adalah sesuatu yang boleh dikaji secara mendalam. Artikel Thariq menjelaskan lebih lengkap berbanding di sini; jika anda ingin melihat gambaran keseluruhan, ia patut dibaca.

Tetapi anda tidak perlu memahami semua butiran secara penuh untuk mendapat manfaat darinya. Anda hanya perlu menguasai 80/20 paling penting: Token cache lebih murah 10 kali berbanding Token biasa; TTL Claude Code adalah 1 jam; menukar model akan menghancurkan cache; melakukan peralihan yang jelas antara tugas biasanya lebih berkesan daripada terus menggunakan sesi lama sehingga ia “tamat tempoh”.

[Link asal]

Klik untuk mengetahui jawatan yang sedang dibuka oleh BlockBeats

Selamat datang ke komuniti rasmi律动 BlockBeats:

Kumpulan langgan Telegram: https://t.me/theblockbeats

Kumpulan perbincangan Telegram: https://t.me/BlockBeats_App

Akaun rasmi Twitter: https://twitter.com/BlockBeatsAsia