Lỗi Claude Code: Hạn mức Pro Max 5x bị cạn kiệt nhanh chóng do tính toán sai token cache

Một báo cáo lỗi mới đây trên GitHub đã chỉ ra một vấn đề nghiêm trọng ảnh hưởng đến trải nghiệm của người dùng sử dụng công cụ dòng lệnh (CLI) Claude Code với gói thuê bao cao cấp Pro Max 5x. Theo đó, hạn mức (quota) của người dùng bị cạn kiệt một cách bất thường nhanh chóng, thậm chí chỉ trong vòng 1,5 giờ với mức sử dụng bình thường.

Vấn đề cốt lõi: Đếm sai token cache

Vấn đề chính nằm ở cách tính toán token tiêu thụ đối với tính năng prompt caching. Về lý thuyết, khi hệ thống đọc các token đã có sẵn trong bộ nhớ đệm (cache_read), chi phí tính toán sẽ giảm xuống chỉ còn 1/10 so với token mới. Tuy nhiên, người dùng phát hiện rằng khi áp dụng giới hạn tốc độ (rate limit) hoặc quota, các token cache_read này vẫn bị tính với tỷ lệ 100% (tỷ lệ đầy đủ).

Thực tế này làm vô hiệu hóa lợi ích kinh tế của việc sử dụng prompt caching. Với các mô hình có cửa sổ ngữ cảnh (context window) lớn lên tới 1 triệu token, mỗi lệnh gọi API có thể gửi đi hàng trăm nghìn token. Nếu chúng đều bị tính là token mới đối với giới hạn quota, người dùng sẽ nhanh chóng hết hạn mức dù phần lớn nội dung đã được tải từ cache.

Dữ liệu thực tế so sánh

Người dùng đã cung cấp dữ liệu chi tiết từ các tệp nhật ký (session files) để chứng minh sự bất thường này:

• Khoảng thời gian 1 (Sử dụng cường độ cao): Trong 5 giờ làm việc phát triển phần mềm nặng (multi-file implementation, knowledge graph pipeline), tổng cộng tiêu thụ khoảng 24,4 triệu hiệu tương đương token mỗi giờ. Khoản này được coi là hợp lý và làm cạn quota như mong đợi.
• Khoảng thời gian 2 (Sử dụng mức độ vừa phải): Chỉ sau 1,5 giờ sử dụng thông thường (chủ yếu là Q&A và phát triển nhẹ), quota đã bị cạn kiệt. Dữ liệu cho thấy tổng số token thô (raw tokens) gửi đi là hơn 105 triệu token.

Nếu cache_read được tính đúng mức giảm giá (1/10), mức tiêu thụ trong khoảng thời gian 2 chỉ nên là khoảng 8,7 triệu token/giờ — một con số thấp hơn nhiều so với giới hạn của gói Pro Max 5x. Tuy nhiên, tốc độ cạn kiệt thực tế tương đương với việc tất cả 105 triệu token đều được tính đầy đủ.

Các yếu tố làm trầm trọng thêm vấn đề

Bên cạnh lỗi đếm token, báo cáo này còn chỉ ra một số yếu tố kỹ thuật khác góp phần vào việc tiêu tốn quota nhanh chóng:

1. Các phiên chạy nền (Background sessions): Những phiên Claude Code được mở nhưng không hoạt động vẫn tiếp tục tiêu thụ quota do các quy trình tự động như nén dữ liệu (compacts) hoặc xử lý hook. Trong trường hợp được báo cáo, các session nền đã tiêu thụ tới 78% hạn mức sau khi reset.
2. Tự động nén (Auto-compact) gây ra đỉnh tiêu thụ: Khi ngữ cảnh đạt ngưỡng giới hạn (~960k token), Claude Code thực hiện auto-compact. Quy trình này tạo ra một lệnh gọi API duy nhất với kích thước cực lớn để ghi vào cache, gây ra một "cú đánh" mạnh vào hạn mức người dùng mà không có hành động trực tiếp từ người dùng.
3. Cửa sổ ngữ cảnh 1M token: Mặc dù là một tính năng hấp dẫn, nhưng kích thước ngữ cảnh lớn khiến mỗi lần gọi API tốn kém hơn nhiều nếu cơ chế tính toán cache không hoạt động chính xác.

Đề xuất giải pháp

Để giải quyết vấn đề này, cộng đồng người dùng và kỹ sư đã đề xuất một số cải hướng:

• Sửa logic đếm giới hạn: Các token cache_read phải được tính với tỷ lệ 1/10 khi áp dụng cho quota, tương ứng với chính sách giảm giá về chi phí.
• Tối ưu hóa phiên không hoạt động: Không nên tính chi phí của các session chạy ngầm vào quota người dùng, hoặc ít nhất phải có cảnh báo rõ ràng khi có quá nhiều session đang mở.
• Minh bạch hóa việc sử dụng token: Giao diện Claude Code cần hiển thị chi tiết thời gian thực việc phân chia token (cache_read, cache_create, input, output) để người dùng dễ dàng giám sát.

Hiện tại, vấn đề này được đánh dấu là một lỗi (bug) liên quan đến chi phí và đang chờ phía phát triển xử lý để đảm bảo tính công bằng cho những người dùng trả phí cao cấp.