原文标题：Làm Thế Nào Kỹ Sư Anthropic Thực Sự Tiết Kiệm Token
原文作者：Nate Herk
Biên Dịch: Peggy, BlockBeats

Biên tập viên chú thích: Đối với nhiều người sử dụng Claude Code, ấn tượng đầu tiên nhất là Token tiêu thụ quá nhanh, và các phiên dài dễ dàng đạt tới giới hạn. Tuy nhiên, từ góc độ của Kỹ sư Anthropic, điều thực sự ảnh hưởng đến chi phí thường không phải là số lượng code bạn đã viết, mà là hệ thống có tiếp tục tái sử dụng ngữ cảnh đã xử lý hay không.

Trong bài viết này, trung tâm chia sẻ là làm thế nào để tiết kiệm Token thông qua cơ chế caching. Trong vòng một tuần, tác giả đã tái sử dụng hơn 3 tỷ Token thông qua caching, lượng caching hàng ngày đã đạt 91 triệu. Vì chi phí caching Token chỉ bằng 10% so với việc nhập Token bình thường, điều này có nghĩa rằng lượng 91 triệu Token đã được caching thực tế chỉ tương đương khoảng 9 triệu Token thông thường. Sự "bền bỉ" của Claude Code trong các phiên dài không phải là vì mô hình làm việc miễn phí, mà là vì rất nhiều ngữ cảnh được tái sử dụng thành công.

Ở những trường hợp mà caching nhanh là yếu tố quan trọng, "đừng gián đoạn caching" là chìa khóa. Claude Code sẽ phân lớp caching những thứ như hệ thống gợi ý, định nghĩa công cụ, CLAUDE.md, quy tắc dự án và cuộc trò chuyện lịch sử; miễn là tiền tố của yêu cầu tiếp theo giữ nguyên, Claude có thể trực tiếp đọc từ bộ nhớ cache, thay vì xử lý lại toàn bộ ngữ cảnh. Bên trong Anthropic cũng sẽ theo dõi tỷ lệ tái sử dụng của bộ nhớ cache, vì nó không chỉ ảnh hưởng đến giới hạn người dùng, mà còn liên quan trực tiếp đến chi phí dịch vụ mô hình và hiệu suất hoạt động.

Đối với người dùng thông thường, không cần hiểu tất cả chi tiết cấp dưới, chỉ cần nắm vững vài thói quen quan trọng: không để phiên trống trải quá 1 giờ; khi chuyển nhiệm vụ, thực hiện session handoff tốt; tránh chuyển đổi mô hình thường xuyên; tài liệu lớn nên đặt vào Projects thay vì lặp đi lặp lại trong cuộc trò chuyện.

Bài viết này không phải chỉ là về một kỹ thuật tiết kiệm Token, mà hơn hết là cung cấp một bộ phương pháp sử dụng Claude Code gần với tư duy của Kỹ sư: coi ngữ cảnh như quản lý tài sản, cho phép caching tiếp tục tái sử dụng, giảm thiểu việc tính toán lặp lại trong các phiên dài.

Dưới đây là nguyên văn:

Tôi đã tiết kiệm được 3 tỷ Token trong tuần này, 9100 triệu trong một ngày, hơn 3 tỷ trong một tuần.

Tôi không đãng trích bất kỳ cài đặt nào. Điều này chỉ là việc lưu cache của prompt đang hoạt động bình thường ở nền.

Nhưng khi tôi thực sự hiểu về cache là gì và cách tránh "phá vỡ" cache sau đó, dưới cùng một lượng sử dụng tương tự, phiên của tôi có thể kéo dài hơn. Vì vậy, đây là một hướng dẫn cơ bản 80/20 về cache của Claude Code, không liên quan đến chi tiết sâu ở cấp độ API.

TL;DR

Chi phí lưu trữ Token chỉ bằng 10% của Token nhập thông thường. 91 triệu Token được lưu cache, mức tính toán thực tế khoảng bằng 9 triệu Token.

Thời gian sống của cache cho phiên bản đăng ký của Claude Code là 1 giờ; Mặc định API là 5 phút; Sub-agent luôn là 5 phút.

