Original Title: Tại Sao Các Phiên OpenClaw Của Tôi Đã Đốt 21.5 Triệu Token Trong Một Ngày (Và Điều Gì Thực Sự Đã Khắc Phục Vấn Đề)
Original Author: MOSHIII
Translation: Peggy, BlockBeats

Editor's Note: In the current rapid adoption of Agent applications, many teams have encountered a seemingly abnormal phenomenon: the system operates normally, but the token cost continues to rise unnoticed. This article, through the breakdown of a real OpenClaw workload, reveals that the cause of cost explosion often does not come from user input or model output, but from the overlooked cached prefix replay. The model repetitively reads a large historical context in each call round, resulting in massive token consumption.

The article combines specific session data to demonstrate how large intermediate products such as tool outputs, browser snapshots, JSON logs, etc., are continuously written into historical context and repeatedly read in the agent loop.

Through this case study, the author proposes a clear optimization approach: from context structure design, tool output management to compaction mechanism configuration. For developers building Agent systems, this is not only a technical troubleshooting record but also a practical money-saving strategy.

Below is the original article:

I analyzed a real OpenClaw workload and discovered a pattern that I believe many Agent users will recognize:

The token usage looks very "active"

The replies seem normal

But the token consumption suddenly explodes

Below is the breakdown of this analysis, the root cause, and the practical fix path.

TL;DR

The biggest cost-driving factor is not overly long user messages. It is the massive cached prefix being replayed repeatedly.

Looking at the session data:

Total tokens: 21,543,714

cacheRead: 17,105,970 (79.40%)

đầu vào: 4,345,264 (20.17%)

đầu ra: 92,480 (0.43%)

Nói cách khác: Chi phí phần lớn cuộc gọi không phải là xử lý ý định người dùng mới, mà là việc đọc lặp đi lặp lại ngữ cảnh lịch sử rất lớn.

Thời Điểm "Đợi Chút, Tại Sao Lại Như Thế?"

Ban đầu, tôi nghĩ lượng sử dụng token cao đến từ: đoạn thông tin người dùng rất dài, tạo ra lượng đầu ra lớn, hoặc cuộc gọi công cụ đắt tiền.

Nhưng mẫu chính thực sự chi phối là:

đầu vào: vài trăm đến vài ngàn token

cacheRead: mỗi cuộc gọi từ 170,000 đến 180,000 token

Nghĩa là, mô hình đọc lặp đi lặp lại cùng một tiền tố lớn ở mỗi vòng.

Phạm Vi Dữ Liệu

Tôi đã phân tích dữ liệu ở hai mức:

1. Nhật ký thời gian chạy (runtime logs)
2. Bản ghi cuộc trò chuyện (session transcripts)

Cần lưu ý:

Nhật ký chạy chủ yếu được sử dụng để quan sát tín hiệu hành vi (như khởi động lại, lỗi, vấn đề cấu hình)

Số liệu token chính xác đến từ trường sử dụng trong session JSONL

Các script sử dụng:

scripts/session_token_breakdown.py

scripts/session_duplicate_waste_analysis.py

Tệp phân tích được tạo ra:

tmp/session_token_stats_v2.txt

tmp/session_token_stats_v2.json

tmp/session_duplicate_waste.txt

tmp/session_duplicate_waste.json

tmp/session_duplicate_waste.png

Tiêu Thụ Token Thực Tế Đã Đến Đâu?

1） Tập Trung Phiên

Có một phiên có tiêu thụ cao hơn rất nhiều so với các phiên khác:

570587c3-dc42-47e4-9dd4-985c2a50af86：19,204,645 token

Sau đó là một sụp đổ rõ rệt:

ef42abbb-d8a1-48d8-9924-2f869dea6d4a：1,505,038

ea880b13-f97f-4d45-ba8c-a236cf6f2bb5：649,584

2） Tập Trung Hành Vi

Token chủ yếu đến từ:

toolUse：16,372,294

stop：5,171,420

Vấn đề chính nằm ở việc lặp lại chuỗi gọi công cụ, chứ không phải là trò chuyện thông thường.

3） Tập Trung Thời Gian

Mức đỉnh token không phải ngẫu nhiên, mà tập trung vào vài khung thời gian:

2026-03-08 16:00：4,105,105

2026-03-08 09:00：4,036,070

2026-03-08 07:00：2,793,648

Trong Các Tiền Tố Lớn Khổng Lồ Có Gì?

Không phải là nội dung cuộc trò chuyện, mà chủ yếu là sản phẩm trung gian lớn:

Kết quả công cụ khổng lồ

Các dấu vết suy luận / tư duy rất dài

Bản chụp JSON lớn

Danh sách tệp

Dữ liệu trích xuất trình duyệt

Hồ sơ trò chuyện của các Tác nhân con

Trong phiên lớn nhất, số lượng ký tự khoảng:

toolResult:text: 366,469 ký tự

assistant:thinking: 331,494 ký tự

assistant:toolCall: 53,039 ký tự

Sau khi nội dung này được lưu trữ trong ngữ cảnh lịch sử, mỗi lần gọi sau có thể được tải lại thông qua tiền tố bộ nhớ cache.

Ví dụ Cụ thể (từ tệp phiên)

Một khối ngữ cảnh lớn lặp đi lặp lại tại vị trí sau:

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70

