Hãy hình dung một bản sửa lỗi chỉ thay đổi 12 dòng. Tác nhân đọc dự án, viết kế hoạch, khởi chạy một tác nhân hỗ trợ, chạy thử nghiệm, đọc các lỗi rồi thử lại trước khi tạo ra bản vá đó.

Hóa đơn bao gồm mọi yêu cầu đã được gửi để tạo ra kết quả đó.

Điều đó khiến một tác vụ ngắn lại dễ bị tính phí quá mức đến bất ngờ. Một cuộc trò chuyện dài có thể mang theo các tệp cũ vào những yêu cầu sau. Một công cụ có thể trả về hàng trang dữ liệu trong khi quyết định tiếp theo chỉ cần một bản ghi. Nhiều tác nhân có thể lặp lại cùng một cuộc điều tra.

Bạn có thể tìm thấy các khoản chi phí này trong lịch sử thực thi. Hãy bắt đầu với một tác vụ, theo dõi mọi thứ nó tiêu tốn và kiểm tra xem kết quả có thực sự đạt yêu cầu hay không. Sau đó, thay đổi phần đang làm những việc không cần thiết.

1. Định giá cho một tác vụ hoàn thành

Chọn một tác vụ bạn thường lặp lại: sửa lỗi được báo cáo, chuẩn bị bản tóm lược nghiên cứu hoặc kiểm tra một lô hồ sơ khách hàng. Xác định tiêu chí hoàn thành trước khi chạy.

Với một lỗi cần sửa, tiêu chí chấp nhận có thể yêu cầu một bài kiểm thử tái hiện lỗi ban đầu, kết quả vượt qua sau khi thay đổi và không có lỗi trong các bài kiểm thử tích hợp bị ảnh hưởng. Một thông báo nói rằng lỗi đã được sửa không đáp ứng các điều kiện đó.

Gán ID cho tác vụ. Giữ nguyên ID đó qua các lần thử lại, các tác nhân trợ lý, bước xác minh và kết quả cuối cùng. Ghi một ID yêu cầu riêng cho mỗi lần gọi mô hình để phát hiện các lần gọi trùng lặp trong nhật ký.

Phép tính cốt lõi là:

Chi phí trên mỗi tác vụ được chấp nhận = tổng chi tiêu đã ghi nhận / số tác vụ được chấp nhận

Tính cả những lần thử thất bại. Nếu 10 tác vụ tổng cộng tốn 8 USD nhưng chỉ có 4 tác vụ đạt yêu cầu, chi phí là 2 USD cho mỗi tác vụ được chấp nhận. Hãy ghi kèm tỷ lệ chấp nhận 40% bên cạnh con số đó. Nếu không có tác vụ nào đạt, hãy báo cáo khoản chi tiêu và số tác vụ được chấp nhận bằng 0; tỷ lệ này không xác định.

Theo dõi riêng thời gian con người dành để sửa chữa. Một quy trình tiết kiệm 1 USD phí API nhưng cần 20 phút dọn dẹp là một sự đánh đổi đáng được nhìn thấy.

Với công việc dùng API, hãy lưu phản hồi mức sử dụng của nhà cung cấp, ID mô hình, ngày áp dụng giá, phí công cụ, kết quả tác vụ và dấu thời gian. Nếu thiếu dữ liệu mức sử dụng sau khi hết thời gian chờ, hãy đánh dấu chi phí là chưa rõ và đối chiếu với hồ sơ của nhà cung cấp. Việc không có phản hồi không chứng minh rằng yêu cầu đó miễn phí. Nếu còn bất kỳ yêu cầu nào chưa được định giá, hãy ghi rõ tổng chi phí của lô chưa đầy đủ.

Người dùng Claude Code có thể bắt đầu với /usage và /context. Lệnh đầu giúp kiểm tra mức sử dụng; lệnh thứ hai cho biết những gì đang chiếm chỗ trong hội thoại. Với gói thuê bao, ước tính số tiền cục bộ không phải là hóa đơn riêng, và cửa sổ ngữ cảnh là giới hạn khác với hạn mức gói của bạn.