Cache được chia thành ba lớp: lớp hệ thống, lớp dự án, lớp trò chuyện.

Chuyển mô hình giữa phiên sẽ phá vỡ cache, bao gồm việc bật chế độ "opus plan".

Tính tiền lưu cache như thế nào?

Mỗi Token được lưu cache, chi phí là 10% của Token nhập thông thường.

Vì vậy, khi bảng điều khiển của tôi cho thấy có 91 triệu Token đã trúng cache trong một ngày nào đó, chi phí thực tế khoảng như xử lý 9 triệu Token. Đó cũng là lý do tại sao so với việc không có cache, khi sử dụng lâu dài Claude Code, người ta cảm thấy như phiên kéo dài gần như "miễn phí".

Có hai số trong bảng điều khiển mà đáng chú ý:

Cache tạo ra: Chi phí một lần khi ghi nội dung vào cache. Nó sẽ bắt đầu hữu ích trong phiên tiếp theo.
Đọc cache: Claude sử dụng lại Token từ cache, chẳng hạn như CLAUDE.md của bạn, định nghĩa công cụ, tin nhắn trước đó, v.v. So với xử lý nhập lại, chi phí rẻ hơn 10 lần.

Nếu số Đọc cache của bạn cao, điều đó ngụ ý bạn đang tận dụng cache hiệu quả; nếu số này thấp, điều đó có nghĩa bạn đang trả phí lặp đi lặp lại cho cùng một ngữ cảnh.

Thariq của Anthropic đã nói một câu khiến tôi ấn tượng: "Thực tế, chúng tôi sẽ theo dõi tỷ lệ trúng cache của prompt, một khi tỷ lệ trúng cache quá thấp, chúng tôi sẽ kích hoạt cảnh báo, thậm chí công bố sự cố cấp độ SEV".

Anh ấy cũng đã viết một bài bài viết X rất hay. Khi tỷ lệ hit cache cao, có bốn điều xảy ra đồng thời: Claude Code cảm thấy nhanh hơn, chi phí dịch vụ Anthropic giảm, hạn mức đăng ký của bạn trở nên bền hơn, và phiên mã hóa dài hạn cũng trở nên thực tế hơn.

Nhưng nếu tỷ lệ hit thấp, tất cả mọi người đều mắc thiệt.

Vì vậy, động cơ của cả hai bên thực tế là nhất quán: Anthropic hy vọng tỷ lệ hit cache của bạn cao hơn, và bạn cũng mong muốn tỷ lệ hit cao hơn. Điều thực sự làm chậm lại chỉ là một số thói quen nhỏ nhặt nhưng có thể làm reset cache mà không hề để ý.

Làm thế nào mà cache tăng trong mỗi vòng trò chuyện?

Cache dựa vào việc ánh xạ tiền tố, cũng được gọi là "prefix matching".

Đừng mắc kẹt vào chi tiết kỹ thuật quá sâu, bạn chỉ cần hiểu một điều: nếu nội dung phía trước một vị trí nào đó giống hoàn toàn với nội dung đã được cache, Claude có thể tái sử dụng phần token cache này.

Một cuộc trò chuyện hoàn toàn mới thì điều này diễn ra:

Theo tài liệu Claude Code, một cuộc trò chuyện mới hoàn toàn thường diễn ra như sau:

Vòng trò chuyện đầu tiên: chưa có bất kỳ cache nào. Câu từ gợi ý hệ thống, ngữ cảnh dự án của bạn (ví dụ: CLAUDE.md, bộ nhớ, quy tắc), và thông điệp đầu tiên của bạn sẽ được xử lý lại và ghi vào cache.

Vòng trò chuyện thứ hai: tất cả nội dung của vòng trò chuyện đầu tiên giờ đây đã được cache. Claude chỉ cần xử lý phản hồi mới của bạn và thông điệp tiếp theo. Chi phí của vòng này sẽ thấp hơn nhiều.

Vòng trò chuyện thứ ba: logic tương tự. Cuộc trò chuyện trước đó vẫn còn trong cache, chỉ có tương tác mới nhất cần được xử lý lại.

