Claude Mẹo tiết kiệm tiền: kỹ sư tiết kiệm 3 tỷ Token mỗi tuần nhờ bộ nhớ đệm, chìa khóa là không bị gián đoạn

Claude Code dài cuộc trò chuyện tiêu tốn bao nhiêu? Kỹ sư Nate Herk tiết lộ, một tuần tiết kiệm được 3 tỷ Token nhờ cơ chế cache, cao nhất trong ngày đạt 91 triệu. Chìa khóa không phải là viết bao nhiêu mã, mà là làm thế nào để không "gián đoạn" cache, giúp tránh lãng phí chi phí cho các ngữ cảnh lặp lại.
(Phần trước: dự án mã nguồn mở badclaude tăng tốc Claude code bị Anthropic gửi thư cảnh báo vi phạm bản quyền)
(Thông tin bổ sung: Claude Code mới thêm chức năng nhiệm vụ định kỳ trên đám mây! Không cần mở máy tính, AI tự động kiểm duyệt PR, nâng cấp)

Mục lục bài viết

Toggle

• Chi phí cache chỉ chiếm 10%, 91 triệu Token tương đương 9 triệu
• Kiến trúc 3 lớp: hệ thống, dự án, cuộc trò chuyện, lớp lớp chồng chất
• Cạm bẫy "đứt quãng" phổ biến nhất: chuyển đổi mô hình và khoảng trống 1 giờ
• Bảng điều khiển tự chế của kỹ sư: xem xét Cache Read và Create
• Bí quyết thực chiến: Session Handoff tiết kiệm hơn /compact

Nhiều nhà phát triển khi dùng Claude Code để lập trình, thường đau đầu vì hạn mức Token tiêu thụ nhanh như dòng chảy, cuộc trò chuyện dài gần như trở thành xa xỉ phẩm.

Nhưng influencer Nate Herk, thường chia sẻ mẹo dùng AI trên cộng đồng, trong một tweet trên X đã tiết lộ rằng chi phí thực sự không phải là mã code, mà là hệ thống có tận dụng tốt cơ chế cache prompt hay không. Chính anh đã tiết kiệm hơn 3 tỷ Token trong vòng một tuần, ngày cao điểm đạt 91 triệu: do chi phí cho Token cache chỉ bằng 10% của Token nhập vào thông thường, tính ra chỉ tiêu tốn khoảng 9 triệu Token mỗi ngày, gần như "miễn phí" kéo dài vòng đời của cuộc trò chuyện lập trình.

Tuần này tôi tiết kiệm được 3 tỷ Token, ngày cao điểm 91 triệu, trong vòng một tuần vượt quá 3 tỷ.

Tôi không thay đổi bất kỳ cài đặt nào. Đó chỉ là prompt caching hoạt động bình thường phía sau.

Nhưng khi tôi thực sự hiểu cache là gì, và làm thế nào để không "gián đoạn" cache, thì trong cùng hạn mức sử dụng, cuộc hội thoại của tôi có thể kéo dài hơn. Vì vậy, tôi tổng hợp một hướng dẫn nhập môn 80/20 về prompt caching của Claude Code, không đi sâu vào API.

Chi phí Token cache chỉ bằng 10% của Token nhập vào thông thường. 9100 triệu Token cache, thực tế tính phí khoảng 9 triệu Token.

Phiên bản đăng ký Claude Code có TTL cache là 1 giờ; API mặc định là 5 phút; Sub-agent luôn là 5 phút.

Cache gồm ba lớp: hệ thống, dự án, cuộc trò chuyện.

Chuyển đổi mô hình giữa chừng sẽ phá vỡ cache, kể cả khi bật chế độ "opus plan".

các agent lập trình giờ cần hộp kính

jianshuo/ccglass

111 sao trên github
tạo hôm qua
mit + javascript
proxy cục bộ + dashboard web cho claude code, codex, deepseek-tui, và kimi
hiển thị toàn bộ prompt hệ thống, schema công cụ, lịch sử tin nhắn, token/cache/chi phí, và… hình ảnh.twitter.com/Wot5SFV16N

— Beau Johnson (@BeauJohnson89) 24 Th5 2026

Chi phí cache chỉ 10%, 9100 triệu Token tương đương 9 triệu

Mỗi Token được cache đều có chi phí bằng 10% của Token nhập vào thông thường.

