Hai dòng code ẩn khiến Claude Code ngốn token gấp 4 lần

Mình dùng Claude Code hàng ngày. Và trong vài tuần gần đây, mình có cảm giác usage limit của mình đang bị ăn nhanh hơn bình thường — đặc biệt vào các session dài, khi mình resume lại conversation cũ. Cứ tưởng do mình dùng nhiều hơn. Hóa ra không phải. Có một bug thực sự trong Claude Code đã ngầm phá vỡ caching mechanism mỗi lần bạn resume session, khiến toàn bộ conversation phải rebuild từ đầu dưới dạng cache creation tokens thay vì cache read. Và một người dùng Reddit vừa tìm ra nó — với sự trợ giúp của Codex, không phải Claude, vì anh ta đã hết quota trước khi kịp dùng Claude để debug.

Trớ trêu theo một cách rất đặc trưng của nghề này.

Cơ chế caching hoạt động như thế nào — và tại sao nó quan trọng

Để hiểu bug này, cần hiểu sơ qua về prompt caching của Anthropic. Khi bạn gửi một request đến Claude, toàn bộ conversation history phải được đưa vào context — system prompt, lịch sử tin nhắn, tool definitions. Đây là input tokens, và bạn trả tiền cho chúng.

Prompt caching giải quyết vấn đề này bằng cách lưu một "cache prefix" — phần đầu của conversation mà ít thay đổi nhất. Lần sau khi bạn gửi request, thay vì process lại toàn bộ, Claude chỉ cần đọc từ cache cho phần đã lưu (cache_read_input_tokens) và chỉ process phần mới (cache_creation_input_tokens). Cache read rẻ hơn cache creation khoảng mười lần.

Trong một session khỏe mạnh, sau vài turn đầu, tỉ lệ cache read nên chiếm phần lớn. Đây là những gì OP đo được trên stock Claude Code:

Cache ratio — TRƯỚC khi patch (stock Claude Code) Turn 1: cache_read: 15,451 cache_creation: 7,473 ratio: 67% Turn 5: cache_read: 15,451 cache_creation: 16,881 ratio: 48% Turn 10: cache_read: 15,451 cache_creation: 35,006 ratio: 31% Turn 15: cache_read: 15,451 cache_creation: 42,970 ratio: 26% cache_read kẹt cứng ở 15,451 — chỉ system prompt được cache. Mọi thứ khác: full-price token processing.

Cache ratio — SAU khi patch Turn 1 (resume): cache_read: 7,208 cache_creation: 49,748 ratio: 13% ← structural reset Turn 2: cache_read: 56,956 cache_creation: 728 ratio: 99% Turn 3: cache_read: 57,684 cache_creation: 611 ratio: 99%

26% lên 99%. Đó là khoảng cách giữa session bình thường và session bị bug.

Bug nằm ở đâu — và tại sao nó âm thầm đến vậy

Claude Code lưu lịch sử conversation vào các file JSONL trong ~/.claude/projects/. Có một hàm trong minified source — được obfuscate thành tên db8 — chịu trách nhiệm lọc những gì được ghi vào file đó. Và hàm này có một lỗ hổng nhỏ nhưng chết người.

Với user không phải Anthropic internal, db8 strip ra toàn bộ message có type là attachment. Nghe có vẻ vô hại — attachment thường là file đính kèm, không cần lưu vào session history. Nhưng cùng chung type attachment đó còn có các record deferred_tools_delta — những bản ghi theo dõi xem tool nào đã được announce với model.