2. Tìm phần ngữ cảnh liên tục xuất hiện lại

Tin nhắn mới nhất của bạn chỉ là một phần trong yêu cầu gửi đến mô hình. Trong Claude Code, yêu cầu cũng có thể chứa hướng dẫn dự án, mô tả công cụ, lịch sử hội thoại, nội dung tệp và kết quả công cụ trước đó.

Giả sử một tài liệu 12.000 token không thay đổi xuất hiện trong 8 yêu cầu. Qua các lần gọi đó, tài liệu đóng góp 96.000 token đầu vào. Các lượt đọc bộ nhớ đệm đủ điều kiện có thể được tính phí ở mức thấp hơn. Tuy vậy, tài liệu có thể không liên quan đến một số quyết định trong đó.

Xem chuỗi xử lý của một tác vụ cụ thể. Những tệp nào đã được đọc? Những đầu ra nào vẫn còn trong hội thoại? Yêu cầu nào gây ra mức tăng lớn nhất? Đến cuối cùng, tác nhân còn dùng những chi tiết đó không?

Với lỗi trong tổng tiền hóa đơn, hãy bắt đầu từ đầu vào gây lỗi, phép tính, các nơi gọi phép tính đó và những bài kiểm thử bao quát nó. Để tác nhân lần theo các tham chiếu khi cần thêm thông tin. Tải trước toàn bộ kho mã nguồn có thể khiến mọi lượt tiếp theo phải mang theo tài liệu chưa từng góp phần vào việc sửa lỗi.

Giữ toàn bộ bằng chứng trên ổ đĩa. Trả về kết quả ngắn gọn kèm đường dẫn tệp và đủ chi tiết để kiểm tra bản gốc. Với một lần chạy kiểm thử, thông tin đó bao gồm lệnh, mã thoát, tên các bài kiểm thử thất bại, lỗi liên quan và vị trí nhật ký.

Một bản tóm tắt bỏ sót manh mối duy nhất sẽ khiến công việc nhiều hơn. Hãy giữ nguyên lỗi chính xác, mã định danh bị ảnh hưởng và bằng chứng cần thiết cho hành động tiếp theo.

3. Kiểm tra xem bộ nhớ đệm có đang hoạt động hữu ích không

Bộ nhớ đệm lời nhắc tái sử dụng phần đầu khớp và đủ điều kiện của một yêu cầu. Đặt các hướng dẫn ổn định ở trước, dữ liệu tác vụ thay đổi ở sau.

Trong quy trình Claude API tùy chỉnh, dấu thời gian nằm trước ranh giới bộ nhớ đệm có thể tạo một mục khác nhau ở mỗi lần gọi. Đặt ranh giới sau phần nội dung được lặp lại. Kiểm tra tài liệu hiện hành về bộ nhớ đệm cho mô hình và cấu trúc yêu cầu của bạn.

So sánh số lượt đọc và ghi bộ nhớ đệm giữa các yêu cầu. Nhiều lượt ghi nhưng ít lượt đọc là dấu hiệu nên kiểm tra các thay đổi tiền tố, độ dài tối thiểu đủ điều kiện, thời hạn lưu trữ và thời điểm.

Đọc từ bộ nhớ đệm vẫn tốn tiền. Số lượt đọc cao có thể cho thấy bộ nhớ đệm đang hoạt động; đồng thời hãy kiểm tra xem ngữ cảnh đó có giúp hoàn thành tác vụ hay không.

Trong Claude Code, các tác nhân phụ thông thường có ngữ cảnh và cách hoạt động của bộ nhớ đệm riêng. Một nhánh rẽ hoạt động khác. Việc nén ngữ cảnh cũng dùng một yêu cầu mô hình và dựng lại ngữ cảnh hội thoại. Đừng lên lịch nén ngữ cảnh thủ công vài phút một lần nếu chưa đo lường kết quả.