Cache chính mình có thể được phân thành ba tầng:

Từ bài viết X của Thariq:

Tầng hệ thống (System layer): Bao gồm các hướng dẫn cơ bản, định nghĩa công cụ (read, write, bash, grep, glob) và kiểu đầu ra. Tầng này là tầng cache toàn cầu.

Lớp Dự án (Project layer): Bao gồm tệp CLAUDE.md, memory, và quy tắc dự án. Lớp này được lưu trong bộ nhớ cache của dự án.

Lớp Đối thoại (Conversation): Bao gồm phản hồi và tin nhắn, sẽ mở rộng theo mỗi vòng đối thoại.

Nếu giữa một cuộc trò chuyện, bất kỳ nội dung nào từ lớp hệ thống hoặc lớp dự án thay đổi, tất cả nội dung đều phải được chuẩn bị lại từ đầu. Đây chính là hoạt động tốn kém nhất. Hãy tưởng tượng: bạn đã trò chuyện đến tin nhắn thứ 16, lúc này đột nhiên từ thiết lập hệ thống hoặc dự án thay đổi, hoặc dừng lại trong một giờ, vậy thì tất cả Token từ tin nhắn thứ nhất trở đi sẽ phải được xử lý lại.

Sự Nhầm lẫn giữa 1 Giờ và 5 Phút

Đây là điểm dễ nhầm lẫn nhất.

Phiên bản Đăng ký Claude Code: TTL mặc định là 1 giờ.

Claude API: TTL mặc định là 5 phút. Bạn có thể trả thêm chi phí để nâng cấp lên 1 giờ.
Bất kỳ Sub-agent nào dưới mọi kế hoạch: Luôn là 5 phút.

Trò chuyện trực tuyến Claude.ai: Chính thức không có ghi chú cụ thể. Có thể giống như bản Đăng ký, nhưng tôi chưa xác nhận được.

Vài tháng trước, nhiều người phàn nàn về việc lượng dung lượng đăng ký của Claude tiêu tốn quá nhanh. Khi đó, một số người nghĩ rằng Anthropic lén giảm TTL từ 1 giờ xuống còn 5 phút và không thông báo cho người dùng. Nhưng thực tế không phải như vậy, TTL của Claude Code vẫn là 1 giờ.

Vấn đề là, tài liệu của Claude Code và API được trình bày một cách riêng lẻ, và hai thứ này ban đầu là hoàn toàn khác biệt, do đó gây ra rất nhiều sự nhầm lẫn.

Nếu bạn đang chạy nhiều luồng công việc Sub-agent hoặc trực tiếp sử dụng API, thì con số 5 phút này rất quan trọng. Nhưng với 95% người dùng của Claude Code, điều thực sự cần quan tâm là cửa sổ thời gian 1 giờ đó.

Ba Thói Quen Phủ 95% Người Dùng

Dưới đây, đây là những phần mà tôi nghĩ thực sự hữu ích trong việc sử dụng hàng ngày.

Không Nên Tạm Dừng Quá Lâu

Nếu bạn đã rảnh rỗi hơn một giờ, phần lớn nội dung trước đó sẽ đã hết hạn trong bộ nhớ cache. Tin nhắn tiếp theo của bạn sẽ xây dựng lại cache. Trong tình huống này, thay vì tiếp tục khôi phục một cuộc trò chuyện cũ đã "nguội", thì thực hiện một bước chuyển giao rõ ràng, sau đó bắt đầu một cuộc trò chuyện mới, chi phí thường thấp hơn.

Khi Chuyển Nhiệm Vụ, Hãy Bắt Đầu Lại Ngay

/compact hoặc /clear sẽ làm hỏng bộ nhớ cache, vì vậy tốt hơn hết là tận dụng cơ hội này để thực sự thiết lập lại một lần.

Tôi đã tự tạo một kỹ năng session handoff, sử dụng để thay thế /compact. Nó sẽ tóm tắt những gì chúng ta đã hoàn thành, những quyết định còn phải thực hiện, những tệp quan trọng nhất và nên tiếp tục từ đâu tiếp theo. Sau đó, tôi thực thi /clear, dán tổng kết này vào đó, giúp tiếp tục triển khai như không có sự gián đoạn nào.

