Чому мої сесії OpenClaw спалили 21,5 мільйона токенів за день (і що насправді це виправило)
Автор оригіналу: MOSHIII
Оригінальний текст: Peggy, BlockBeats
Редакційна примітка: У час швидкого поширення застосунків Agent багато команд помічають на перший погляд дивне явище: система працює безперебійно, але витрати на токени непомітно постійно зростають. У цій статті, на основі розбору реального завантаження OpenClaw, виявлено, що причина стрімкого зростання витрат часто полягає не у вхідних даних користувача чи виході моделі, а у зневаженому повторному відтворенні кешованого контексту (cached prefix replay). Модель у кожному виклику повторно читає величезний історичний контекст, що призводить до колосального споживання токенів.
Стаття на основі конкретних даних сесії демонструє, як великі проміжні результати — такі як вихідні дані інструменту, знімки екрану браузера та JSON-журнали — постійно записуються в історичний контекст і повторно читаються в циклі агента.
На основі цього випадку автор запропонував чітку стратегію оптимізації: від проектування структури контексту до управління виводом інструментів та налаштування механізму compaction. Для розробників, які створюють системи Agent, це не просто технічний журнал виправлення помилок, а й справжній спосіб зекономити гроші.
Нижче наведено оригінал:
Я проаналізував реальне завантаження OpenClaw і виявив шаблон, який, я вважаю, впізнають багато користувачів Agent:
Використання токену виглядає дуже «активним»
Відповідь також виглядає нормально
Але споживання токенів раптово різко зросло
Нижче наведено структурний розбір, основні причини та практичні шляхи виправлення цієї аналізу.
Коротко
Найбільшим фактором витрат є не надто довгі повідомлення користувачів, а величезна кількість кешованих префіксів, які повторно відтворюються.
З даних сесії:
Загальна кількість токенів: 21,543,714
cacheRead: 17 105 970 (79,40%)
4 345 264 (20,17%)
вивід: 92 480 (0,43%)
Іншими словами: вартість більшості викликів насправді не пов’язана з обробкою нових намірів користувача, а з повторним читанням великих історичних контекстів.
Момент «Зараз, як це може бути?»
Я спочатку вважав, що високе використання токенів походить із: дуже довгих запитів користувача, великої кількості згенерованих вихідних даних або дорогих викликів інструментів.
Але справжнім домінуючим шаблоном є:
Сотні до тисяч токенів
cacheRead: кожен виклик — від 170 000 до 180 000 токенів
Тобто модель на кожному етапі повторно читає один і той самий величезний стабільний префікс.
Діапазон даних
Я проаналізував дані на двох рівнях:
1. Журнали виконання (runtime logs)
2. Записи сесій (session transcripts)
Варто зазначити:
Журнал виконання використовується переважно для спостереження за поведінковими сигналами (наприклад, перезавантаження, помилки, проблеми з конфігурацією)
Точна статистика токенів отримана з поля usage у файлі JSONL сесії
Використовуваний сценарій:
scripts/session_token_breakdown.py
scripts/session_duplicate_waste_analysis.py
Згенерований аналітичний файл:
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
Де фактично витрачається токен?
1) Зосередження сесії
Один сеанс споживає значно більше, ніж інші:
570587c3-dc42-47e4-9dd4-985c2a50af86: 19 204 645 токенів
А потім — очевидний стрімкий спад:
ef42abbb-d8a1-48d8-9924-2f869dea6d4a: 1 505 038
ea880b13-f97f-4d45-ba8c-a236cf6f2bb5: 649 584
2) Концентрація поведінки
Токени походять з:
toolUse：16,372,294
стоп: 5 171 420
Проблема полягає в циклі викликів інструментів, а не у звичайному чаті.
3) Концентрація часу
Піки токенів не є випадковими, а зосереджені на кількох часових інтервалах:
2026-03-08 16:00: 4 105 105
2026-03-08 09:00: 4 036 070
2026-03-08 07:00: 2 793 648
Що саме знаходиться у величезному префіксі кешу?
Не зміст діалогу, а головним чином великий проміжний продукт:
Великий блок даних toolResult
Довгі ланцюги міркувань / міркувань
Великий JSON-зйомка
Список файлів
Збір даних браузером
Історія діалогу під-Agenta
У найбільшій сесії кількість символів становить приблизно:
366 469 символів
assistant:thinking:331,494 символи
53 039 символів
Після збереження цих даних у історичному контексті, кожен наступний виклик може знову читати їх через префікс cache.
Конкретні приклади (з файлу сесії)
У цьому місці були повторювані величезні блоки контексту:
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70
Великий JSON-лог шлюзу (приблизно 37 000 символів)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134
Знімок браузера + безпечне обгортання (приблизно 29 000 символів)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219
Великий список файлів (приблизно 41 000 символів)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311
session/status Знімок стану + велика структура prompt (приблизно 30 000 символів)
«Витрати на повторювані дані» проти «Навантаження від відтворення кешу»
Я також виміряв частку повторюваних даних всередині одного виклику:
Повторний відсоток приблизно: 1,72%
Це дійсно існує, але не є основною проблемою.
Справжнє питання полягає в тому, що абсолютний обсяг префікса кешу надто великий
Структура: великий історичний контекст, перезавантаження на кожен виклик, зверху додається лише невеликий обсяг нових даних
Тому основна увага не на видаленні дублікатів, а на проектуванні структури контексту.
Чому цикл Agent особливо схильний до цієї проблеми?
Три механізми накладаються один на одного:
1. Велика кількість інструментів виводиться в історичний контекст
2. Цикл інструментів створює велику кількість викликів з короткими інтервалами
3. Префікс змінюється незначно → кеш кожен раз зчитується заново
Якщо компактизація контексту не тригериться стабільно, проблема швидко посилюється.
Найважливіші стратегії виправлення (за ступенем впливу)
P0 — Не заповнюйте довгостроковий контекст великими виводами інструментів
Для виводу надвеликого інструменту:
- Зберегти короткий зміст + шлях / ID цитування
- Оригінальний payload записано у файл-артефакт
- Не зберігайте повний оригінальний текст у історії чату
Пріоритетні обмеження для цих категорій:
- Великий JSON
- Довгий список каталогів
- Повний знімок браузера
- Повний транскрипт під-Agent
P1 — Переконайтеся, що механізм компактизації дійсно працює
У цих даних неодноразово з’являються проблеми сумісності конфігурації: недійсний ключ компактизації
Це тихо вимкне механізм оптимізації.
Правильний підхід: використовуйте лише конфігурації, сумісні з версією
Потім перевірте:
openclaw doctor --fix
Перевірте журнал запуску, щоб переконатися, що компактизація прийнята.
P1 — Зменшення тривалості зберігання тексту міркувань
Уникайте повторного відтворення довгих текстів міркувань
У виробничому середовищі: зберігайте короткі скорочення, а не повні міркування
P3 — Вдосконалення дизайну кешування запитів
Мета — не максимізувати cacheRead. Мета — використовувати кеш на стислих, стабільних і високодоходних префіксах.
Рекомендація:
- Вставте стабільні правила до system prompt
- Не додавайте нестабільні дані до стабільного префікса
- Уникайте введення великої кількості даних для налагодження за одну сесію
Практичний план стоп-втрат (якби мені це треба було обробити завтра)
1. Знайдіть сесію з найвищим відсотком cacheRead
2. Виконайте /compact для runaway session
3. Додайте обрізання + артефакти до виводу інструменту
4. Після кожного редагування повторно запустіть статистику токенів
Основні показники для відстеження:
cacheRead / totalTokens
toolUse avgTotal/call
Кількість викликів >=100k токенів
Максимальний відсоток сесії
Сигнал успіху
Якщо оптимізація вступить в дію, ви повинні побачити:
Кількість викликів токенів більше 100 000 значно зменшилася
Відсоток cacheRead знизився
Зниження ваги виклику toolUse
Зменшення домінування окремого сеансу
Якщо ці показники не змінилися, це означає, що ваша стратегія контексту все ще надто вільна.
Команди для відтворення експерименту
python3 scripts/session_token_breakdown.py 'sessions' \
--include-deleted \
--топ 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 \
--топ 20 \
--png-out tmp/session_duplicate_waste.png \
--json-out tmp/session_duplicate_waste.json \
> tmp/session_duplicate_waste.txt
Заключення
Якщо ваша система Agent виглядає нормально, а витрати постійно зростають, спочатку перевірте це питання: чи ви платите за нові висновки, чи за масове відтворення старих контекстів?
У моєму випадку більшість витрат насправді походить із повторного відтворення контексту.
Як тільки ви це усвідомите, рішення стане очевидним: строго контролюйте дані, що надходять до довготривалого контексту.