4. Thu gọn dữ liệu công cụ trả về

Phản hồi của công cụ có thể trở thành đầu vào cho các lệnh gọi mô hình tiếp theo. Vì vậy, một phản hồi lớn có thể ảnh hưởng đến nhiều thứ hơn cả yêu cầu ban đầu dùng để lấy dữ liệu.

Xét một báo cáo đơn hàng hằng ngày. Một công cụ lấy toàn bộ đơn hàng, mô hình đọc từng dòng, rồi một yêu cầu khác yêu cầu tính tổng. Một tập lệnh có thể lọc bản ghi, tính tổng và trả về những trường hợp ngoại lệ cần phán đoán.

Cách đó thay đổi những gì được đưa đến mô hình. Đồng thời, nó tạo ra một phép tính mà bạn có thể kiểm thử độc lập.

Áp dụng cách tương tự cho nhật ký, bảng tính và kết quả tìm kiếm. Lọc theo khách hàng, ngày, lỗi hoặc loại bản ghi liên quan trước khi trả dữ liệu. Nêu rõ bộ lọc đã dùng, số lượng đã xử lý, dữ liệu có bị cắt bớt hay không, cùng đường dẫn hoặc mã định danh của bằng chứng gốc.

Kiểm tra phân trang. Xử lý trang đầu tiên rồi trình bày như thể đó là toàn bộ tập dữ liệu sẽ cho bạn một câu trả lời sai nhưng rẻ hơn.

Các kết quả trung gian có thể được giữ trong môi trường thực thi, trong khi chỉ dữ liệu đã chọn mới được đưa đến mô hình. Bạn có thể áp dụng nguyên tắc này bằng một tập lệnh nhỏ chạy cục bộ mà không cần xây dựng một hệ thống tác nhân phức tạp.

Các định nghĩa công cụ cũng chiếm ngữ cảnh khi được tải. Một số ứng dụng khách đã trì hoãn việc tải đầy đủ định nghĩa cho đến khi cần. Hãy kiểm tra thiết lập thực tế trước khi gỡ bỏ tích hợp: chỉ riêng số lượng kết nối không cho biết mức tiêu thụ token của chúng.

5. Lưu lại quy trình sau khi đã tìm ra cách làm

Hãy để ý những tác vụ mà tác nhân liên tục tìm lại cùng các lệnh, viết lại cùng một kế hoạch hoặc bắt đầu lại từ đầu để quyết định cần chạy những bài kiểm thử nào.

Khi đã hiểu quy trình, hãy lưu lại. Đưa các hướng dẫn riêng của dự án vào một tài liệu ngắn có thể tái sử dụng. Đưa các phép tính cố định, thao tác chuyển đổi tệp và chuỗi lệnh vào một tập lệnh đã được kiểm thử.

Với lỗi hóa đơn, một tập lệnh có thể chuẩn bị dữ liệu kiểm thử, thực hiện phép tính, đối chiếu giá trị mong đợi và báo cáo kết quả. Tác nhân vẫn cần chẩn đoán sự sai lệch bất ngờ và chọn cách khắc phục phù hợp. Nhưng nó không cần phải nghĩ ra lệnh kiểm thử mỗi lần.

Gắn quy trình với các giả định của nó. Ghi lại các phần phụ thuộc cần thiết, đầu vào mong đợi và điều kiện buộc quy trình phải dừng. Khi môi trường thay đổi, một lỗi hiển thị rõ sẽ dễ chẩn đoán hơn một thông báo thành công có vẻ hợp lý.

Các lần kiểm tra trạng thái lặp đi lặp lại cũng nên được xử lý tương tự. Nếu dịch vụ cung cấp mã ID tác vụ, hãy dùng sự kiện hoàn tất hoặc một hàm thăm dò có giới hạn. Chỉ gọi lại mô hình khi tác vụ hoàn thành, thất bại hoặc vượt quá thời hạn.