Log JSON cổng thông tin lớn (khoảng 3,7 vạn ký tự)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134

Ảnh chụp trình duyệt + Bọc an ninh (khoảng 2,9 vạn ký tự)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219

Danh sách tập tin lớn đầu ra (khoảng 4,1 vạn ký tự)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311

Trạng thái session/status + Cấu trúc gợi ý lớn (khoảng 3 vạn ký tự)

« Lãng phí nội dung lặp đi lặp lại » so với « Gánh nặng tải lại bộ nhớ cache »

Tôi cũng đã đo lường Tỷ lệ nội dung lặp lại trong mỗi lần gọi:

Tỷ lệ lặp lại khoảng: 1,72%

Nó thậm chí tồn tại, nhưng không phải là vấn đề chính.

Vấn đề thực sự là: Tổng khối lượng tiền tố bộ nhớ cache quá lớn

Cấu trúc là: Ngữ cảnh lịch sử lớn, mỗi lần gọi lại, chỉ chồng lên một lượng nhỏ đầu vào mới ở trên

Do đó, việc tối ưu hóa tập trung không phải vào việc làm trùng, mà là vào thiết kế cấu trúc ngữ cảnh.

Tại sao vòng lặp của Agent dễ gặp vấn đề này?

Ba cơ chế chồng lên nhau:

1. Đầu ra của công cụ lớn được ghi vào ngữ cảnh lịch sử

2. Vòng lặp của công cụ tạo ra nhiều lời gọi trong khoảng thời gian ngắn

3. Sự thay đổi tiền tố rất nhỏ → bộ nhớ cache sẽ được đọc lại mỗi lần

Nếu quá trình compacting ngữ cảnh không được kích hoạt một cách ổn định, vấn đề sẽ nhanh chóng trở nên nghiêm trọng.

Chiến lược sửa lỗi quan trọng nhất (theo mức ảnh hưởng)

P0—Không đưa ra đầu ra của công cụ lớn vào ngữ cảnh dài hạn

Đối với đầu ra công cụ cực lớn:

· Giữ lại tóm tắt + đường dẫn tham chiếu / ID

· Ghi gốc payload vào tệp artifact

· Không giữ toàn bộ văn bản gốc trong lịch sử trò chuyện

Ưu tiên hạn chế những loại này:

· JSON lớn

· Danh sách thư mục dài

· Bản chụp toàn bộ trình duyệt

· Biên bản đầy đủ của Agent con

P1—Đảm bảo cơ chế compacting thật sự hiệu quả

Trong dữ liệu này, vấn đề tương thích cấu hình đã xuất hiện nhiều lần: khóa compacting không hợp lệ

Điều này sẽ mở lẻn cơ chế tối ưu một cách im lặng.

Cách làm đúng: chỉ sử dụng cấu hình tương thích với phiên bản

Sau đó xác minh:

openclaw doctor --fix

Và kiểm tra nhật ký khởi động để xác nhận rằng compacting đã được chấp nhận.

P1—Giảm việc lưu trữ văn bản suy luận

Tránh lưu trữ văn bản suy luận dài bị phát lại lặp đi lặp lại

Trong môi trường sản xuất: giữ lại tóm tắt ngắn, thay vì suy luận đầy đủ

P2—改进提示缓存设计

目标不是最大化 cacheRead。目标是，在紧凑、稳定、高价值的前缀上使用缓存。

建议：

·将稳定规则放入系统提示

·不要将不稳定数据放入稳定前缀

·避免在每轮注入大量调试数据

操作性止损方案（如果我明天需要处理）

1. 找出 cacheRead 占比最高的会话
2. 对溢出会话执行 /compact 操作
3. 将工具输出进行截断 + 制作成 artifact
4. 每次修改后重新运行令牌统计

重点关注四个关键绩效指标：

cacheRead / totalTokens

toolUse 平均总数/调用次数

调用次数>=100k 的令牌

最大会话占比

成功的迹象

如果优化生效，您应该看到：

减少明显的 100k+ 令牌调用次数

cacheRead 占比下降

toolUse 调用权重下降

单个会话的主导程度降低

如果这些指标没有变化，则说明您的上下文策略仍然过于宽松。

复现实验命令

python3 scripts/session_token_breakdown.py 'sessions' \
--include-deleted \
--top 20 \
--outlier-threshold 120000 \
--json-out tmp/session_token_stats_v2.json \
> tmp/session_token_stats_v2.txt

python3 scripts/session_duplicate_waste_analysis.py 'sessions' \
--include-deleted \
--top 20 \
--png-out tmp/session_duplicate_waste.png \
--json-out tmp/session_duplicate_waste.json \
> tmp/session_duplicate_waste.txt

Kết luận

Nếu hệ thống Agent của bạn dường như hoạt động bình thường nhưng chi phí lại tiếp tục tăng, bạn có thể kiểm tra vấn đề sau đây: bạn đang trả phí cho việc suy luận mới hay đang tiêu thụ tài nguyên trên quy mô lớn để phục hồi bối cảnh cũ?

Trong trường hợp của tôi, phần lớn chi phí thực tế đến từ việc phục hồi bối cảnh.

Một khi bạn nhận ra vấn đề này, giải pháp trở nên rõ ràng: kiểm soát chặt chẽ dữ liệu vào bối cảnh dài hạn.

[Link bài viết gốc]

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia