Bakit Nabawasan ng 21.5M na Tokens ang Aking Mga Sesyon sa OpenClaw sa Isang Araw (At Ano Talaga ang Nag-fix Nito)
May-akda: MOSHIII
Isinalin ni Peggy, BlockBeats
Editor’s Note: Sa panahon ng mabilis na pagkalat ng mga aplikasyon ng Agent, maraming mga tim ay nakakakita ng isang nakakagulat na pangyayari: ang sistema ay gumagana nang maayos, ngunit ang gastos sa token ay patuloy na tumataas nang hindi napapansin. Sa pamamagitan ng pagsusuri sa isang totoong workload ng OpenClaw, natuklasan na ang sanhi ng pagtaas ng gastos ay karaniwang hindi galing sa input ng user o output ng modelo, kundi sa nakalimutang cached prefix replay. Ang modelo ay paulit-ulit na binabasa ang malaking kasaysayan ng konteksto sa bawat pagtawag, na nagdudulot ng malaking paggamit ng token.
Ang artikulo ay nagpapakita kung paano ang mga malalaking intermediate output tulad ng output ng tool, screenshot ng browser, at JSON log ay sinusulat nang patuloy sa historical context at binabasa muli sa loob ng agent cycle.
Sa pamamagitan ng kaso na ito, ipinresenta ng may-akda ang isang malinaw na estratehiya para sa pag-optimize: mula sa disenyo ng kontekstwal na istruktura, pamamahala sa output ng mga kasangkapan, hanggang sa konpigurasyon ng mekanismo ng compaction. Para sa mga developer na nagbuo ng Agent system, ito ay hindi lamang isang talaan ng teknikal na paglutas kundi isang tunay na paraan upang mag-save ng pera.
Narito ang orihinal na teksto:
Nilikha ko ang isang real-world OpenClaw workload at natuklasan ko ang isang pattern na alam kong makikilala ng maraming Agent user:
Ang paggamit ng token ay tila "aktibo"
Ang reply ay tila normal din
Ngunit ang paggamit ng token ay biglang umabot sa isang malaking pagtaas
Narito ang estruktural na pagkakabuo, pangunahing sanhi, at praktikal na landas para sa pagpapabuti sa pag-aaral na ito.
TL;DR
Ang pinakamalaking driver ng gastos ay hindi ang sobrang haba ng mensahe ng user. Kundi ang malaking dami ng cached prefix na paulit-ulit na inirereplay.
Batay sa session data:
Kabuuang tokens: 21,543,714
cacheRead: 17,105,970 (79.40%)
4,345,264 (20.17%)
output: 92,480 (0.43%)
Sa ibang salita: Ang karamihan sa gastos ng mga pagtawag ay hindi nagpapakita ng bagong user intent, kundi ang paulit-ulit na pagbabasa ng malaking kasaysayan ng konteksto.
Ang sandali ng “Hintayin muna, bakit ganito?”
Akala ko ang mataas na paggamit ng token ay galing sa: sobrang habang user prompt, malaking dami ng output na ginawa, o mahal na pagtawag sa mga tool.
Ngunit ang tunay na pangunahing modelo ay:
Mga sandaang hanggang libo-libong token
cacheRead: Bawat pagtawag ay 170,000 hanggang 180,000 na token
Ibig sabihin, ang modelo ay bumabasa muli at muli ang parehong malaking stable prefix sa bawat round.
Data range
Sinuri ko ang data sa dalawang antas:
1. Mga log sa pagpapatakbo (runtime logs)
2. Mga tala ng sesyon
Dapat ipaalala na:
Ang mga log ng pagpapatakbo ay ginagamit pangunahin upang obserbahan ang mga signal ng pag-uugali (tulad ng restart, error, at mga problema sa konfigurasyon)
Maaaring makakuha ng eksaktong token statistics mula sa usage field ng session JSONL
Ginamit na script:
scripts/session_token_breakdown.py
scripts/session_duplicate_waste_analysis.py
Nabuo na ang analysis file:
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
Saan talaga ginagamit ang token?
1) Pagsasama ng Sesyon
May isang session na ang paggamit ay mas mataas kaysa sa iba:
570587c3-dc42-47e4-9dd4-985c2a50af86: 19,204,645 tokens
At ang malaking pagbaba:
ef42abbb-d8a1-48d8-9924-2f869dea6d4a: 1,505,038
ea880b13-f97f-4d45-ba8c-a236cf6f2bb5: 649,584
2) Paggalaw na nakatuon
Ang token ay pangunahing galing sa:
toolUse: 16,372,294
stop: 5,171,420
Ang problema ay pangunahing dulot ng siklo sa pagtawag ng kasangkapan, hindi sa karaniwang pag-uusap.
3) Panahon na nakapokus
Hindi random ang peak ng token, kundi nakatuon sa ilang mga oras:
2026-03-08 16:00: 4,105,105
2026-03-08 09:00: 4,036,070
2026-03-08 07:00: 2,793,648
Ano ang nasa loob ng malaking cache prefix?
Hindi ito ang nilalaman ng talakayan, kundi pangunahin ang malalaking intermediate product:
Malaking toolResult na bloke
Mga habang pagsusuri / mga trace ng pag-iisip
Malaking JSON snapshot
Listahan ng mga file
Nakuha ng browser ang data
Mga tala ng usapan ng Sub-Agent
Sa pinakamalaking session, ang bilang ng mga karakter ay halos:
366,469 na karakter
assistant:thinking：331,494 characters
53,039 na karakter
Kapag ang mga ito ay mananatili sa kasaysayang konteksto, bawat susunod na pagtawag ay maaaring muliing basahin ang mga ito sa pamamagitan ng cache prefix.
Mga tiyak na halimbawa (mula sa session file)
Maraming beses na lumabas ang malaking bloke ng konteksto sa sumusunod na lokasyon:
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70
Malaking gateway JSON log (tungkol sa 37,000 na karakter)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134
Browser snapshot + secure encapsulation (approx. 29,000 characters)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219
Malaking listahan ng mga file (tungkol sa 41,000 na karakter)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311
session/status snapshot + malaking prompt structure (tungkol sa 30,000 na karakter)
"Repeated content waste" vs. "cache replay burden"
Kasama ko rin ang pagsukat ng proporsyon ng paulit-ulit na nilalaman sa loob ng isang tawag:
Approximate repetition rate: 1.72%
Totoo ito, ngunit hindi ito pangunahing problema.
Ang totoong problema ay ang sobrang laki ng absolute na dami ng cache prefix
Ang istruktura ay: malaking historical context, bawat pagtawag ay babasahin muli, at idinadagdag lamang kaunting bagong input sa itaas
Kaya ang pangunahing pagpapabuti ay hindi ang pagtanggal ng duplikado, kundi ang disenyo ng kontekstwal na istruktura.
Bakit lalong madaling makakasalba ang Agent loop sa problemang ito?
Tatlong mekanismo na nag-ooverlap:
1. Maraming mga tool output ay isinulat sa kasaysayan ng konteksto
2. Ang pag-loop ng mga kasangkapan ay magdudulot ng maraming maliliit na pagtawag sa magkakasunod na oras.
3. Maliit ang pagbabago sa prefix → ang cache ay babasahin muli bawat beses
Kung hindi nag-stabilize ang context compaction, agad na lalaki ang problema.
Mga pinakamahalagang pagsasailalim na pagpapabuti (ayon sa epekto)
P0—Huwag isaksak ang malalaking tool output sa matagalang konteksto
Para sa malalaking output ng tool:
- Panatilihin ang buod + path / ID ng sanggunian
- Isulat ang orihinal na payload sa file artifact
- Huwag panatilihin ang buong orihinal na teksto sa chat history
Prioritize limiting these categories:
- Malaking JSON
- Mahabang lista ng mga kategorya
- Complete browser snapshot
- Kabuuang transcript ng Sub Agent
P1—Siguraduhin na aktibo ang mekanismo ng compaction
Sa data na ito, maraming beses na lumabas ang problema sa compatibility ng configuration: ang compaction key ay hindi wasto
Ito ay papaalis nang tahimik ang mekanismo ng pag-optimize.
Tama para gawin: Gamitin lamang ang kompatibleng konfigurasyon ng bersyon
Sundin ang pag-verify:
openclaw doctor --fix
Suriin ang log ng pagpapagana upang masiguro na tinanggap ang compaction.
P1—Bawasan ang pagpapalabas ng teksto ng reasoning
Iwasan ang paulit-ulit na pag-replay ng mahabang teksto sa pag-iisip
Sa production environment: i-save ang maikling buod, hindi ang buong reasoning
P3—Pagpapabuti ng disenyo ng prompt caching
Ang layunin ay hindi ang pag-maximize ng cacheRead. Ang layunin ay gamitin ang cache sa mga kompakto, matatag, at mataas na halaga na prefix.
Mungkahi:
- Ilagay ang mga patakaran sa pagpapanatili sa system prompt
- Huwag isama ang hindi matatag na data sa matatag na prefix
- Iwasan ang pagpapalabas ng malaking dami ng debug data sa bawat round
Praktikal na plano para sa stop-loss (kung ako ang mag-aayos bukas)
1. Hanapin ang session na may pinakamataas na porsyento ng cacheRead
2. I-executed ang /compact sa runaway session
3. Magdagdag ng truncation + artifactization sa output ng tool
4. Iulit ang pagkalkula ng token pagkatapos ng bawat pagbabago
Mahalagang suriin ang apat na KPI:
cacheRead / totalTokens
toolUse avgTotal/call
Kahit 100k na bilang ng pagtawag
Pinakamalaking porsyento ng session
Successful signal
Kung aktibo ang pag-optimize, dapat mong makita:
Nabawasan nang malaki ang pagtawag sa 100k+ token
Bumaba ang porsyento ng cacheRead
Bumaba ang weight ng toolUse
Nabawasan ang pagiging pangunahin ng isang session
Kung hindi nagbago ang mga indikator na ito, ibig sabihin ay ang iyong kontekstwal na estratehiya ay patuloy na sobrang maluwag.
I-repeat ang command ng eksperimento
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
Wakas
Kung ang iyong Agent system ay tila normal lamang ngunit patuloy na tumataas ang gastos, unang i-check ang sumusunod: binabayaran mo ba ang bagong inference, o nagpapalit ka ng malaking saklaw ng mga lumang konteksto?
Sa aking kaso, ang karamihan sa gastos ay galing sa context replay.
Agad na malinaw ang solusyon kapag naiintindihan mo ito: magkaroon ng mahigpit na kontrol sa mga data na papasok sa mahabang konteksto.