After the author dissected an OpenClaw workload, it was found that 79% of token consumption came from cached prefix replay rather than user input or model output. Three major contextual optimization strategies were proposed to effectively reduce the operational costs of AI Agents. This article is based on a piece by MOSHIII titled (Why My OpenClaw Sessions Burned 21.5M Tokens in a Day (And What Actually Fixed It)), edited and translated by Dongqu. (Background: MEXC ranks among the Top 3 CEXs globally, deepening its layout in the spot and commodity markets) (Background Supplement: Bear Market Relies on Stablecoins for Yield: Interest Rate Comparison OSL 18%, MEXC 15%, Binance 8%...) I analyzed a real OpenClaw workload and identified a pattern that I believe many Agent users would recognize: token usage seems very "active," responses appear normal, yet token consumption suddenly skyrockets. Below is the structural breakdown of this analysis, root causes, and practical repair paths. The main cost driver: cached prefix replay The biggest cost driver is not overly long user messages but rather the massive cached prefixes being replayed repeatedly. From the session data: total tokens: 21,543,714 cacheRead: 17,105,970 (79.40%) input: 4,345,264 (20.17%) output: 92,480 (0.43%) In other words, most of the cost calls are not in handling new user intentions but in repeatedly reading vast historical contexts. I originally thought the high token usage came from: very long user prompts, a large amount of output generation, or expensive tool calls. However, the true dominating pattern is: input: hundreds to thousands of tokens cacheRead: 170,000 to 180,000 tokens per call. This means the model is repeatedly reading the same massive stable prefix every round. Session Data Breakdown I analyzed data on two levels: 1. Runtime logs 2. Session transcripts It should be noted that: Runtime logs are primarily used to observe behavioral signals (such as restarts, errors, configuration issues) Precise token statistics come from the usage field in session JSONL The scripts used: scripts/session_token_breakdown.py scripts/session_duplicate_waste_analysis.py Generated analysis files: 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 There is one session with consumption far exceeding others: 570587c3-dc42-47e4-9dd4-985c2a50af86: 19,204,645 tokens Then there is a clear cliff-like drop: ef42abbb-d8a1-48d8-9924-2f869dea6d4a: 1,505,038 ea880b13-f97f-4d45-ba8c-a236cf6f2bb5: 649,584 tokens Mainly from: toolUse: 16,372,294 stop: 5,171,420 This indicates that the problem primarily lies in the tool call loop rather than regular chat. Where do the token peaks come from? Token peaks are not random but concentrated in a few short time periods: 2026-03-08 16:00: 4,105,105 2026-03-08 09:00: 4,036,070 2026-03-08 07:00: 2,793,648 It is not the content of the conversation but mainly large intermediate products: massive toolResult data blocks long reasoning/thinking traces large JSON snapshots file lists browser scrape data dialogue records of sub-Agents In the largest session, the character count is approximately: toolResult:text: 366,469 characters assistant:thinking: 331,494 characters assistant:toolCall: 53,039 characters Once this content is retained in the historical context, subsequent calls may read them through cached prefixes. Huge context blocks appeared repeatedly in the following locations: sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70 large gateway JSON log (about 37,000 characters) sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134 browser snapshots + secure packaging (about 29,000 characters) sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219 massive file list output (about 41,000 characters) sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311 session/status state snapshot + large prompt structure (about 30,000 characters) I also measured the proportion of repeated content within a single call: the duplication ratio is about: 1.72%. It does exist but is not the main issue. The real problem is: the absolute volume of cached prefixes is too large. The structure consists of: huge historical context, re-reading with each call, with only a small amount of new input added on top. Therefore, the optimization focus is not on deduplication but on the design of the contextual structure. The Triple Mechanism of Context Expansion Three mechanisms overlap: 1. A large amount of tool output is written into historical context 2. Tool loops generate a large number of short interval calls 3. Minimal prefix changes → cache is re-read every time If context compaction is not consistently triggered, the problem will quickly amplify. Practical Optimization Strategies For extremely large tool outputs: · Keep summaries ...