Vì vậy, khi dashboard của tôi hiển thị ngày nào đó có 91 triệu Token trúng cache, thực tế tính phí chỉ khoảng 9 triệu Token đã xử lý. Đây cũng là lý do khi dùng Claude Code lâu dài, cảm giác như cuộc trò chuyện gần như "miễn phí" kéo dài.

Trong dashboard có hai con số đáng chú ý:

Cache create: chi phí phát sinh khi ghi nội dung vào cache, sẽ phát huy tác dụng trong các lượt hội thoại tiếp theo.
Cache read: Claude lấy lại Token từ cache, như CLAUDE.md, định nghĩa công cụ, tin nhắn trước đó, v.v. So với xử lý lại từ đầu, chi phí thấp hơn gấp 10 lần.

Nếu số lượng Cache read của bạn cao, chứng tỏ bạn đang tận dụng cache hiệu quả; nếu thấp, nghĩa là bạn đang trả phí cho cùng một ngữ cảnh lặp lại nhiều lần.

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

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

Nhưng nếu tỷ lệ trúng thấp, ai cũng thiệt.

Kiến trúc 3 lớp: hệ thống, dự án, cuộc trò chuyện, lớp lớp chồng chất

Vì vậy, động lực của cả hai bên đều nhất quán: Anthropic muốn tỷ lệ trúng cache cao hơn, còn bạn cũng muốn như vậy. Điều làm chậm lại chính là những thói quen nhỏ tưởng chừng vô hại, nhưng âm thầm xây dựng lại cache.

Cache dựa vào matching tiền tố, tức là "đối chiếu từ đầu".

Không cần đi sâu kỹ thuật, bạn chỉ cần hiểu một điểm: chỉ cần nội dung trước đó tại một vị trí nào đó hoàn toàn trùng khớp với nội dung đã cache, Claude có thể tái sử dụng các Token cache này.

Một cuộc hội thoại mới bắt đầu như thế này:

Dựa theo file Claude Code, một cuộc hội thoại mới thường diễn ra như sau:

Lượt hội thoại đầu tiên: chưa có cache. Prompt hệ thống, ngữ cảnh dự án (ví dụ CLAUDE.md, memory, quy tắc), và tin nhắn đầu tiên của bạn đều sẽ được xử lý lại, rồi ghi vào cache.

Lượt hội thoại thứ hai: tất cả nội dung của lượt đầu đã được cache. Claude chỉ cần xử lý phản hồi mới và tin nhắn tiếp theo. Lượt này chi phí sẽ thấp hơn nhiều.

Lượt thứ ba: tương tự. Các cuộc hội thoại trước vẫn còn trong cache, chỉ cần xử lý phần mới nhất.

Cạm bẫy "đứt quãng" phổ biến nhất: chuyển đổi mô hình và khoảng trống 1 giờ

Cache có thể chia thành ba lớp:

Theo bài của Thariq trên X:

Hệ thống (System layer): gồm các lệnh cơ bản, định nghĩa công cụ (read, write, bash, grep, glob) và phong cách xuất. Đây là cache toàn cục.

Dự án (Project layer): gồm CLAUDE.md, memory, quy tắc dự án. Lớp này cache theo dự án.

Cuộc trò chuyện (Conversation): gồm phản hồi và tin nhắn, sẽ tăng dần theo từng vòng.

Nếu trong quá trình hội thoại, nội dung của hệ thống hoặc dự án thay đổi, tất cả nội dung đó phải được cache lại từ đầu. Đây là thao tác đắt nhất. Tưởng tượng bạn đã nói chuyện đến lượt thứ 16, rồi đột nhiên thay đổi prompt hệ thống hoặc dừng một giờ, thì tất cả Token từ lượt 1 phải xử lý lại.

Đây là điểm dễ gây hiểu lầm nhất.

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

Kỹ sư tự chế bảng điều khiển: xem Cache Read và Create

API của Claude: TTL mặc định là 5 phút. Bạn có thể trả phí để nâng lên 1 giờ.
Bất kỳ kế hoạch nào của Sub-agent: luôn là 5 phút.

Chat trên web của Claude.ai: chính thức không ghi rõ. Có thể giống như phiên đăng ký, nhưng tôi chưa xác nhận.

Vài tháng trước, nhiều người phàn nàn về tốc độ tiêu thụ hạn mức Claude. Có người nghĩ Anthropic đã âm thầm giảm TTL từ 1 giờ xuống 5 phút mà không thông báo. Nhưng thực tế không phải vậy, TTL của Claude Code vẫn là 1 giờ.

