Claude Code và agent_summary: cách kiểm tra token của background agent

Một preload không chính thức cho rằng Claude Code định kỳ gửi transcript của background agent đang chạy để tạo trạng thái ngắn trong agents panel. Báo cáo này nên được kiểm chứng bằng telemetry của từng đội trước khi áp dụng workaround.

Một dòng trạng thái ngắn trong agents panel có thể không hề “ngắn” về context phía sau nó.

Theo README của preload không chính thức no-agent-summary.js, Claude Code có thể định kỳ gửi lại transcript đầy đủ của từng background agent để yêu cầu model tạo mô tả hành động gần nhất dài vài từ. Mục đích được nêu là cập nhật trạng thái agent trên panel.

Với DevOps/SRE, điểm đáng chú ý không chỉ là token: đây là một luồng request cần quan sát được. Nhưng các con số đang được chia sẻ là phép đo của tác giả và cộng đồng, không phải số liệu áp dụng mặc định cho mọi đội, repository hay workflow.

Cơ chế được báo cáo: transcript để tạo status ngắn

README mô tả một timer chạy khoảng mỗi 30 giây. Với mỗi background agent, timer này gửi transcript của agent tới model của chính agent và yêu cầu mô tả hành động gần nhất trong 3–5 từ.

Theo tài liệu đó:

Request được gắn querysource = agentsummary trong OpenTelemetry export của Claude Code. Kết quả dùng để cập nhật agents panel, không được đưa trở lại cuộc hội thoại chính. Preload tác động lên timer tạo summary, không nhằm dừng background agent. Khi timer bị chặn, trạng thái từng agent trên panel sẽ không tiếp tục cập nhật.

Một bình luận từ người tự nhận làm việc tại Claude Code nói cơ chế này chỉ áp dụng cho background agent đang hoạt động, không áp dụng cho agent idle. Đây là thông tin từ cộng đồng, không phải tài liệu cấu hình chính thức trong nguồn được cung cấp.

Điểm cần tránh là suy rộng: đây không phải báo cáo rằng mọi lượt chat Claude Code đều phát sinh request kiểu này. Nó được mô tả là hành vi liên quan đến background agent.

Số liệu token: xem như tín hiệu, không phải KPI

Tác giả preload cho biết họ phát hiện hiện tượng này bằng cách nhóm event claudecode.apirequest theo trường querysource trong OpenTelemetry.

Trong một tuần đo của họ, agentsummary được báo cáo chiếm:

16,4% tổng chi phí ước tính của Claude Code; so với 15,7% cho main conversation; khoảng 19,7% tổng số API request.

README cũng dẫn tới bốn phép đo cộng đồng khác trong khoảng 18–26%. Tuy vậy, các số liệu này không phải benchmark độc lập hay cam kết sản phẩm.

Tài liệu cũng lưu ý costusd là ước tính theo từng request của Claude Code, không phải hóa đơn. Với người dùng gói thuê bao, tác giả mô tả tác động chủ yếu là tiêu hao phần headroom của rate limit.

Một số bình luận cộng đồng nêu khả năng chi phí phụ thuộc mạnh vào độ dài context và cache. Vì vậy, thay vì lấy một tỷ lệ phần trăm trên mạng làm chuẩn nội bộ, hãy đo workload của chính mình.

Bắt đầu từ telemetry

Nếu Claude Code của đội đã xuất OpenTelemetry, nơi cần kiểm tra là event:

text claudecode.apirequest

và trường:

text querysource = agentsummary

Ba câu hỏi thực tế cho platform team:

agentsummary xuất hiện bao nhiêu request trong các phiên có background agent? Tỷ trọng chi phí ước tính của nó thay đổi thế nào theo số agent chạy song song? Khi workload giống nhau, tỷ trọng này có khác giữa tác vụ ngắn và tác vụ kéo dài hay không?

Đây là cách biến một báo cáo đang được bàn luận thành dữ liệu vận hành có thể đối chiếu.

Preload được chia sẻ hoạt động ra sao?

