Ngay lúc này (ngày 15), Anthropic đã đăng một bài viết trên blog.
Thông tin cốt lõi là: Mọi người, đừng đốt token vô ích nữa, chúng tôi đều không thể xem tiếp được!
Vì vậy, công ty đã liệt kê chi tiết sáu nguyên tắc tiết kiệm tiền, xin được gửi trước:
1. Xong việc là /clear. Sửa xong một lỗi thì xóa hội thoại hiện tại, đừng để các tệp đã đọc và kết quả lệnh của nhiệm vụ trước kéo vào nhiệm vụ tiếp theo, chiếm chỗ vô ích trong ngữ cảnh.
2. Ngay từ đầu hãy đặt mô hình và cường độ suy luận (effort level). Nếu chuyển đổi giữa chừng, bộ đệm gợi ý tích lũy trước đó sẽ mất hiệu lực hoàn toàn, toàn bộ lịch sử hội thoại sẽ phải được tính toán lại từ đầu với giá đầy đủ.
3. Dùng @ để tham chiếu tệp, đừng gõ đường dẫn thủ công. Dùng @ để đính kèm trực tiếp tệp vào tin nhắn, Claude không cần tốn thêm một lần gọi công cụ để đọc. Nếu bạn chỉ gõ tên tệp, Claude có thể sẽ tìm kiếm một vòng trước rồi thử mở vài tệp, tất cả các thao tác này đều sẽ đi vào lịch sử hội thoại và được mang theo mỗi lượt sau.
4. Thêm tham số im lặng (quiet flag) cho các lệnh có đầu ra nhiều. Viết một dòng cấu hình tương tự như --reporter=dot trong CLAUDE.md, để đầu ra kiểm tra chỉ in vài dòng tóm tắt, không phải hàng trăm dòng chi tiết. Đầu ra càng ngắn thì càng chiếm ít ngữ cảnh.
5. Thực hiện /compact trước khi nghỉ. Nén khi hội thoại còn trong bộ đệm, chi phí chỉ bằng một phần mười so với bình thường. Nếu bạn quay lại sau khi bộ đệm hết hạn rồi mới nén, sẽ phải đọc lại toàn bộ với giá đầy đủ rồi mới nén.
6. Giao nhiệm vụ đầu ra lớn cho Agent con. Agent con chạy trong một cửa sổ ngữ cảnh độc lập, sau khi hoàn thành chỉ truyền kết luận về, các tệp đọc và đầu ra lệnh chạy trong quá trình sẽ không đi vào hội thoại chính của bạn.
Hành trình của một token
Sử dụng Claude Code làm việc, API tính theo lượng, phí định kỳ hàng tháng chia làm ba mức từ 20 đô la đến 200 đô la.
Theo tính toán của công ty, nhà phát triển tiêu thụ trung bình 13 đô la token mỗi ngày, chi tiêu hàng tháng trong khoảng 150 đến 250 đô la.
Đây mới chỉ là mức trung bình. Cùng sửa một lỗi, cách hỏi khác nhau, chi phí có thể chênh lệch gấp vài lần.
Hơn nữa, mỗi lượt hội thoại đều kéo theo toàn bộ nội dung của tất cả các lượt trước đó gửi lại, phiên càng dài thì mỗi lượt càng đắt.
Tiền này chi vào đâu, phải nói từ logic định giá của token.
Mỗi lần bạn nhập một lệnh vào Claude Code, phía sau xảy ra hai việc.
Việc thứ nhất gọi là tiền điền (prefill), tức là mô hình đọc toàn bộ yêu cầu của bạn một lần, bao gồm lời nhắc hệ thống, CLAUDE.md, tin nhắn của bạn, và tất cả những gì tích lũy trong hội thoại trước đó. Đây đều là token đầu vào.
Việc thứ hai gọi là giải mã (decode), tức là quá trình mô hình viết ra từng chữ một, bao gồm suy nghĩ của nó, lời gọi công cụ và văn bản cuối cùng bạn nhìn thấy. Đây đều là token đầu ra.
Điểm khác biệt then chốt nằm ở đây.
Tiền điền là song song, đưa tất cả token đầu vào qua GPU một lần. Giải mã là tuần tự, mỗi lần nhả ra một token đều phải chạy mô hình một lần. Phản hồi 200 token tức là 200 lần tính toán độc lập.
Vì vậy cũng không khó hiểu tại sao token đầu ra lại đắt hơn token đầu vào 5 lần.
Trên cơ sở này, hóa đơn cuối cùng phụ thuộc vào hai việc.
Thứ nhất là mô hình, quyết định đơn giá của mỗi token.
Opus 5, đầu vào 5 đô la/triệu token, đầu ra 25 đô la.
Sonnet 5, đầu vào 2 đô la, đầu ra 10 đô la.
Haiku 4.5, đầu vào 1 đô la, đầu ra 5 đô la.
Thứ hai là cường độ suy luận, quyết định số lượng token.
Phần lớn token đầu ra trong một phiên là token suy nghĩ, cường độ suy luận kiểm soát chính là lượng này. Cường độ suy luận càng cao, mô hình suy nghĩ càng lâu, token suy nghĩ đầu ra càng nhiều. Giữa max và low có thể chênh lệch vài lần.
Dùng Sonnet cho việc đơn giản, chỉ dùng Opus cho việc khó. Tiền dùng dao mổ trâu giết gà là tiền oan uổng nhất.
Bộ đệm gợi ý, là công cụ tiết kiệm tiền lớn nhất
Trong định giá token còn có một biến số khổng lồ, đó là bộ đệm.
Mỗi yêu cầu của Claude Code đều bắt đầu từ tiền tố giống nhau, tức là lời nhắc hệ thống, định nghĩa công cụ, CLAUDE.md và lịch sử hội thoại.
Nếu tiền tố của yêu cầu lần này giống hệt từng byte so với lần trước, máy chủ sẽ không tính toán lại mà trực tiếp tải kết quả tính toán lần trước.
Đọc bộ đệm chỉ tốn 0.1 lần giá đầu vào bình thường, tiết kiệm trực tiếp 90%.
Ghi vào bộ đệm đắt hơn một chút, cao nhất là 2 lần. Nhưng ghi chỉ xảy ra một lần, mỗi lượt sau đó đều được hưởng giá đọc 0.1 lần.
Ví dụ.
Giả sử lịch sử hội thoại của bạn có 50 nghìn token. Không đi qua bộ đệm, mỗi lượt chỉ việc đọc lại 50 nghìn token này cũng phải trả giá đầy đủ. Nhưng chỉ cần trúng bộ đệm, 50 nghìn token tương tự chỉ cần tốn một phần mười số tiền.
Một phiên chạy hai ba mươi lượt, chiết khấu tích lũy từ việc trúng bộ đệm là con số khổng lồ.
Đây là đòn bẩy kiếm lợi lớn nhất của bạn.
Nhưng bộ đệm có một điểm yếu chí mạng. Nó phải khớp liên tục từ byte đầu tiên của yêu cầu, bất kỳ chỗ nào ở giữa thay đổi, từ đó về sau toàn bộ sẽ mất hiệu lực.
Cụ thể, có tổng cộng sáu trường hợp:
1. /model chuyển mô hình: Bộ đệm của mỗi mô hình độc lập. Chuyển từ Sonnet sang Opus, toàn bộ lịch sử hội thoại được tiền điền lại với giá Opus, không có chiết khấu.
2. /effort chuyển cường độ suy luận: Cường độ suy luận cũng là một phần của khóa bộ đệm, sau khi chuyển đổi toàn bộ lịch sử hội thoại đều phải tính toán lại.
3. Bật/tắt Fast mode: Hiệu quả giống hai loại trước, bộ đệm trực tiếp mất hiệu lực.
4. /compact nén hội thoại: Hội thoại được viết lại thành tóm tắt, nội dung ban đầu hoàn toàn không khớp, bộ đệm cũ trực tiếp mất hiệu lực.
5. Thời gian hết hạn: Bộ đệm của người dùng đăng ký duy trì 1 giờ, người dùng API mặc định 5 phút. Sau khi hết hạn, lượt tiếp theo sẽ tính toán lại toàn bộ.
6. Khôi phục phiên cũ: Quá lâu bộ đệm đã không còn, gần 100% phải tính toán lại với giá đầy đủ.
Tin xấu là, chỉ cần trúng một cái có nghĩa là toàn bộ lịch sử hội thoại từ 0.1 lần quay về giá gốc.
Tin tốt là, khi bạn biết điều gì sẽ làm bộ đệm mất hiệu lực, bạn sẽ biết cách bảo vệ nó.
Ví dụ, ngay từ đầu phiên hãy khóa chặt mô hình và cường độ suy luận, toàn bộ quá trình không chuyển. Không thực hiện /compact khi bộ đệm còn nóng, đợi đến lúc chuẩn bị nghỉ mới chạy.
Ở đây, còn có một cái bẫy ẩn.
Chế độ opusplan mỗi lần vào ra plan đều chuyển mô hình. Vào một lần, bộ đệm mất hiệu lực một lần. Ra, lại mất hiệu lực một lần. Nhảy qua nhảy lại, mỗi lần nhảy đều là một lần prefill giá đầy đủ.
Phiên của bạn, đang âm thầm phình to
Bộ đệm giúp bạn giảm chi phí gửi lại lịch sử lặp đi lặp lại xuống còn một phần mười.
Nhưng có một việc nó không giúp được. Bản thân lịch sử của bạn đang phình to từng lượt.
Mỗi lần Claude đọc một tệp, nội dung tệp được thêm vào hội thoại. Mỗi lần Claude chạy một lệnh, đầu ra cũng được thêm vào. Kể từ lượt được thêm đó, mỗi lượt sau đều mang theo.
Lượt hội thoại thứ 40 đang gửi lại toàn bộ nội dung tích lũy từ lượt 1 đến lượt 39.
Sự tăng trưởng này, là cấp độ gần như bình phương O(n2).
CClaude Code có một cơ chế đáy.
Đầu ra lệnh vượt quá 30000 ký tự, sẽ không nhét vào hội thoại nữa, mà viết vào một tệp tạm thời, trong hội thoại chỉ để lại một câu tóm tắt. Nhưng đầu ra dưới 30000 thì không ai quản.
Ví dụ, một khung kiểm tra chạy xong, in 400 dòng bản ghi thông qua, mỗi dòng vài chục ký tự, tổng lượng chưa đến 3 vạn, không đạt ngưỡng này.
Thế là 400 dòng này nguyên vẹn ở lại trong lịch sử hội thoại, mỗi lượt sau đều kéo theo gửi lại một lần.
Đối với điều này, blog của Anthropic đã đưa ra vài cách giảm cân rất thực tế.
1. @ tham chiếu tệp.
Đừng nhập đường dẫn thủ công để Claude tự tìm. @ tham chiếu sẽ đính kèm trực tiếp tệp vào tin nhắn, tiết kiệm một lần thao tác đọc.
Nếu bạn chỉ nói tên tệp, Claude có thể sẽ grep tìm một vòng trước, mở vài tệp xem cái nào đúng. Sau đó những lần thử này sẽ đều đi vào lịch sử hội thoại, chỉ tăng thêm chi phí.
2. Thêm quiet flag cho các lệnh noisy.
Viết một dòng "run tests with npx vitest run --reporter=dot" trong CLAUDE.md, sau này mỗi lần chạy kiểm tra chỉ xuất ra vài dòng kết quả dạng chấm, không phải hàng trăm dòng chi tiết. Một phút cấu hình, sau này mỗi phiên tiết kiệm vài trăm dòng ngữ cảnh.
3. Subagent cách ly nhiệm vụ đầu ra lớn.
Subagent chạy trong cửa sổ ngữ cảnh độc lập của chính nó, sau khi hoàn thành chỉ truyền đáp án về, các tệp đọc và đầu ra lệnh trong quá trình đều bị loại bỏ. Thích hợp cho những việc như "đi xem nhật ký có gì bất thường" "giúp tôi xem qua tệp lớn này". Bạn chỉ cần kết luận, không cần quá trình.
Còn một điều quan trọng nhất.
4. /clear chuyển nhiệm vụ.
Sửa xong một lỗi là /clear, bắt đầu việc tiếp theo. Các tệp, đầu ra lệnh, khám phá trung gian của lỗi trước, tất cả đều không liên quan đến nhiệm vụ sau, nhưng nếu không xóa, chúng sẽ chiếm chỗ, ăn token trong mỗi lượt sau.
Nếu không muốn xóa sạch hoàn toàn, /compact có thể nén hội thoại thành tóm tắt. Một đến hai vạn token có thể nén xuống còn một đến ba nghìn.
Ngoài ra, trong blog còn đề cập đến một thao tác ít người biết nhưng miễn phí, /rewind.
Nếu vài lượt cuối chạy lệch hướng, /rewind trực tiếp cắt bỏ vài lượt đó, bộ đệm phía trước hoàn toàn không động.
Quản lý token, cũng là một phẩm chất của nhà phát triển
Phân tích xong các thao tác trên, bạn sẽ phát hiện một quy luật. Người viết code đang mọc ra một bộ kỹ năng mới.
Không liên quan đến framework và ngôn ngữ, mà là biết nên chọn mô hình nào, quản lý ngữ cảnh thế nào, giữ bộ đệm ra sao, mở cường độ suy luận bao nhiêu là phù hợp.
Những khả năng này một năm trước không tồn tại. Nhưng bây giờ nó lại quyết định trong cùng một nhiệm vụ, bạn tiêu 3 đô la hay 30 đô la.
Bản thân Anthropic là ví dụ tốt nhất.
80% code của họ dựa vào AI viết, lượng code hợp nhất một năm tăng gấp 8 lần, kiểm tra chuẩn tăng tốc 52 lần. Sử dụng AI với cường độ này, nếu không ai quản lý token, chỉ riêng chi phí suy luận đã có thể ăn hết ngân sách.
Từ góc độ này, thay vì nói bài viết blog này nói về kỹ năng tiết kiệm tiền, chi bằng nói đó là một bản năng mới mà người viết code thời đại AI cần mọc ra——
Biết mỗi thao tác của bạn đang tiêu hao cái gì, biết làm thế nào để cùng một ngân sách làm được nhiều việc hơn.
Người đọc hiểu nó, vặt được không chỉ là vài đô la token.
Tài liệu tham khảo:
https://claude.com/blog/maximizing-the-value-of-your-claude-code-sessions
Bài viết này từ tài khoản công chúng WeChat "Tân Trí Nguyên", tác giả: Môi Tây