Vấn đề là, file của Claude Code và API được mở riêng, vốn dĩ chúng hoàn toàn khác nhau, gây ra nhiều nhầm lẫn.

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

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

Nếu bạn đã quá 1 giờ không hoạt động, nội dung cũ gần như đã hết hạn trong cache. Lần tiếp theo gửi tin nhắn, cache sẽ được xây dựng lại. Trong trường hợp này, thay vì tiếp tục khôi phục một cuộc hội thoại đã "nguội", tốt hơn là làm rõ ràng quá trình chuyển giao, rồi bắt đầu một cuộc hội thoại mới, chi phí thường thấp hơn.

/compact hoặc /clear vốn đã phá vỡ cache, nên tốt nhất là tận dụng thời điểm này để xây dựng lại cache.

Bí quyết thực chiến: Session Handoff tiết kiệm hơn /compact

Tôi đã tự tạo ra một kỹ năng chuyển giao session, để thay thế /compact. Nó sẽ tổng kết những gì đã làm, còn những quyết định chưa rõ, các file quan trọng, và bước tiếp theo nên bắt đầu từ đâu. Sau đó tôi chạy /clear, dán phần tóm tắt này vào, rồi tiếp tục như chưa có gì bị gián đoạn.

Lệnh /compact đôi khi chạy chậm, còn kỹ năng chuyển giao này thường xong trong chưa đầy một phút.

Hệ thống cache của Claude.ai chưa có hướng dẫn chính thức rõ ràng, nhưng Projects rõ ràng tối ưu khác với các cuộc hội thoại thông thường. Vì vậy, nếu bạn muốn dán file lớn, tốt nhất là bỏ vào Project chứ không dán trực tiếp vào hội thoại.

Có vài thao tác sẽ tự động xây dựng lại cache mà không cần cảnh báo rõ ràng:

Chuyển đổi mô hình: do cache dựa vào matching tiền tố, mỗi mô hình có cache riêng. Chuyển mô hình sẽ khiến lần yêu cầu tiếp theo không có cache nào trúng, phải đọc lại toàn bộ lịch sử.

Chế độ "Opus plan": chế độ này dùng Opus trong giai đoạn lập kế hoạch, dùng Sonnet trong thực thi. Trước đây tôi đã giới thiệu trong các video tối ưu token, có lý do. Nhưng cần hiểu rằng, mỗi lần chuyển plan đều là chuyển mô hình, nghĩa là phải xây dựng lại cache. Về lâu dài, vẫn giúp kéo dài hạn mức hội thoại, nhưng bạn cần hiểu rõ chuyện gì đang xảy ra phía dưới.

Chỉnh sửa CLAUDE.md giữa chừng là được: thay đổi này không có tác dụng ngay lập tức, phải chờ lần khởi động lại mới áp dụng. Do đó, cache đang chạy sẽ không bị ảnh hưởng.

Ảnh chụp tôi đã trình bày trước đây, là từ một dashboard token.

https://github.com/nateherkai/token-dashboard
Đây là một repo GitHub rất đơn giản. Bạn gửi link cho Claude Code, để nó triển khai trên localhost, nó sẽ đọc toàn bộ lịch sử hội thoại của bạn, không bắt đầu từ trạng thái trống. Bạn sẽ thấy dữ liệu input, output, cache create, cache read của từng ngày.

Tuy nhiên, cần chú ý: dashboard này thống kê Token trên thiết bị cục bộ. Nếu bạn chuyển từ desktop sang laptop, số liệu sẽ không hoàn toàn trùng khớp. Mỗi thiết bị có bộ thống kê riêng của mình.

Prompt caching là một lĩnh vực có thể nghiên cứu rất sâu. Bài của Thariq viết chi tiết hơn nhiều, nếu muốn hiểu toàn diện, đáng để đọc.

Nhưng bạn không cần hiểu tất cả chi tiết để hưởng lợi. Chỉ cần nắm các điểm then chốt 80/20: cache Token rẻ hơn 10 lần Token thông thường; TTL của Claude Code là 1 giờ; chuyển đổi mô hình sẽ phá cache; làm rõ quá trình chuyển giao giữa các nhiệm vụ thường tiết kiệm hơn so với để cuộc hội thoại cũ "hết hạn" rồi tiếp tục.

》Link nguyên bản