no-agent-summary.js là Bun preload. Theo README, nó không sửa binary Claude Code mà nạp qua biến môi trường BUNOPTIONS.

Cách tiếp cận của preload là bọc global.setTimeout. Khi callback của timer có các dấu hiệu mà tác giả dùng để nhận diện summary timer, preload trả về một handle không kích hoạt timer đó. Những timer khác được cho là đi qua bình thường.

README nêu rằng preload đã được thử trên Linux với Claude Code từ 2.1.257 đến 2.1.312; macOS được báo cáo là hoạt động bởi người khác, còn Windows chưa được đo trực tiếp trong tài liệu.

Đây vẫn là mã chạy bên trong tiến trình CLI. Vì vậy, hãy xem nó là workaround không chính thức, không phải setting sản phẩm.

Xác minh thay vì chỉ tin trạng thái panel

Tài liệu nguồn khuyến nghị kiểm tra preload đã được nạp bằng lệnh sau:

sh BUNOPTIONS=--preload=$HOME/.local/share/no-agent-summary.js \ CCAGENTSUMMARYLOG=/tmp/nas.log \ claude --version && cat /tmp/nas.log

Kết quả được mong đợi là một dòng tương tự:

text preload active mode=off …

Sau đó, khi chạy background subagent trong khoảng một hoặc hai phút, log được mô tả có thể xuất hiện:

text summary timer #1 suppressed (setTimeout, delay=30000)

Theo tác giả, kiểm tra đầy đủ nhất vẫn là telemetry: querysource = agentsummary cần giữ ở mức không phát sinh request trong workload đang thử.

Preload cũng có chế độ đối chứng:

sh CCAGENTSUMMARYMODE=pass

Ở chế độ này, module vẫn được nạp và ghi log nhưng không chặn timer. Đây là cách A/B test hữu ích để phân biệt hai trường hợp:

request không xuất hiện vì preload đã chặn timer; request vốn không phát sinh ở workload hiện tại.

Các giới hạn cần nhớ

README nêu rõ preload có thể fail-open sau khi Claude Code cập nhật: nếu cách nhận diện callback không còn khớp, summary sẽ hoạt động trở lại mà không bị chặn.

Một số thay đổi có thể làm điều đó xảy ra gồm:

đổi tên log line hoặc querysource; thay đổi cách callback được bọc; chuyển timer sang API khác thay vì global.setTimeout.

Vì vậy, tài liệu khuyến nghị xác minh lại sau mỗi lần cập nhật Claude Code.

Tài liệu cũng lưu ý daemon, PTY host và các process nền có thể kế thừa môi trường từ lúc daemon được khởi động. Nếu thay đổi BUNOPTIONS, cần dừng daemon cũ trước khi mở phiên mới:

sh claude daemon stop --any

Checklist cho đội DevOps/SRE

[ ] Kiểm tra OTEL theo claudecode.apirequest và querysource. [ ] Đo riêng workload có background agent, thay vì suy luận từ mọi phiên Claude Code. [ ] Xem các tỷ lệ 16,4% hay 18–26% là số liệu tham khảo, không phải chuẩn chung. [ ] Nếu thử preload, xác minh log nạp module và request agentsummary. [ ] Dùng CCAGENTSUMMARYMODE=pass làm đối chứng A/B. [ ] Xác minh lại sau mỗi lần cập nhật Claude Code. [ ] Coi preload là mã can thiệp runtime không chính thức và review trước khi dùng rộng rãi.

Kết luận

Báo cáo về agentsummary đặt ra một câu hỏi vận hành hợp lý: background agent đang tạo thêm bao nhiêu request ngoài tác vụ chính?

Câu trả lời không nằm ở một tỷ lệ token lan truyền trên mạng, mà ở telemetry của từng đội. Nếu agentsummary thực sự chiếm tỷ trọng đáng kể trong môi trường của bạn, preload được chia sẻ là một lựa chọn thử nghiệm có thể đo được — đổi lại là agents panel không còn cập nhật status và cần xác minh lại sau mỗi bản cập nhật.