AI agent của bạn hết token quá nhanh? Đây là nơi token của chúng tôi đã đi

Nếu AI agent của bạn hay hết token, hoặc trang usage tăng nhanh hơn khối lượng việc làm được, bài này dành cho bạn.

Hóa đơn

Trong mười ngày, chúng tôi để các coding agent chạy một dự án thật: 136 phiên, mỗi phiên nhận một ticket và đi từ lập kế hoạch, viết code, review đến QA. Việc thì xong. Rồi chúng tôi mở trang usage: khoảng 680 triệu token quy đổi.

Chúng tôi tưởng đã biết thủ phạm. Mỗi lần review, agent gọi thêm vài agent phụ (subagent), mỗi con soi một góc: logic, bảo mật, dọn code. Tất cả đều chạy model lớn. Cách sửa có vẻ hiển nhiên: chuyển agent phụ sang model nhỏ, rẻ hơn, thế là hóa đơn giảm.

Trước khi sửa, chúng tôi quyết định đo đã. Hóa ra đó là quyết định đáng giá nhất của cả tuần.

Bất ngờ thứ nhất: agent phụ không phải vấn đề

Agent phụ chỉ chiếm 19%. 81% còn lại đến từ cuộc hội thoại chính, tức là agent đang trực tiếp làm việc.

Nghĩa là kể cả khi agent phụ chạy miễn phí, bốn phần năm hóa đơn vẫn còn nguyên. Cách sửa chúng tôi định làm là có thật, nhưng nhỏ. Khoản tốn lớn nằm ở chỗ chúng tôi không nhìn tới.

Bất ngờ thứ hai: cache trúng 98% mà vẫn đắt

Tỉ lệ trúng prompt cache của chúng tôi là 98,4%. Nghe như chẳng còn gì để tối ưu. Thật ra không phải vậy, và lý do chính là ý quan trọng nhất của bài này.

Agent không nhớ gì giữa hai lần gọi model. Ở mỗi lượt, nó gửi lại toàn bộ cuộc hội thoại: chỉ dẫn, các file đã đọc, mọi kết quả tool từ đầu tới giờ. Cache giúp việc gửi lại rẻ đi, chỉ còn khoảng một phần mười giá bình thường, nhưng không miễn phí.

Phiên trung vị của chúng tôi mang khoảng 165 nghìn token ngữ cảnh và chạy khoảng 150 lượt. Một phần mười của 165 nghìn, nhân 150 lần, vẫn là rất nhiều token, dù lần nào cũng trúng cache. Riêng phần đọc cache đã hơn nửa hóa đơn.

Nên chi phí của một agent đại khái là:

những gì nó mang theo × số lượt nó chạy

Cache chỉ làm rẻ đơn giá, không đổi được công thức. Còn khi trượt cache, vì mở phiên mới hay vì agent chờ quá lâu, toàn bộ ngữ cảnh phải ghi lại với giá gấp 1,25 đến 2 lần. Một lần khởi động lạnh tốn ngang khoảng hai mươi lượt ấm.

Nhìn theo cách đó rồi thì chỗ rò rỉ hiện ra khá rõ.

Rò rỉ 1: những lượt tốn vào việc đoán

Lượt nào cũng đọc lại cả bàn làm việc, nên không có lượt thừa nào là rẻ. Chúng tôi đếm được:

• 644 lần gọi --help. Agent phải đoán flag của lệnh vì chỉ dẫn không ghi rõ, rồi đi tra.
• Khoảng 230 lần bị từ chối ở cùng một lệnh ghi kết quả kiểm tra: sai tên gate, thiếu tham số, thừa một key trong file kết quả. Mỗi lần bị từ chối là một lượt, mỗi lần thử lại là thêm một lượt nữa.
• 22 trên 68 lần review là review lại, đọc lại toàn bộ thay đổi chỉ để kiểm tra một bản sửa nhỏ. Có ticket bị review đầy đủ tới sáu lần.

Không có lỗi nào ở đây là do model kém. Đó là chỉ dẫn để hở, và agent phải trả tiền để lấp chỗ hở. Cách sửa là viết cho rõ: flag chính xác, cách xử lý lỗi chính xác, và quy tắc lần review thứ hai chỉ xem phần đã đổi kể từ lần trước.

Rò rỉ 2: những phiên phải khởi động lạnh

Dự án chạy theo ticket, mỗi ticket một phiên agent. Một nửa số ticket cần thêm phiên, và mỗi phiên thêm tốn khoảng 2 triệu token: agent đọc lại kế hoạch, làm quen lại code, chạy lại review và QA của riêng nó.

Gần như phiên thêm nào cũng cùng một nguyên nhân: một ticket anh em trong cùng giai đoạn sửa đúng những file đó, hoặc đổi một interface mà ticket này đang dùng. Chúng tôi đã chia việc theo kích thước ("mỗi giai đoạn 2 đến 5 ticket"), và các mảnh cứ giẫm lên chân nhau.

Quy tắc mới: chia theo ngữ cảnh, không chia theo kích thước. Việc trên cùng một module, hay trên một interface còn đang định hình, giữ thành một ticket trong một phiên dài, dù nó lớn. Chỉ tách khi các phần thật sự độc lập.

Rò rỉ 3: cái đồng hồ đặt trễ một phút

Bộ điều phối (Foreman) của chúng tôi thỉnh thoảng thức dậy để xem các worker. Lời nhắc trạng thái của nó mặc định 3600 giây. Còn prompt cache sống đúng một giờ. Thế là hễ bộ điều phối ngồi yên chờ tới lượt nhắc, nó lại thức dậy ngay sau lúc cache vừa hết hạn: 21% số lần thức dậy là khởi động lạnh, mỗi lần ghi lại 0,2 đến 0,45 triệu token.

Cách sửa chỉ là một con số: 3300 giây.

Cũng cái đồng hồ đó gây hại theo chiều ngược lại. Chúng tôi từng đặt cache của agent phụ sống một giờ, mà loại cache này ghi tốn gấp 2 thay vì 1,25. Phần lớn agent review chỉ sống vài phút và chẳng bao giờ đọc lại cache đó. Riêng thiết lập này đã tốn khoảng 4%. Chúng tôi bỏ nó đi.

Rò rỉ 4: hành lý mang theo trước khi bắt đầu

Trước khi agent đọc file đầu tiên, nó đã mang sẵn một gánh: danh sách skill đã cài, chỉ dẫn của dự án, file mục lục memory. Gánh này nằm trong mọi lượt.

Gánh của chúng tôi đã phình tới khoảng 7.500 token mô tả skill, phần lớn không bao giờ được dùng: skill đồng bộ từ đâu đó đã quên, bản sao cũ, skill vận hành mà chỉ con người mới gọi. File mục lục memory còn vượt giới hạn đọc (25,1 KB so với 24,4 KB), nên phần cuối của nó bị cắt mất mà không ai hay.

Chúng tôi gỡ các skill không dùng (chuyển sang chỗ khác, không xóa), biến skill vận hành thành lệnh người dùng tự gõ, và gọn lại mục lục memory. Danh sách giảm từ khoảng 7,5 nghìn xuống khoảng 3 nghìn token, ở mọi phiên, trong mọi lượt.

Những gì chúng tôi chọn không làm

Có những khoản tiết kiệm mà cái giá còn lớn hơn:

• Rút ngắn prompt của skill: nhiều nhất 1–2%, trong khi prompt đã được tinh chỉnh từng chữ.
• Gộp các agent bỏ phiếu khi review: khoảng 2%, nhưng phá vỡ nguyên tắc "một phát hiện, một phiếu" giúp review trung thực.
• Nén hội thoại sớm hơn: khoảng 10%, nhưng agent sẽ quên nhiều hơn. Đánh đổi đó là quyền của người dùng, không phải của chúng tôi.
• Model nhỏ hơn cho agent soi logic: đó là nơi tìm ra bug thật. Chúng tôi đánh giá chúng bằng số bug tìm được, không bằng token.

Các agent review phần dọn code thì đã chuyển sang model nhẹ hơn, và không phiếu nào bị bỏ.

Hiện giờ ra sao

Nói thật: bài này mô tả số liệu trước đã đo, và những thay đổi làm ngày 25/10/2026. Số liệu sau cần khoảng một tuần làm việc thật. Chúng tôi đã ghi trước con số mình kỳ vọng, và sẽ công bố số thật, dù có khớp hay không.

Tự kiểm tra agent của bạn trong năm phút

Chúng tôi đóng gói cả cuộc điều tra thành một skill, để lần kiểm tra sau chỉ còn một lệnh. Skill này có trong 2build từ bản v1.108.

1. Cài hoặc cập nhật 2build.

brew tap 2found/2build https://github.com/2found/2build
brew install 2found/2build/bbs   # đã cài rồi thì chạy: bbs update
bbs install                      # tự nhận Claude Code, Codex, Antigravity

Sau đó khởi động lại agent.

2. Nhờ agent kiểm tra.

Bạn có thể thêm phạm vi, ví dụ: /bbs:token-audit 14 ngày gần nhất, chỉ repo này.

3. Đọc báo cáo. Cuối báo cáo có một khối ngắn như sau:

STATUS: DONE
VERDICT: AUDITED
WINDOW: last 14 days · claude · 42 sessions · 96.1M
SPLIT: main 78% (read 51% · write 15% · output 12%) · subagents 22%
BACKGROUND: listing ≈6.8k tokens · instructions 9.2 KB · memory 23.9 KB/182 lines
PROPOSALS:
1. Fix the docs behind 310 --help lookups — saves ≈3% — risk none
2. Hide 14 unused skills — saves ≈2% — risk low
...
REJECTED: shorter skill text — under 1%
NEXT: apply item 1

Các con số trên chỉ là ví dụ. Số của bạn sẽ khác, và đó chính là mục đích.

Skill xem những gì:

• Token đã đi đâu: hội thoại chính so với agent phụ; đọc cache, ghi cache và output; theo từng skill, từng model, từng agent phụ.
• Ma sát: lệnh bị lỗi, số lần tra --help, lệnh lặp lại, skill chạy lặp lại.
• Hành lý mỗi phiên: từng skill đã cài và có được dùng trong khoảng thời gian đó không, bản trùng và bản cũ, các file chỉ dẫn, mục lục memory so với giới hạn của nó.

Skill đọc log phiên của Claude Code, Codex và OMP ngay trên máy bạn. Nó chỉ in số đếm và tên lệnh, không bao giờ in nội dung hội thoại, và không gửi gì ra ngoài. Nó chỉ đề xuất. Không có gì thay đổi cho tới khi bạn bảo nó áp dụng một đề xuất, và mỗi đề xuất đều ghi rõ tiết kiệm được bao nhiêu, rủi ro là gì.

Không dùng 2build? Tự kiểm tra mấy điểm này

1. Đo trước khi đổi model. Xem hội thoại chính hay agent phụ tốn hơn.
2. Đếm lượt, đừng chỉ đếm token. Lượt nào cũng đọc lại mọi thứ agent đang mang.
3. Tìm dấu hiệu phải đoán: gọi --help, thử lại cùng một lệnh, review lặp lại.
4. Giữ phiên sống khi các việc dùng chung file. Mở phiên mới tốn ngang khoảng hai mươi lượt ấm.
5. So các bộ hẹn giờ với thời gian sống của cache. Nhắc trễ một phút là lần nào cũng khởi động lạnh.
6. Bớt những gì nạp sẵn: skill không dùng, file chỉ dẫn dài, mục lục memory vượt giới hạn.

Agent của bạn có lẽ không hoang phí. Nó chỉ đang trả tiền, ở mỗi lượt, cho mọi thứ nó mang theo và mọi thứ nó buộc phải đoán. Làm cả hai nhỏ lại, hóa đơn sẽ giảm theo.

Chi tiết kỹ thuật, phương pháp đo và đầy đủ các bảng: token economics và Foreman cache economics trong repo 2build (tiếng Anh).