Thống kê lượng token Claude Code trong 30 ngày. 98% là lượt đọc từ bộ nhớ đệm (cache read).

Cơ chế Claude Code ghi dữ liệu vào ổ đĩa, phương pháp thống kê chính xác tránh trùng lặp và cách xác định giới hạn gói sử dụng. Khi sử dụng gói thuê bao trọn gói hằng tháng của Claude, lượng token tiêu thụ thường ít được người dùng chú ý. Tuy nhiên, qua theo dõi bằng một ứng dụng chuyên biệt trên thanh tác vụ, số liệu thực tế ghi nhận được trên một thiết bị cá nhân đã lên tới 4,9 tỷ token chỉ trong vòng 30 ngày. Con số này không lấy từ bảng điều khiển trực tuyến (dashboard) mà được trích xuất trực tiếp từ các tệp JSON lưu trong thư mục người dùng, do Claude Code tự động ghi lại sau mỗi phản hồi. Đáng chú ý, cơ cấu phân bổ mới là yếu tố bất ngờ nhất: 98,1% lượng token thuộc diện đọc từ bộ nhớ đệm (cache read) — tức toàn bộ cuộc hội thoại từ đầu được gửi lại trong mỗi yêu cầu và xử lý qua bộ nhớ đệm câu lệnh (prompt cache) của Anthropic. Lượng văn bản phản hồi thực tế từ Claude chỉ chiếm 0,37%. Nội dung dưới đây phân tích chi tiết dữ liệu từ các tệp lưu trữ này: cấu trúc tổ chức, cách thức thống kê chuẩn xác bằng 25 dòng mã nguồn Python, thực tế sử dụng trong một tháng và phương pháp xác định các giới hạn chu kỳ 5 giờ cũng như giới hạn tuần của gói dịch vụ. Việc tra cứu các hạn mức này là một vấn đề kỹ thuật riêng biệt và đòi hỏi nhiều thời gian nghiên cứu. Dữ liệu Claude Code ghi vào ổ đĩa Mỗi phiên làm việc được lưu dưới dạng tệp JSONL: mỗi dòng là một đối tượng JSON và được ghi tiếp nối trong suốt phiên chạy. Các tệp này nằm trong thư mục ~/.claude/projects/, phân chia theo từng thư mục dự án tương ứng với đường dẫn của dự án đó: ~/.claude/projects/ -Users-you-code-api/ 3f2c….jsonl # một phiên làm việc 3f2c…/subagents/ # các phiên làm việc của tác tử phụ (subagent)Trường hợp vận hành hai tài khoản qua hai biến môi trường CLAUDE_CONFIG_DIR, mỗi thư mục cấu hình sẽ có một thư mục projects/ riêng; do đó cần tiến hành thống kê trên cả hai vị trí. Mỗi dòng đại diện cho một sự kiện: câu lệnh người dùng (prompt), kết quả thực thi công cụ, bản tóm tắt hoặc phản hồi từ mô hình. Dòng phản hồi sẽ chứa đối tượng usage từ API với 4 chỉ số thống kê: input_tokens: dữ liệu đầu vào mới không có trong bộ nhớ đệm. cache_creation_input_tokens: dữ liệu đầu vào được ghi vào bộ nhớ đệm trong lượt yêu cầu này. cache_read_input_tokens: dữ liệu đầu vào được truy xuất từ bộ nhớ đệm. output_tokens: lượng dữ liệu do mô hình tạo ra, bao gồm cả các chuỗi suy nghĩ (thinking). Một đặc tính vận hành cốt lõi là mỗi lượt yêu cầu đều gửi lại toàn bộ nội dung cuộc trò chuyện trước đó. Theo tài liệu chi phí chính thức của Claude Code, một câu hỏi ngắn gọn trong một phiên làm việc mở cả ngày “vẫn tính mức sử dụng cho toàn bộ cuộc hội thoại”. Cơ chế lưu bộ nhớ đệm (caching) giúp việc tái gửi dữ liệu này đạt hiệu quả kinh tế cao, và đối tượng usage phản ánh chính xác mức độ tối ưu đó. Một lưu ý quan trọng trước khi thống kê: Claude Code sẽ tự động xóa các tệp phiên làm việc cũ hơn thông số cleanupPeriodDays, mặc định là 30 ngày. Để lưu giữ lịch sử dài hơn một tháng, người dùng cần điều chỉnh thông số này trong tệp ~/.claude/settings.json trước thời điểm hệ thống tự động xóa dữ liệu. Phương pháp thống kê chính xác, tránh tính trùng lặp Cách tiếp cận thông thường là đọc từng dòng chứa thông số usage và cộng dồn lại. Tuy nhiên, phương pháp này sẽ khiến lượng token đầu ra (output tokens) bị tính dư 2,47 lần và lượng đọc từ bộ nhớ đệm bị phóng đại 2,13 lần, dẫn đến tổng số liệu cao hơn gấp đôi thực tế. Nguyên nhân là một lượt phản hồi thường được ghi thành nhiều dòng. Phản hồi bao gồm chuỗi suy nghĩ, văn bản và lệnh gọi công cụ có thể tách thành từng dòng riêng cho mỗi khối nội dung, nhưng mỗi dòng lại giữ nguyên đối tượng usage giống nhau. Trong chu kỳ 30 ngày, hệ thống ghi nhận 51.429 dòng có thông số usage, nhưng thực tế chỉ có 24.434 phản hồi riêng biệt. Ngoài ra, một phản hồi cũng có thể xuất hiện đồng thời ở hai tệp khi một phiên làm việc được khôi phục hoặc phân nhánh (fork). Giải pháp xử lý là lập chỉ mục cho mỗi phản hồi dựa trên mã định danh tin nhắn (message ID) và mã định danh yêu cầu (request ID), sau đó chỉ lấy giá trị lớn nhất của từng chỉ số trong các bản ghi trùng: import json, glob, os from collections import Counter root = os.path.expanduser("~/.claude/projects") replies = {} # (message id, request id) -> usage for path in glob.glob(f"{root}/**/*.jsonl", recursive=True): for line in open(path, errors="ignore"): if '"usage"' n ot in line: continue # bỏ qua câu lệnh nhắc, kết quả công cụ, phần tóm tắt row = json.loads(line) msg = row.get("message") or {} if row.get("type") != "assistant" or "usage" not in msg: continue key = (msg.get("id"), row.get("requestId")) seen = replies.setdefault(key, Counter()) for field, n in msg["usage"].items(): if isinstance(n, int): seen[field] = max(seen[field], n) # các bản sao của một phản hồi: giữ giá trị lớn nhất total = sum(replies.values(), Counter()) print(len(replies), "replies") for field in ("input_tokens", "cache_creation_input_tokens", "cache_read_input_tokens", "output_tokens"): print(f"{field:30} {total[field]:>15,}")Việc kiểm tra chuỗi ký tự trước khi chạy lệnh json.loads có ý nghĩa quan trọng đối với thư mục có dung lượng lớn. Phần lớn các dòng là câu lệnh nhắc (prompt) và kết quả công cụ; việc bỏ qua các dòng này mà không phân tích cú pháp giúp quá trình xử lý chỉ diễn ra trong vài giây. Thư mục có dung lượng 1,6 GB chỉ mất khoảng 9 giây xử lý. Tại sao lại lấy giá trị lớn nhất mà không phải giá trị cuối cùng? Các bản sao của cùng một phản hồi cần phải đồng nhất, và việc chọn giá trị lớn nhất sẽ bảo đảm an toàn khi có sự đồng nhất. Khi xảy ra chênh lệch, giá trị lớn nhất phản ánh đầy đủ số lượng nhất. Kết quả ghi nhận từ dữ liệu nhật ký (log) trong 30 ngày Dữ liệu được thống kê trên cả hai tài khoản trong giai đoạn từ ngày 26/9/2026 đến ngày 26/10/2026, sau đó tính chi phí từng phản hồi theo biểu giá niêm yết của Anthropic API cho từng mô hình tương ứng. Do sử dụng gói thuê bao định kỳ, đây không phải số tiền thực tế đã chi trả, mà là mức chi phí quy đổi nếu sử dụng API cho cùng lượng token – phương pháp khách quan nhất để so sánh giữa các tháng hoặc các mô hình. Số lượng token: 4,90 tỷ. Trong đó, dữ liệu đọc từ bộ nhớ đệm (cache read) đạt 4,80 tỷ (98,1%), dữ liệu ghi vào bộ nhớ đệm (cache write) đạt 73 triệu (1,5%), dữ liệu đầu ra (output) đạt 18 triệu (0,37%), dữ liệu đầu vào không lưu bộ nhớ đệm (uncached input) đạt 49 nghìn. Giá trị quy đổi API: 1.782 USD. Trong đó, đọc bộ nhớ đệm chiếm 954 USD (54%), ghi bộ nhớ đệm chiếm 490 USD (27%), đầu ra chiếm 338 USD (19%). Theo mô hình: Opus 5.5 là 1.622 USD, Sonnet 5.5 là 135 USD, Sonnet 5 là 25 USD. Phần lớn chi phí thuộc về mô hình Opus. Có ba điểm đáng chú ý được ghi nhận. Cơ chế lưu trữ bộ nhớ đệm (caching) đóng vai trò quyết định. Thao tác đọc bộ nhớ đệm được tính phí bằng 1/10 hoặc thấp hơn so với giá đầu vào thông thường. Nếu tính theo giá đầu vào thông thường, riêng 4,8 tỷ token đọc từ bộ nhớ đệm sẽ tiêu tốn 18.083 USD, gấp 10 lần tổng chi phí cả tháng. Do đó, yếu tố gây tốn kém không nằm ở câu trả lời dài, mà là các tác vụ làm gián đoạn bộ nhớ đệm: thay đổi câu lệnh hệ thống (system prompt) giữa phiên làm việc hoặc tiếp tục tác vụ sau khi bộ nhớ đệm đã hết hạn. Dữ liệu đầu ra chiếm tỷ lệ token rất nhỏ nhưng chi phí lớn: chỉ 0,37% lượng token nhưng chiếm tới 19% giá trị, do đơn giá mỗi token đầu ra cao gấp năm lần token đầu vào. Dữ liệu đầu vào không lưu bộ nhớ đệm gần như bằng 0, chỉ ghi nhận 49 nghìn token trong cả tháng. Gần như toàn bộ token đầu vào đều được ghi vào hoặc đọc từ bộ nhớ đệm. Nếu muốn giảm mức sử dụng, các số liệu này chỉ ra rằng cần tối ưu hóa dung lượng ngữ cảnh (context size) thay vì rút ngắn câu trả lời. Mỗi lượt tương tác đều đọc lại toàn bộ dữ liệu trước đó. Điều này cho thấy việc sử dụng lệnh /clear giữa các tác vụ không liên quan là rất đ...