Lệnh compact đôi khi chạy rất chậm. Trong khi đó, kỹ năng handoff này thường chỉ mất dưới một phút để hoàn thành.

Trong Trò Chuyện với Claude, Hãy Đặt Tài Liệu Lớn Vào Dự Án

Cơ chế cache trên Claude.ai không có hướng dẫn chính thức rất chi tiết, nhưng có vẻ như Projects và luồng trò chuyện thông thường được tối ưu hóa khác nhau. Vì vậy, nếu bạn muốn dán một tài liệu lớn, tốt nhất là đặt chúng vào Dự Án thay vì đưa trực tiếp vào cuộc trò chuyện.

Những Hành Động Nào Sẽ Làm Hỏng Bộ Nhớ Cache Một Cách Im Lặng?

Có một số hành động sẽ làm thiết lập lại toàn bộ bộ nhớ cache mà không có cảnh báo rõ ràng.

Chuyển Đổi Mô Hình: Bởi vì cache dựa vào sự trùng khớp tiền tố và mỗi mô hình có bộ nhớ cache riêng. Chỉ cần chuyển đổi mô hình, yêu cầu tiếp theo sẽ đọc lại toàn bộ lịch sử mà không có bất kỳ trùng khớp cache nào.

Chế Độ "Opus plan": Cài đặt này sẽ sử dụng Opus trong giai đoạn kế hoạch và sử dụng Sonnet trong giai đoạn thực thi. Tôi đã giới thiệu nó trong một số video tối ưu hóa token trước đây với lý do. Tuy nhiên, cần hiểu rằng, mỗi lần chuyển đổi plan, về cơ bản là một lần chuyển đổi mô hình, có nghĩa là cần phải thiết lập lại cache. Tính inav đó, nó vẫn giúp kéo dài thời gian cuộc trò chuyện, nhưng bạn cần hiểu rõ về những điều diễn ra ở tầng dưới.

Chỉnh Sửa CLAUDE.md Giữa Chừng Cuộc Trò Chuyện Là Được: Sửa đổi này sẽ không có hiệu lực ngay lập tức, mà sẽ được áp dụng sau khi khởi động lại lần tiếp theo. Do đó, cache đang chạy hiện tại sẽ không bị ảnh hưởng.

Bảng Điều Khiển Token Miễn Phí Của Tôi

Bức ảnh mà tôi đã trình bày trước đó, đến từ một bảng điều khiển token.

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

Đây là một kho GitHub rất đơn giản. Bạn đưa liên kết này cho Claude Code, để nó triển khai cục bộ trên localhost, nó sẽ đọc tất cả lịch sử trò chuyện của bạn trong quá khứ, thay vì bắt đầu tính từ trạng thái trống rỗng. Bạn sẽ ngay lập tức thấy dữ liệu input, output, cache create và cache read hàng ngày.

Tuy nhiên, có một điều cần lưu ý: bảng điều khiển này thống kê dữ liệu Token trên thiết bị cục bộ. Nếu bạn chuyển từ máy tính để bàn sang máy tính xách tay, con số sẽ không hoàn toàn giống nhau. Mỗi thiết bị có một bộ xem thống kê riêng.

Tóm Tắt

Prompt caching là một điều có thể nghiên cứu sâu hơn. Bài viết của Thariq nói về nó chi tiết hơn so với đây, nếu bạn muốn nhìn nhận toàn cảnh, đọc bài đó đáng giá.

Nhưng bạn không cần phải hiểu hoàn toàn tất cả chi tiết để có lợi ích từ nó. Bạn chỉ cần nắm bắt 20% quan trọng nhất: việc cache Token rẻ hơn 10 lần so với Token thông thường; TTL của Claude Code là 1 giờ; chuyển đổi mô hình sẽ làm hỏng cache; chuyển giao rõ ràng giữa các nhiệm vụ thường hiệu quả hơn so với để một phiên cũ chờ "hết hạn" rồi tuân thủ tiếp.

[Liên kết Gốc]

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia