Hầu như bất kỳ ai hướng dẫn dùng coding agent cũng sẽ lặp lại cùng một lời khuyên quen thuộc: hãy xóa phiên thường xuyên để tiết kiệm token. Lý lẽ đưa ra nghe rất xuôi tai — một phiên làm việc càng kéo dài thì lịch sử hội thoại càng dày, và mỗi câu bạn gõ vào sẽ phải cõng theo toàn bộ những gì đã diễn ra trước đó.
Nhưng khi tôi đem toàn bộ 27 phiên làm việc thật trên website này ra đo đạc chi tiết, những con số thực tế lại kể một câu chuyện hoàn toàn trái ngược. Nếu tính chi phí trung bình trên từng lượt phản hồi, những phiên ngắn ngủi mà chúng ta tưởng là tiết kiệm hóa ra lại đắt hơn những phiên dài rất nhiều.
Trong bài trước về chỗ tiền thật sự đi, chúng ta đã thấy câu gõ mới chỉ chiếm 0,4% hóa đơn, còn phần lớn chi phí nằm ở việc đọc lại bộ nhớ đệm (cache). Khi nhìn sâu hơn vào độ dài của từng phiên, chính cơ chế bộ nhớ đệm này đã tạo ra một nghịch lý kinh tế thú vị giữa phiên ngắn và phiên dài.
Lời khuyên ai cũng nói, và số đo nói ngược
Thói quen dùng lệnh xóa phiên liên tục bắt nguồn từ một trực giác cơ bản: không ai muốn một câu hỏi đơn giản vào buổi chiều phải trả tiền cho cả buổi sáng làm việc. Nhiều người thậm chí đặt ra nguyên tắc cứ sau vài chục phút hoặc sau năm mười câu lệnh là gõ xóa phiên để làm mới lại từ đầu.
Để kiểm chứng xem thói quen đó có thật sự tiết kiệm tiền hay không, tôi chia 27 phiên làm việc trong bộ dữ liệu thành hai nhóm rõ rệt: nhóm phiên ngắn có số lượt trả lời không quá 50 lượt, và nhóm phiên dài có số lượt trả lời từ 200 lượt trở lên.
Bộ dữ liệu ghi nhận 3 phiên ngắn (từ 50 lượt trở xuống) và 6 phiên dài (từ 200 lượt trở lên). Khi áp biểu giá của Claude Opus 5 để tính toán chi phí trung bình cho từng lượt trả lời của assistant, kết quả thu được rất bất ngờ:
Ở nhóm phiên ngắn, chi phí trung bình cho mỗi lượt trả lời lên tới 0,2762 $. Trong khi đó, ở nhóm phiên dài, chi phí trung bình cho mỗi lượt trả lời chỉ còn 0,1653 $.
Lấy chi phí mỗi lượt của phiên dài chia cho phiên ngắn, tỉ lệ chỉ là 0,5983 — tức là xét trên từng lượt tương tác đơn lẻ, phiên dài rẻ hơn phiên ngắn tới gần 40%. Mỗi lần bạn nhận được một câu trả lời trong một phiên dài, bạn chỉ phải trả khoảng sáu phần mười số tiền so với việc nhận cùng câu trả lời đó trong một phiên vừa mở.
Vì sao phiên ngắn lại đắt hơn mỗi lượt
Nguyên nhân khiến phiên ngắn trở nên đắt đỏ trên mỗi lượt gọi nằm ở chi phí khởi tạo ngữ cảnh ban đầu.
Khi bạn mở một phiên mới toanh, agent bắt đầu với một bộ nhớ đệm hoàn toàn trống rỗng. Để có thể làm việc, nó phải đọc và ghi toàn bộ ngữ cảnh nền vào bộ nhớ đệm tạm thời: hướng dẫn cố định của dự án, các file mã nguồn liên quan, và định nghĩa của các công cụ.
Trong biểu giá của Anthropic, thao tác ghi cache bậc 1 giờ có đơn giá đắt gấp đôi so với giá input thông thường. Ngược lại, thao tác đọc từ cache lại rẻ hơn giá input thông thường tới mười lần — với Claude Opus 5 là 0,5 $ so với 5 $ cho mỗi triệu token.
Ở các phiên ngắn, tỉ lệ đọc cache trung bình chỉ đạt 75,55% lượng input. Chi phí ghi cache ban đầu bị phân bổ cho quá ít lượt tương tác, khiến mỗi lượt gọi phải gánh một phần chi phí khởi tạo rất lớn.
Ngược lại, ở các phiên dài từ 200 lượt trở lên, tỉ lệ đọc cache trung bình đạt tới 97,81%. Khối ngữ cảnh nền sau khi được nạp và ghi một lần duy nhất ở đầu phiên sẽ được tái sử dụng liên tục hàng trăm lần với mức giá đọc cache siêu rẻ (0,5 $ mỗi triệu token). Khoản phí ghi đắt đỏ ban đầu được chia mỏng ra cho hàng trăm lượt gọi, kéo mức giá trung bình của mỗi lượt tương tác xuống mức cực thấp.
Chỗ lời khuyên cũ vẫn đúng
Thấy phiên dài có đơn giá mỗi lượt rẻ hơn, liệu chúng ta có nên giữ một phiên duy nhất và làm việc liên tục từ ngày này qua ngày khác?
Câu trả lời dứt khoát là không. Và đây là chỗ chúng ta cần rạch ròi về mặt giới hạn đo lường.
Đây là chi phí cho mỗi lượt trả lời, không phải chi phí cho mỗi việc làm xong. Một phiên dài có thể tốn nhiều lượt hơn cho cùng một việc, và bộ dữ liệu này không tách được điều đó. Tổng tiền của một phiên vẫn tăng theo độ dài.
Khi một phiên kéo dài quá mức, tổng chi phí tuyệt đối của phiên đó vẫn liên tục tăng lên vì mỗi lượt gọi mới vẫn phải đọc lại toàn bộ khối ngữ cảnh khổng lồ tích lũy từ quá khứ. Hơn nữa, khi lịch sử trò chuyện quá dài và chứa nhiều nội dung không còn liên quan, agent rất dễ bị phân tâm, hiểu sai ngữ cảnh, hoặc sinh mã nguồn thừa thãi, dẫn đến việc bạn phải tốn thêm nhiều lượt gọi phụ để sửa chữa.
Một lượt gọi rẻ đi 40% không có ý nghĩa gì nếu bạn phải mất tới năm lượt gọi lòng vòng để hoàn thành một việc mà lẽ ra chỉ cần hai lượt trong một phiên sạch sẽ. Đơn giá mỗi lượt giảm không đồng nghĩa với việc tổng chi phí công việc giảm.
Ba phiên đắt nhất chiếm gần một phần tư hóa đơn
Tổng chi phí đo được trên toàn bộ 27 phiên làm việc của dự án là 675,96 $. Sự phân bổ chi phí giữa các phiên có sự chênh lệch rất lớn.
Phiên làm việc rẻ nhất trong bộ dữ liệu chỉ tiêu tốn 2,59 $. Đó là những phiên ngắn, tập trung xử lý một nhiệm vụ gọn gàng rồi kết thúc.
Ở chiều ngược lại, phiên làm việc đắt nhất tiêu tốn tới 62,04 $ — gấp gần hai mươi bốn lần phiên rẻ nhất.
Đặc biệt, khi cộng tổng chi phí của ba phiên đắt nhất trong toàn bộ 27 phiên, con số này chiếm tới 23,84% tổng hóa đơn (tỉ lệ top3_share_of_total là 0,2384), tức gần một phần tư toàn bộ số tiền phát sinh trên dự án.
Con số này cho thấy một quy luật rất rõ ràng: phần lớn ngân sách của bạn không bị tiêu hao bởi những phiên làm việc bình thường hằng ngày, mà bị chi phối bởi một vài phiên làm việc cá biệt kéo dài quá lâu và tích lũy khối lượng ngữ cảnh quá lớn. Những phiên cá biệt đó chính là nơi rủi ro chi phí phát sinh mạnh nhất nếu bạn không chủ động kiểm soát.
Vậy khi nào thì nên xóa phiên
Nếu xóa phiên quá sớm làm tăng đơn giá mỗi lượt gọi do phải ghi cache lại từ đầu, còn để phiên quá dài lại làm tăng tổng tiền và giảm độ tập trung của agent, đâu là điểm cân bằng hợp lý?
Câu trả lời không nằm ở một con số cố định như mười lăm phút hay ba mươi lượt gọi. Câu trả lời nằm ở nguyên tắc chuyển đổi mục tiêu công việc và chỉ số dung lượng ngữ cảnh thực tế.
Bạn nên xóa phiên khi đổi sang một việc khác.
Khi bạn vừa hoàn thành việc sửa form đăng ký và chuyển sang viết tính năng xuất báo cáo, toàn bộ file mã nguồn, thông báo lỗi và lịch sử trao đổi của việc cũ không còn giá trị gì cho việc mới. Giữ lại phiên cũ lúc này chỉ khiến bộ nhớ đệm phải lưu giữ những thứ rác không liên quan, vừa làm loãng sự tập trung của mô hình, vừa khiến bạn phải trả tiền đọc lại những dữ liệu vô ích ở mỗi lượt gọi tiếp theo.
Ngược lại, nếu bạn vẫn đang trong cùng một mạch công việc — đang lần theo một luồng xử lý phức tạp, đang gỡ một lỗi phát sinh từ bước trước, hoặc đang tinh chỉnh giao diện dựa trên mã nguồn vừa viết — thì việc giữ nguyên phiên làm việc là lựa chọn tối ưu nhất. Bạn tận dụng được khối ngữ cảnh đã nạp sẵn, hưởng trọn vẹn mức giá đọc cache rẻ mười lần, và giúp agent nắm bắt mạch tư duy liền mạch mà không phải nạp lại dữ liệu từ đầu.
Chỉ dấu context window mà tôi dùng mỗi ngày
Bên cạnh việc đổi tác vụ, có một chỉ dấu kỹ thuật rất cụ thể giúp bạn biết chính xác khi nào một phiên làm việc đang bắt đầu đi vào vùng "quá tải".
Với Claude Code, việc quản lý này rất thuận tiện: bạn chỉ cần bấm vào biểu tượng vòng tròn bên cạnh phần chọn model là sẽ thấy ngay dung lượng context window hiện tại cùng các mốc đếm ngược reset quota. Đây là một chỉ dấu cực kỳ quan trọng trong thói quen hằng ngày của tôi.
Với mỗi phiên làm việc, tôi thường cố gắng giữ dung lượng context window trong khoảng 250k – 350k / 1M token. Ở vùng dung lượng này, agent hoạt động ở phong độ tốt nhất: vừa có đủ chiều sâu ngữ cảnh để hiểu toàn diện logic mã nguồn, vừa duy trì tốc độ phản hồi nhanh, độ chính xác cao và tối ưu chi phí đọc cache.
Tuy nhiên, đối với những tác vụ lớn hoặc chuỗi công việc phức tạp liên hoàn, tôi vẫn có thể để phiên làm việc kéo dài lên tới ngưỡng 500k token, nhưng trường hợp này rất hạn chế. Khi context chạm ngưỡng đó, nguy cơ agent bị loãng thông tin và chi phí tích lũy mỗi lượt tăng lên đáng kể — đó là tín hiệu rõ ràng nhất để tôi chủ động tóm tắt lại đầu việc, đóng phiên cũ và mở một phiên mới tinh gọn.
Điều tôi nhận ra
Nhìn vào những con số thực tế giữa phiên dài và phiên ngắn, bài học lớn nhất là đừng tối ưu hóa một cách máy móc theo những lời khuyên truyền miệng.
Xóa phiên là một công cụ mạnh, nhưng xóa phiên liên tục sau mỗi câu hỏi ngắn chỉ khiến bạn liên tục trả chi phí ghi cache ban đầu mà không kịp tận dụng lợi thế của việc đọc cache. Ngược lại, để một phiên chạy vô tận bất chấp việc chuyển đổi ngữ cảnh sẽ dẫn tới những phiên cá biệt ngốn hàng chục đô la mà hiệu quả công việc lại đi xuống.
Muốn ước tính và tối ưu hóa chi phí cho quy trình làm việc của riêng mình, bạn có thể nhập các thông số thực tế vào công cụ tính chi phí AI để thấy rõ sự khác biệt giữa các kịch bản tương tác.
Quản lý phiên làm việc thông minh không phải là đếm từng lượt gọi hay canh từng phút trên đồng hồ. Đó là sự hiểu biết về bản chất của bộ nhớ đệm: giữ phiên khi cần ngữ cảnh sâu cho cùng một mạch việc, và chủ động xóa phiên ngay khi bước sang một nhiệm vụ mới.