Với các hành động tạo hoặc gửi nội dung, cần đặc biệt thận trọng khi thử lại. Kiểm tra xem lần đầu đã thành công hay chưa trước khi lặp lại. Nếu được hỗ trợ, dùng lại khóa idempotency có thể ngăn một phản hồi không chắc chắn tạo thành hai đơn hàng hoặc hai tin nhắn.

6. Giao cho mỗi tác nhân một nhiệm vụ riêng biệt

Các tác nhân chạy song song có thể rút ngắn thời gian hoàn thành. Nhưng các lệnh gọi, ngữ cảnh và hoạt động phối hợp của chúng cũng làm tăng tổng chi phí.

Hãy chia nhỏ công việc khi các nhiệm vụ độc lập và đầu ra dễ kết hợp. Một tác nhân có thể tái hiện lỗi đã báo cáo, trong khi tác nhân khác kiểm tra hợp đồng giao diện bị ảnh hưởng. Giao cho mỗi tác nhân một câu hỏi rõ ràng và một kết quả xác định.

Tránh gửi cho nhiều trợ lý cùng một chỉ dẫn chung chung là kiểm tra mọi thứ. Việc đó có thể tạo ra nhiều bản điều tra trùng lặp, rồi lại cần thêm một lượt nữa để đối chiếu các bản tóm tắt.

Một lần bàn giao hữu ích cần nêu rõ nhiệm vụ, các tệp liên quan, những thay đổi được phép, đầu ra mong đợi và điều kiện dừng. Yêu cầu cung cấp đường dẫn bằng chứng và các phát hiện cần thiết cho bước tiếp theo. Giữ lại công việc trung gian dài dòng trong các tệp của trợ lý.

Hãy chủ động phân công việc xác minh. Chạy các lượt kiểm tra tập trung trong khi triển khai, rồi chạy các lượt kiểm tra rộng hơn bắt buộc trên kết quả tổng hợp. Chạy lại một lượt kiểm tra khi mã đã thay đổi, lần chạy trước thất bại hoặc có bằng chứng mới làm phát sinh lý do. Ghi lại lý do của mỗi lần chạy.

Đo lường riêng thay đổi mô hình và thay đổi quy trình làm việc. Khi thử mô hình hoặc thiết lập suy luận khác, hãy giữ nguyên cùng một bộ tác vụ và các bài kiểm tra chấp nhận. Tính cả số lần thử lại và thời gian sửa lỗi trong phần so sánh. Chi phí mỗi lần gọi thấp hơn chỉ có ích nếu toàn bộ công việc vẫn đáng thực hiện.

7. Đọc đúng các trường về mức sử dụng

Các nhà cung cấp khác nhau báo cáo đầu vào được lưu trong bộ nhớ đệm theo cách khác nhau. Sao chép công thức của một nhà cung cấp rồi áp dụng cho nhật ký của nhà cung cấp khác có thể tạo ra hóa đơn trông hợp lý nhưng lại sai.

Trong phản hồi Claude Messages tiêu chuẩn, input_tokens, cache_creation_input_tokens và cache_read_input_tokens là các nhóm đầu vào riêng biệt. Việc tạo bộ nhớ đệm cũng có thể được chia theo thời hạn lưu trữ. Hãy đối chiếu từng nhóm với mức giá tương ứng.

Trong lược đồ OpenAI Responses hiện tại, đầu vào được lưu trong bộ nhớ đệm và số lượng ghi bộ nhớ đệm áp dụng nằm trong tổng đầu vào. Cần trừ các mục này theo tài liệu trước khi tính giá đầu vào thông thường. Hãy dùng cách tính của nhà cung cấp dành cho đúng mô hình và API bạn đang gọi.

