Người mới dùng coding agent thường có phản xạ tự nhiên: mỗi lần gõ lệnh, họ dừng lại vài giây để gọt giũa từ ngữ, cố viết thật ngắn vì nghĩ gõ càng ít thì hóa đơn càng nhẹ.
Phản xạ đó nghe rất hợp lý, nhưng nó dựa trên một hình dung chưa đúng về cách agent xử lý công việc. Khi nhìn vào terminal, bạn chỉ thấy câu hỏi của mình và câu trả lời của máy. Bạn không thấy toàn bộ cỗ máy đang âm thầm chạy phía sau.
Đến khi tôi trích xuất dữ liệu thật từ quá trình làm website này, con số thực tế làm đảo lộn hoàn toàn cách nghĩ đó: tiền trả cho câu tôi gõ nhỏ đến mức gần như không đáng kể, trong khi khoản tiền quyết định hóa đơn lại nằm ở nơi khác hẳn.
Câu tôi gõ chỉ chiếm 0,4% hóa đơn
Trong bài về chi phí thật của vibe code, tôi từng chia sẻ một nguyên lý: mỗi khi gửi một câu hỏi ngắn, bạn không chỉ gửi riêng câu đó mà đang kéo theo toàn bộ lịch sử làm việc trước đó của cả phiên. Lúc đó tôi hiểu theo lý thuyết, nhưng chưa có số đo chi tiết để biết mức độ lệch pha lớn đến đâu.
Để có câu trả lời xác thực, tôi đã đóng băng dữ liệu từ 27 phiên Claude Code thật trên chính repository này, gồm 4.019 lượt trả lời của assistant, đo vào ngày 2026-08-23. Trong đó, có 3.515 lượt chạy trên model Claude Opus 5 (chiếm 87,5% tổng số lượt).
Quy đổi 3.515 lượt này ra chi phí thực tế theo giá API, tổng số tiền là 580,76 $. Con số bất ngờ nhất nằm ở dòng đầu tiên: toàn bộ phần input chưa cache — tức những câu lệnh mới, những chỉ dẫn mới và những đoạn văn bản do tôi tự gõ trong 27 phiên — chỉ tốn đúng 2,57 $.
2,57 $ trên tổng hóa đơn 580,76 $ tương đương 0,4%.
Điều đó có nghĩa nếu tôi dành cả ngày gọt giũa câu lệnh từ mười từ xuống năm từ, mức tiết kiệm tối đa chỉ là vài phần mười của một phần trăm. 99,6% chi phí còn lại của hệ thống không quan tâm bạn gõ dài hay ngắn. Tiền đang chảy qua những ngả đường hoàn toàn khác.
Ba loại token mà hóa đơn không tách ra cho bạn thấy
Bảng giá của các nhà cung cấp thường chỉ có hai cột: giá input và giá output mỗi triệu token. Cách trình bày phẳng này tạo cảm giác mọi token gửi lên đều có giá như nhau.
Thực tế khi chạy coding agent, token phía input chia thành ba loại rất khác biệt:
Thứ nhất là input chưa cache. Đây là nội dung mới trong lượt gọi hiện tại, chưa từng lưu ở các bước trước. Với Opus 5, loại này tính giá gốc là 5 $ mỗi triệu token.
Thứ hai là token ghi cache. Khi nạp một khối ngữ cảnh lớn và ổn định, hệ thống ghi khối này vào bộ nhớ tạm trên máy chủ.
Thứ ba là token đọc cache. Ở các lượt gọi tiếp theo trong cùng phiên, agent đọc lại ngữ cảnh đã lưu. Đây là loại token rẻ nhất — với Opus 5 chỉ tốn 0,5 $ mỗi triệu token, rẻ hơn mười lần so với input thường.
Tổng hợp 736,7 triệu token phía input qua 27 phiên (trên cả bốn model trong bộ dữ liệu), cơ cấu lộ diện rõ ràng:
Input chưa cache có 632.053 token, chiếm 0,09%. Ghi cache có 23.209.155 token, chiếm 3,15%. Đọc cache có 712.905.045 token, chiếm 96,76%.
Tổng token output chỉ có 3.370.124 token. Tỉ lệ giữa token phía input và token output là 218,6 : 1. Tức để viết ra 1 token kết quả, agent phải duyệt qua trung bình hơn hai trăm token ngữ cảnh đầu vào.
Chỗ 96,76% token thật sự nằm
Tại sao tỉ lệ đọc cache lại chiếm tới 96,76%? Hơn 712 triệu token đó chứa những gì?
Mỗi lượt gọi của agent không chỉ nhận một câu prompt rời rạc. Để ra quyết định chính xác trên một dự án phần mềm thật, mỗi lượt gọi mang theo một gói ngữ cảnh gồm năm thành phần:
hướng dẫn cố định của dự án, lịch sử hội thoại từ đầu phiên, file đã đọc, mô tả các công cụ và kết quả công cụ trả về, rồi mới tới câu vừa gõ, và cuối cùng là câu trả lời.
Đây là lý do vì sao context chứ không phải prompt là nơi quyết định hành vi lẫn chi phí của agent. Càng làm việc lâu trong một phiên, khối ngữ cảnh nền càng dày, khiến mỗi câu hỏi tiếp theo đều phải gánh toàn bộ khối lượng dữ liệu khổng lồ của quá khứ.
Sự phân tán giữa 27 phiên phản ánh rất thật nhịp độ làm việc trên dự án:
Phiên nhỏ nhất có 11 lượt trả lời, phiên lớn nhất 284 lượt, trung vị 161 lượt. Về quy mô dữ liệu, phiên nhỏ nhất tiêu thụ 1,0 triệu token, phiên lớn nhất lên tới 77,1 triệu token, trung vị 24,8 triệu token mỗi phiên.
Tỉ lệ đọc cache theo từng phiên dao động từ 53,0% đến 98,95%, trung vị đạt 96,3%. Ngữ cảnh tích lũy chính là nơi tiêu thụ hầu hết tài nguyên của cỗ máy.
Cache làm hóa đơn nhỏ đi 5,7 lần, và không làm gì khác
Nếu hơn 96% dữ liệu gửi đi là đọc lại ngữ cảnh cũ, thứ cứu người dùng khỏi hóa đơn khổng lồ chính là cơ chế prompt caching.
Bảng phân bổ tiền của 3.515 lượt chạy Claude Opus 5 cho thấy vai trò của từng dòng:
Đọc cache tốn 316,59 $ (54,5% hóa đơn). Ghi cache bậc 1 giờ tốn 190,57 $ (32,8%). Output tốn 71,03 $ (12,2%). Input chưa cache tốn 2,57 $ (0,4%).
Tổng chi phí cho 3.515 lượt này là 580,76 $, trung bình 0,1652 $ cho một lượt trả lời của assistant.
Nếu không có cache và 712,9 triệu token đọc lại đó bị tính theo giá input gốc của Opus 5 (5 $ mỗi triệu token), hóa đơn sẽ là 3.334,82 $.
Cơ chế prompt caching giúp hóa đơn nhỏ đi khoảng 5,7 lần.
Nhưng cần nhớ: cache không làm giảm lượng context được gửi đi mỗi lượt. Nó không làm agent đọc ít file hơn hay lịch sử ngắn lại. Nó chỉ làm phần được gửi lại rẻ hơn. Lượng dữ liệu luân chuyển vẫn nguyên vẹn, chỉ có đơn giá mỗi token đọc lại là giảm.
Bậc một giờ đắt gấp đôi bậc năm phút, và tôi dùng nó 100% số lần
Trong cơ chế của Anthropic, lưu trữ cache chia thành hai bậc thời gian sống:
Bậc 5 phút có giá ghi bằng 1,25 lần giá input thường. Bậc 1 giờ có giá ghi bằng 2 lần giá input thường.
Kiểm tra 23.209.155 token ghi cache trong bộ dữ liệu, toàn bộ 23,2 triệu token đều là bậc 1 giờ. Không có một token nào ở bậc 5 phút.
Nếu toàn bộ ghi ở bậc 5 phút với hệ số 1,25 lần, chi phí cho 3.515 lượt Opus 5 là 509,30 $. Tức bậc 1 giờ đắt hơn 71,46 $.
Tại sao chấp nhận trả thêm 71,46 $ cho bậc 1 giờ?
Vì 5 phút là quá ngắn trong thực tế. Bạn dừng lại đọc tài liệu, kiểm tra giao diện đang chạy, hoặc suy nghĩ cấu trúc dữ liệu là bộ đệm 5 phút đã hết hạn. Khi cache trôi, lượt gọi sau phải ghi lại từ đầu với giá mới, biến nỗ lực tiết kiệm thành đắt đỏ hơn. Bậc 1 giờ cho bạn sự thong thả cần thiết giữa các lượt giao việc.
Dòng chi phí duy nhất tôi không đo được
Bên cạnh các con số rõ ràng về token input, ghi cache hay output, có một dòng chi phí luôn hiện diện nhưng tôi không bóc tách được: chi phí của những lần làm lại (retry).
Khi giao việc phức tạp, agent có thể hiểu sai ý định, sửa nhầm file, hoặc sinh mã không vượt qua bài kiểm thử. Lúc đó bạn buộc phải can thiệp và yêu cầu làm lại.
Mỗi lần retry ngốn một lượt ngữ cảnh đầy đủ, mang theo toàn bộ token đọc cache và output mới. Khoản tiền đó có thật và nằm trọn trong 580,76 $ kia.
Tuy nhiên, transcript không gắn nhãn lượt nào là làm đúng ngay và lượt nào là sửa sai thất bại. Vì không có dữ liệu phân loại, tôi nói thẳng là tôi không biết chi phí retry chiếm bao nhiêu. Không đoán một con số không có căn cứ là câu trả lời đúng ở đây, để giữ trọn tính trung thực cho các số liệu còn lại.
Cách tự đo phiên của chính bạn
Bạn hoàn toàn có thể tự kiểm chứng trên máy của mình thay vì tin vào ước tính chung chung.
Toàn bộ số trong bài này không đến từ một công cụ đo nào cả. Claude Code ghi lại mọi phiên làm việc thành file transcript ngay trên máy bạn, và mỗi lượt trả lời trong đó đã có sẵn bốn con số tôi cần: input chưa cache, ghi cache, đọc cache, output. Tôi chỉ cộng chúng lại. Bạn làm được đúng như vậy với phiên của mình, và tôi khuyên cộng thử một phiên dài — chính tỉ lệ đọc cache của phiên đó sẽ nói cho bạn biết mình đang để phiên phình đến đâu.
Còn để ước tính trước khi bắt đầu, công cụ tính chi phí AI nhận thẳng bốn loại token đó theo từng vai trong workflow, cộng số lần gọi mỗi task, số retry kỳ vọng và tỉ lệ được chấp nhận — rồi trả về chi phí cho mỗi task được chấp nhận, không phải cho mỗi lần gọi.
Một lưu ý quan trọng: hạn mức của gói thuê bao không đo bằng token. Thuê bao hoạt động theo cửa sổ thời gian và công suất động, còn API tính theo token xử lý. Không quy đổi thuê bao sang token để tránh những tính toán sai lệch về mặt kinh tế.
Điều tôi nhận ra
Nhìn lại 27 phiên làm việc, bài học lớn nhất đọng lại nằm ở nhận thức về quy luật chi phí:
Muốn tiết kiệm tiền khi làm việc với coding agent, gọt giũa câu lệnh cho ngắn là việc ít hiệu quả nhất. Chỗ duy nhất đáng để bạn đầu tư công sức tối ưu hóa chính là cách quản lý ngữ cảnh: dọn dẹp các phiên làm việc đã quá dài, tổ chức tài liệu chỉ dẫn ngắn gọn và mạch lạc, chia nhỏ tác vụ lớn thành bước tập trung, và chỉ nạp file thật sự liên quan tới công việc hiện tại.
Trước khi khép lại, tôi muốn nói rõ về phạm vi của những con số trong bài:
Đây là số liệu thực tế của một người, trên một repo cụ thể, trong một khoảng thời gian nhất định — phản ánh thói quen làm việc của riêng tôi chứ không phải mẫu số chung cho tất cả mọi người. Bài viết này nhằm mục đích cung cấp một số liệu thực tế để bạn tham khảo. Bạn hoàn toàn có thể tự kiểm tra con số thật của mình để điều chỉnh cho hợp lý.
Hiểu cách tiền vận hành giúp bạn tự tin làm chủ công cụ: chi tiêu đúng chỗ mang lại hiệu quả, cắt giảm những phần phình to vô ích, và dành trọn vẹn sự tập trung cho việc tạo ra những sản phẩm có giá trị thật.