Hàm db8 gốc — minified function db8(A){ if(A.type==="attachment"&&ss1()!=="ant"){ if(A.attachment.type==="hook_additional_context" &&a6(process.env.CLAUDE_CODE_SAVE_HOOK_ADDITIONAL_CONTEXT)) return!0; return!1 // ← drops EVERYTHING else, kể cả deferred_tools_delta } if(A.type==="progress"&&Ns6(A.data?.type))return!1; return!0 }

Khi bạn resume một session, Claude Code đọc lại file JSONL để xem "tôi đã announce những tool nào cho model rồi?" Nhưng vì db8 đã xóa toàn bộ deferred_tools_delta khỏi file đó, nó không tìm thấy gì. Kết quả: nó re-announce toàn bộ tool từ đầu, mỗi lần resume.

Điều này phá vỡ cache prefix theo ba cách cùng lúc. System reminder vốn ở vị trí đầu conversation trong session mới bây giờ lại nằm ở giữa. Billing hash thay đổi vì nội dung message đầu tiên khác đi. Cache breakpoint dịch chuyển vì mảng message có độ dài khác. Ba cái đó cộng lại: toàn bộ conversation phải rebuild từ đầu, mỗi lần resume.

Fix — đúng hai dòng

Patch chỉ cần thêm hai type vào allowlist của db8, trước dòng return!1:

if(A.attachment.type==="deferred_tools_delta")return!0;

if(A.attachment.type==="mcp_instructions_delta")return!0;

Vậy là các deferred tool announcement tồn tại trong session file. Lần resume tiếp theo, delta computation thấy "tôi đã announce những cái này rồi" và không re-emit lại. Cache prefix giữ nguyên.

Còn một bug thứ hai liên quan đến binary standalone của Claude Code — nó dùng một custom Bun fork và rewrite một sentinel value cch=00000 trong mọi outgoing API request. Nếu conversation của bạn tình cờ chứa chuỗi đó, nó phá vỡ cache prefix. Chạy qua node cli.js thay vì binary loại bỏ vấn đề này hoàn toàn.

Phần mà cộng đồng Reddit bắt đầu nổi loạn

Đây là lúc câu chuyện rẽ theo hướng mình không ngờ.

Boris Cherny — developer từ Anthropic, người tạo ra Claude Code — xuất hiện trong thread và xác nhận bug là thật và sẽ được patch trong release tiếp theo. Tin tốt. Nhưng ông cũng nói thêm: đây là "<1% win" về token usage, không phải silver bullet cho usage limit.

"So Anthropic intentionally leaked their source code to crowdsource QA and bug fixes from their user base for free. All our software engineers aren't writing code anymore — they're getting users to do it for them." — Top comment, r/ClaudeAI

Mình cười, nhưng cũng hiểu tại sao người ta nói vậy. Nhưng đó chưa phải phần thú vị nhất.

Phần thú vị nhất: repo GitHub mà OP link tới không chỉ chứa patch cho bug caching. Nó còn bao gồm một patch riêng để bypass billing controls của Anthropic bằng cách force một 1-hour cache TTL. Điều này không được đề cập trong bài post gốc.

Cảnh báo từ cộng đồng

Nhiều người trong thread đã chỉ ra rằng việc apply repo đó như-là vi phạm ToS của Anthropic — reverse engineering và bypass billing controls. Anthropic đã ban account người dùng vì những hành vi tương tự trong quá khứ.

Bug caching là thật và đáng được fix. Nhưng repo của OP bao gồm nhiều hơn mức cần thiết để fix bug đó. Nếu bạn muốn áp dụng patch, bạn cần đọc kỹ từng thay đổi trước khi chạy bất cứ thứ gì.

Cái mình thực sự suy nghĩ sau chuyện này

Có vài lớp đáng nói ở đây, không chỉ về bug.

Thứ nhất: việc một user tự tay reverse-engineer minified CLI code của một công ty, tìm ra bug thực sự, và post bằng chứng cụ thể kèm số liệu đo được — đó là engineering tốt. Mình tôn trọng điều đó, bất kể anh ta dùng Codex thay vì Claude để làm nó. Cách anh present data — so sánh cache ratio theo từng turn, trước và sau patch — rõ ràng hơn nhiều documentation bug report mình từng thấy trong nội bộ công ty.

Thứ hai: Boris Cherny confirm bug nhưng nói đây là "<1% win" — mình nghĩ con số đó misleading theo một nghĩa quan trọng. Về tổng token usage, có thể đúng. Nhưng nếu bạn là người hay resume session dài — đặc biệt là session làm việc với codebase lớn, nhiều tool — thì bug này không phải <1%. Nó là lý do tại sao usage limit của bạn bốc hơi nhanh một cách khó giải thích. Data của OP cho thấy 26% vs 99% cache ratio, không phải <1% difference.

Thứ ba — và đây là phần mình nghĩ nhiều nhất: việc OP thêm patch bypass billing vào cùng repo với bug fix, rồi không đề cập trong post, dù vô tình hay cố ý, đã làm hỏng một câu chuyện kỹ thuật tốt. Giờ thay vì "community tìm ra bug và Anthropic xác nhận," narrative là "người dùng cố bypass billing và bị cộng đồng phát hiện." Cái bug thật sự đáng được chú ý hơn mức nó đang nhận được, vì nó bị shadow bởi phần drama này.