Giữ phản hồi mức sử dụng gốc bên cạnh bản ghi đã chuẩn hóa. Như vậy, bạn có thể sửa phép tính khi nhà cung cấp, mô hình hoặc giá thay đổi.

Một số tính năng cũng tạo thêm phần việc bị tính phí. Với tính năng nén ngữ cảnh của Claude API, số lượng đầu vào và đầu ra cấp cao nhất không bao gồm lượt lặp nén ngữ cảnh. Hãy tính giá các mục trong usage.iterations một lần, dùng các trường mức sử dụng của từng mục. Đừng cộng lại các số liệu cấp cao nhất.

Việc thực thi công cụ, tìm kiếm, lưu trữ trên máy chủ và lưu trữ dữ liệu có thể bị tính phí riêng. Nếu không bao gồm các khoản này, hãy ghi rõ đó là chi phí mô hình. Với các yêu cầu truyền trực tuyến, hãy dùng tổng mức sử dụng cuối cùng khi có và tránh tính lặp các bản cập nhật cộng dồn.

8. Thử nghiệm trên một lô tác vụ

Sau đây là một phép tính minh họa mà bạn có thể tái hiện. Số lượng yêu cầu, lượng token, phí công cụ và kết quả dưới đây đều là giả định. Không có tác nhân nào được chạy để tạo ra chúng.

Tác vụ ví dụ trích xuất ba giá trị cùng các đoạn văn bản làm căn cứ từ mỗi trong bốn tài liệu. Một kết quả chỉ đạt nếu JSON, các giá trị và bằng chứng nguồn đều chính xác.

Cả hai kịch bản đều giả định có ba kết quả được chấp nhận, một lần thử bị từ chối cần thử lại và một tác vụ cuối cùng thất bại. Đó là năm lần thử cho bốn tác vụ. Mỗi lần thử đều góp phần vào hóa đơn.

Kịch bản đầu tiên có 15 yêu cầu mô hình: 375.000 token đầu vào không được lưu trong bộ nhớ đệm và 15.000 token đầu ra. Theo mức giá tiêu chuẩn của Claude Haiku 4.5 được kiểm tra vào ngày 7 tháng 9 năm 2026, đầu vào có giá 1 USD cho mỗi triệu token và đầu ra có giá 5 USD cho mỗi triệu token. Phí mô hình là 0,45 USD. Cộng thêm 0,06 USD phí công cụ bên ngoài giả định, tổng cộng là 0,51 USD.

Chia 0,51 USD cho ba kết quả được chấp nhận: 0,17 USD cho mỗi kết quả được chấp nhận.

Kịch bản thứ hai giả định có 10 yêu cầu với ít đầu vào mới hơn và một phần đầu vào được lưu trong bộ nhớ đệm. Chi phí mô hình được chia như sau:

• 55.000 token đầu vào không được lưu trong bộ nhớ đệm, với giá 1 USD cho mỗi triệu token: 0,055 USD.

• 25.000 token ghi bộ nhớ đệm với thời hạn năm phút, giá 1,25 USD cho mỗi triệu token: 0,03125 USD.

• 25.000 token ghi bộ nhớ đệm với thời hạn một giờ, giá 2 USD cho mỗi triệu token: 0,05 USD.

• 50.000 token đọc từ bộ nhớ đệm, giá 0,10 USD cho mỗi triệu token: 0,005 USD.

• 7.500 token đầu ra, giá 5 USD cho mỗi triệu token: 0,0375 USD.

Tổng phí mô hình là 0,17875 USD. Cộng thêm 0,05 USD phí công cụ bên ngoài giả định: tổng cộng 0,22875 USD cho mọi lần thử, hay 0,07625 USD cho mỗi kết quả được chấp nhận. Các thời hạn lưu bộ nhớ đệm khác nhau minh họa những nhóm tính phí, chứ không phải thiết lập được khuyến nghị.

