Mọi người đều nói Claude Code lãng phí Token, nhưng thực sự lãng phí đến mức nào? Lần này cuối cùng cũng có người tính ra con số.
Gần đây có một thử nghiệm so sánh khá thú vị, đến từ nhóm Composio. Họ đã sử dụng cùng một mô hình Kimi K3, đưa vào ba framework (harness) agent khác nhau để chạy — Claude Code, Hermes và Kimi Code — tổng cộng thử nghiệm 28 nhiệm vụ hoàn toàn giống nhau.
Kết quả, tỷ lệ thành công của ba harness khi hoàn thành nhiệm vụ tương đương nhau: Kimi Code thành công 22/28, Hermes thành công 21, Claude Code thành công 20. Khoảng cách không lớn.
Thứ thực sự tạo ra sự khác biệt, là mức tiêu thụ token. Một nhiệm vụ giống nhau, chạy trên các harness khác nhau, lượng token sử dụng có thể chênh lệch tới 30 lần!
Xét theo giá trị trung vị, Kimi Code sử dụng khoảng 6.1 vạn token, Hermes khoảng 6.7 vạn, còn Claude Code tăng vọt lên 34 vạn, gấp khoảng 6 lần Kimi Code.
Tính theo giá Kimi K3 là 3 đô la cho mỗi triệu token đầu vào (token đầu vào thường chiếm khoảng 95% trong quy trình agent), chi phí trung bình cho mỗi nhiệm vụ là: Kimi Code 0.22 đô la, Hermes 0.28 đô la, Claude Code lên tới 2 đô la. Sự chênh lệch rất rõ ràng.
Tốc độ cũng khác nhau. Thời gian thực hiện trung vị, Hermes nhanh nhất, 179 giây; Kimi Code 297 giây; Claude Code 348 giây.
Vậy nên, nhanh nhất là Hermes, tiết kiệm token nhất là Kimi Code, hai điều này không trùng khớp.
Từ đó, nhóm Composio đưa ra một kết luận trực tiếp: Nếu bạn muốn giảm chi phí agent, trước tiên hãy xem mình đang dùng harness nào, thay vì vội vàng đổi mô hình. Theo dữ liệu của họ, bản thân harness có thể tạo ra sự chênh lệch chi phí lên tới 9 lần, trong khi khả năng thể hiện của các mô hình thực tế lại tương đương nhau.
Sebastian Raschka sau khi xem kết quả này cũng đã đăng bài, nói rằng điều này tương đồng với quan sát của ông trước đây khi dùng Qwen3.6: Claude Code với tỷ lệ thành công tương đương, lượng token sử dụng thường gấp 2 đến 3 lần nhiều harness khác.
Ông đưa ra một vài nguyên nhân có thể: Liệu có phải là chưa được tối ưu hóa nhiều? Có lỗi? Hay là cố tình thiết kế như vậy (vì có thể có ích trong những nhiệm vụ khó hơn)? Ông cho biết cần dành thời gian kiểm tra kỹ lưỡng hơn.
Sau đó, ông bổ sung thêm quan sát từ bài viết của mình tháng trước về coding agent local. Lúc đó ông đã phân tích tại sao Claude Code dùng nhiều token hơn, và phát hiện sự khác biệt chủ yếu nằm ở token đầu vào, chứ không phải token đầu ra. Nói cách khác, Claude không hề viết nhiều gấp đôi nội dung. Nhật ký cho thấy, harness của Claude trong tương tác đa luồng liên tục đẩy thêm nhiều ngữ cảnh trở lại mô hình, bao gồm thông điệp trước đó, lệnh gọi công cụ, đầu ra lệnh và nội dung tệp. Ví dụ, trong một lần chạy Claude sử dụng khoảng 57.8 vạn token đầu vào, nhưng đầu ra chỉ khoảng 4500 token, trải qua 25 lượt. Vì vậy, giải thích khả dĩ hơn là harness của Claude khi chạy đa bước agent, sẽ tích lũy hoặc tính toán lịch sử prompt lớn hơn.
Những kết quả kiểm tra này dường như cho thấy một xu hướng không thể bỏ qua: Tầm quan trọng của harness không thua kém gì bản thân mô hình.
Một bài báo gần đây (từ Writer, một công ty làm nền tảng AI Agent doanh nghiệp) đã hệ thống hóa rõ điều này: Nó sử dụng thử nghiệm biến số kiểm soát chứng minh rằng việc thay đổi lớp harness có tác dụng cắt giảm chi phí mạnh hơn so với việc thay đổi mô hình, và tất cả các mô hình đều được hưởng lợi.
Cụ thể, họ triển khai một thử nghiệm nghiêm ngặt "biến số kiểm soát": Trong điều kiện cố định 22 nhiệm vụ doanh nghiệp và 6 mô hình cơ bản (Claude Sonnet 4.6, Gemini 3.1, Gemini Flash 3.5, Qwen 3.6, GLM 5.1, Palmyra X6), chỉ thay thế lớp điều phối — thay vòng lặp agent cấp sản xuất truyền thống bằng Harness riêng của Writer.
Kết quả thử nghiệm cho thấy: Chi phí trung bình cho mỗi nhiệm vụ giảm 41% (0.21 đô la → 0.12 đô la), độ trễ trung vị rút ngắn 44% (48 giây → 27 giây), lượng tiêu thụ Token giảm 38% (14.2k → 8.8k), trong khi chất lượng hoàn thành nhiệm vụ cơ bản không đổi (0.78 → 0.81, do cỡ mẫu nhỏ có thể coi là không có sự khác biệt đáng kể). Về mặt hiệu quả chi phí, chất lượng có thể đạt được trên mỗi đô la tăng mạnh 82%, đồng thời số nhiệm vụ có thể hoàn thành trên mỗi triệu Token tăng từ 54.9 lên 92.0.
Vậy nên, sau khi mô hình trở thành "điện, nước, khí", harness mới là chiếc máy lạnh quyết định hóa đơn tiền điện? Nói cách khác: Trước đây có người nói "mô hình chính là sản phẩm", bây giờ là "harness chính là sản phẩm"?
Vì harness quan trọng như vậy, vậy thì từ nay về sau hóa đơn có phải cũng nên tính chi tiết hơn?
Có người chỉ ra rằng, chúng ta cần thiết phải thêm mục "thuế harness" vào benchmark hiện tại. Đặc biệt là xét đến việc một khi lệnh gọi công cụ và thử lại rơi vào vòng lặp, mức thuế này không tăng tuyến tính.
Nói cách khác, cuộc đua agent trong tương lai, hiệp một so về "có làm được không", hiệp hai sẽ so về "làm việc giống nhau, ai tiết kiệm hơn" — và bí mật tiết kiệm tiền, không nằm ở mô hình, mà nằm ở harness.
Trong quá trình chạy Agent, bạn đã từng có trải nghiệm tương tự chưa? Chào mừng thảo luận tại phần bình luận.
Bài viết từ tài khoản công chúng WeChat "Cỗ máy Chi Tâm" (ID:almosthuman2014), tác giả: Cỗ máy Chi Tâm