Các con số này cho biết chi phí của mức sử dụng đã nêu. Chúng không chứng minh rằng lọc ngữ cảnh hoặc thay đổi ranh giới bộ nhớ đệm sẽ tạo ra những số liệu đó hay duy trì chất lượng. Để so sánh thực tế, cần ghi lại các yêu cầu và kiểm tra kết quả độc lập. Các tác vụ thất bại vẫn phải được tính vào tổng.

9. Thử nghiệm trên quy trình của chính bạn

Chọn một nhóm nhỏ các tác vụ tiêu biểu và giữ nguyên đầu vào. Bao gồm một trường hợp thành công thông thường, một trường hợp khó và một tác vụ từng thất bại. Viết các bước kiểm tra chấp nhận trước khi thay đổi.

Chạy quy trình hiện tại và lưu lại bản ghi yêu cầu. Đánh dấu thời điểm tài liệu không cần thiết được đưa vào hội thoại, một quy trình bị dựng lại, một bước kiểm tra trùng lặp được chạy hoặc một lỗi không thay đổi khiến tác vụ được thử lại.

Thay đổi một cơ chế. Lọc kết quả lớn của công cụ. Lưu chuỗi lệnh được dùng lặp lại. Sửa ranh giới bộ nhớ đệm. Thu hẹp nhiệm vụ của một trợ lý. Giữ nguyên mô hình và tiêu chí chấp nhận trong lần so sánh đó.

Chạy lại cùng đầu vào trong một môi trường kiểm thử sạch. Phân biệt các lượt chạy ban đầu với các lượt chạy khi bộ nhớ đệm đã được làm nóng. Lặp lại đủ số lần để xem kết quả có nhất quán không, và giữ các lần thử thất bại trong tổng số.

Dùng lời nhắc này với một tác nhân lập trình có thể truy cập phần triển khai và nhật ký của bạn:

Kiểm tra quy trình làm việc này và các nhật ký thực thi hiện có.

Xác định phạm vi tác vụ và các bước kiểm tra chấp nhận. Lần theo các lệnh gọi của tác nhân cha, lệnh gọi của trợ lý, các lần thử lại, bước xác minh và kết quả cuối cùng.

Tạo báo cáo cục bộ thể hiện chi phí mô hình đã ghi nhận, các khoản phí công cụ riêng, dữ liệu mức sử dụng còn thiếu, tác vụ được chấp nhận, tác vụ thất bại, thời gian hoàn thành và sự can thiệp của con người. Dùng các trường mức sử dụng riêng của nhà cung cấp hiện tại cùng bảng giá có ghi ngày. Giữ lại phản hồi mức sử dụng thô. Khử trùng lặp các ID yêu cầu.

Xác định khoản chi phí lớn nhất có thể tránh được dựa trên nhật ký. Chỉ ra các lệnh gọi cụ thể và giải thích vì sao phần việc đó không cần thiết. Tách riêng các khoản ước tính khỏi số tiền đã ghi nhận.

Đề xuất một thay đổi và cách so sánh dùng cùng đầu vào, mô hình và bước kiểm tra chấp nhận. Tách riêng các lượt chạy ban đầu và các lượt chạy khi bộ nhớ đệm đã được làm nóng. Dừng lại nếu thiếu bằng chứng cần thiết và nêu chính xác những gì còn thiếu.

Đừng thực hiện các lệnh gọi API mất phí hoặc thay đổi quy trình đang hoạt động trong lúc kiểm tra này. Lưu báo cáo và bản vá đề xuất để xem xét.

Các bước kiểm tra chấp nhận giúp phép so sánh trung thực. Nếu việc lọc nhật ký che mất lỗi hoặc mô hình nhỏ hơn cần được sửa đi sửa lại, hãy ghi nhận kết quả đó và điều chỉnh thay đổi.

Tôi chia sẻ các quy trình AI thực tiễn tại đây. Hãy theo dõi để đón xem nội dung tiếp theo.