Куда делись мои токены?

Когда начинаешь плотно работать с AI-агентом, кажется, что бОльшая часть токенов улетает на сложные процессы — код написать, сайт разобрать, статью подготовить, браузером поуправлять, в логах покопаться. Вроде логично, задача сложная, модель думает, инструменты дергает, контекст растет.

А потом смотришь внимательнее и понимаешь, что основная дыра вообще не там. Токены уходят не на полезную работу, а на служебную движуху вокруг нее. Cron-задачи, проверки, диагностика, статусные запросы, огромные списки инструментов “на всякий случай” — все это тихо ест бюджет каждый день. Агент еще ничего толком не сделал, а счетчик уже крутится. Примерно как если бы мастер пришел поменять розетку, но сначала выгрузил из газели весь строительный рынок, два перфоратора и почему-то бетономешалку.

Так что в статье решил поделится где именно была утечка, что я подкрутил и как получилось срезать примерно 4,6 млн токенов в день только на фоновых задачах.

Где жулик?

У Mickey, моего AI-агента в OpenClaw, к этому моменту уже была нормальная такая рабочая жизнь. Он помогал с публикациями, браузерной автоматизацией, Elementor, аудитами сайтов, Google Docs, cron-задачами и внутренними проверками. То есть полноценный рабочий помощник, который каждый день что-то делает.

На первый взгляд все было нормально — задачи выполнялись, cron запускался, диагностика что-то проверяла, агент отвечал. То есть по работе агента вопросов не было, но вот расход токенов выглядел подозрительно. Некоторые сессии раздувались до десятков миллионов токенов, а фоновые задачи, которые должны были просто проверять состояние системы, за день съедали объем, похожий на полноценную рабочую задачу.

И вот тут стало понятно — проблема не в том, что агент много работает, а в том, что часть токенов улетает в трубу еще до нормальной работы.

Первая утечка — слишком широкий toolsAllow

Самая жирная «утечка» нашлась в настройке toolsAllow. В OpenClaw агенту доступны разные инструменты — файлы, браузер, WordPress, Elementor, Google Docs, cron, сессии, генерация медиа и куча всего еще. Это удобно, когда агенту реально нужен широкий набор действий, но если такую же “полную тележку” выдать маленькой фоновой задаче, начинается цирк.

В моем случае некоторые cron-задачи получали 200+ инструментов. При этом сама задача могла быть простейшей — прочитать файл, проверить процесс или собрать короткий статус. Но перед запуском ей в контекст прилетал огромный список инструментов, большинство из которых ей вообще не нужны. Цена такого “а вдруг пригодится” — примерно 50 тысяч токенов только на описание инструментов.

То есть задача еще даже не начала работать, а токены уже потрачены. Просто потому что ей выдали все подряд. На всякий случай, конечно. Вдруг healthcheck внезапно захочет сверстать лендинг.

Я прошелся по активным cron-задачам и для каждой посмотрел три вещи:

1. какая модель используется,

2. как часто задача запускается

3. какие инструменты ей реально нужны.

Довольно быстро стало понятно, что часть задач настроена слишком широко. Для простого healthcheck обычно достаточно read и exec. Если задача должна смотреть сессии, можно добавить sessions_list и sessions_history. Но ей точно не нужны инструменты Elementor, WordPress, генерация изображений, работа с формами, виджетами и всем этим набором.

После этого я урезал toolsAllow у проблемных cron-задач. Там, где раньше было 200+ инструментов, осталось 2–5. И это сразу убрало большой кусок лишнего контекста.

То есть тут вывод довольно банальный, но все же — если у фоновой задачи есть доступ ко всем инструментам агента, скорее всего, она настроена слишком жирно. Для cron лучше начинать с минимума и добавлять только то, что реально нужно.

Вторая утечка — cron слишком часто просыпался

Следующая проблема была проще, но тоже неприятная. Некоторые фоновые задачи запускались слишком часто. Healthcheck просыпался каждые 10 минут, watchdog — каждые 15, kill-runaway проверял сессии каждые 30 минут.

Вроде бы, что плохого в частых проверках? Система под контролем, все бодрствуют, никто не спит на посту. Но если каждая такая проверка поднимает отдельную LLM-сессию, это уже не забота, а подписка на регулярное сжигание токенов.

Так что, я снизил частоту запусков — dashboard-label-watchdog перевел с 15 минут на 30, shell-healthchecks — с 10 минут на 30, kill-runaway-sessions — с 30 минут на 60. Ничего критичного после этого не произошло. Система не стала менее управляемой, просто агент перестал каждые несколько минут перепроверять еще раз то же самое.

Так что далеко не каждая проверка должна выполняться максимально часто. Если задача не критична по секундам, ее можно запускать реже. Особенно если внутри используется LLM, а не обычный легкий shell-скрипт.

Статусные запросы тоже не бесплатные

Отдельно всплыла история со статусными запросами. Например, спрашиваешь “что с токенами?” или “что с задачей?”. Ожидаешь короткий ответ в духе “все нормально” или “вот где проблема”. А внутри агент может начать живой анализ десятков сессий, логов и процессов.

В одном случае такой разбор стоил около 1,35 млн токенов. То есть ты просто спросил “как дела?”, а система поднимает кучу процессов для ответа на простой вопрос.

Поэтому самым адекватным вариантом было готовить отчет заранее, а не каждый раз заново разбирать десятки сессий. Для этого появился pre-generated отчет по токенам — его собирает cron-задача на дешевой модели, а основная сессия потом просто читает готовый markdown-файл.

После перехода на готовый отчет стоимость ответа стала около 2 тысяч токенов. Разница примерно в 675 раз. И что приятно, пользователь от этого ничего не теряет. Ответ все равно есть, просто система перестает каждый раз изображать следственный комитет.

Браузер и VNC я вынес из основной сессии

Еще один источник лишнего расхода — браузерная диагностика, VNC и проверки процессов. Когда агент смотрит страницу, читает DOM, делает snapshot, проверяет процессы и логи, контекст быстро раздувается. Если все это делать в основной сессии, технический хвост остается в истории и мешает дальше.

Бывали случаи, когда такая диагностика добавляла десятки миллионов токенов. После этого стало понятно, что основная сессия не должна тащить на себе весь технический мусор. Для таких задач лучше запускать изолированного subagent на дешевой модели: дать ему узкую задачу, минимальный набор инструментов и попросить вернуть короткий вывод.

Теперь VNC, браузерные проверки и диагностика процессов не выполняются в основной сессии. Subagent проверяет проблему и возвращает нормальный результат — что проверено, где проблема, что делать дальше. Основная сессия получает не весь лог браузера, а короткую выжимку, с которой уже можно работать.

Какие инструменты пригодились

Основная работа шла вокруг OpenClaw и его служебных механизмов. Для cron использовался встроенный scheduler OpenClaw. Через него я проверял задачи, частоту запуска, payload, модель, toolsAllow, timeout и lightContext.

Для анализа расхода использовался scripts/token-usage-watchdog.py. Он показывает, какие сессии и фоновые задачи потребляют больше всего. Позже вокруг него появился status-cache, чтобы не запускать тяжелую проверку повторно без необходимости.

Для регулярных отчетов использовались scripts/generate-token-report.py, scripts/run-token-report.sh и cron-задача token-usage-report. Они нужны, чтобы готовить отчет по токенам заранее, а не каждый раз собирать его вручную через основную сессию. Для зависших и слишком разросшихся сессий использовался scripts/kill-runaway-sessions.py, а для shell-проверок — scripts/run-shell-healthchecks.sh.

Последний пункт важный. Если задачу можно решить обычным shell-скриптом без LLM, лучше так и делать. Не надо звать модель туда, где достаточно простого скрипта.

Отдельно появился scripts/safe-write.sh. Он не про экономию токенов напрямую, но помог убрать повторные правки. Раньше при записи русскоязычных файлов могли появляться битые символы U+FFFD, после чего приходилось искать их, исправлять и снова проверять. Скрипт пишет UTF-8 безопасно и сразу блокирует битый текст.

По моделям правило стало простым — для cron, heartbeat и рутины используется дешевая модель ollama-cloud-gemma4-31b, а для сложного анализа, архитектуры и кода — сильная модель. Не наоборот. Потому что гонять дорогую модель на регулярный healthcheck — неразумно.

Что получилось в цифрах

После оптимизации трех основных cron-задач расход снизился примерно на 4,6 млн токенов в день. Больше всего дала задача dashboard-label-watchdog — после снижения частоты и урезания toolsAllow экономия составила примерно 3,7 млн токенов в день.

shell-healthchecks дал еще около 565 тысяч токенов в день, а kill-runaway-sessions — примерно 360 тысяч токенов в день. В сумме это около 84% фонового потребления. Отдельно удалось уменьшить стоимость запроса по токенам с 1,35 млн до примерно 2 тысяч токенов за счет заранее подготовленных отчетов.

И что важно, это не была экономия в стиле “давайте все выключим и будем делать вид, что оптимизировали”. Важные проверки остались, сложные задачи остались, качество работы не просело. Я просто убрал лишний расход вокруг нормальной работы.

Что я из этого вынес

Главный вывод — AI-агента нужно оптимизировать не только на уровне модели, но и на уровне всей обвязки вокруг нее. Когда видишь большой расход токенов, первая мысль обычно «наверное, модель слишком дорогая или агент делает слишком много сложных задач», но в моем случае основная проблема была не в этом.

Самые большие потери оказались в служебных процессах — слишком широкий список инструментов, слишком частые cron-задачи, повторные проверки одного и того же, диагностика, которая тащит в основную сессию кучу технических данных. То есть токены уходили не на полезную работу, а на плохо настроенную инфраструктуру вокруг агента.

Это важный момент для всех, кто внедряет AI-агентов в работу:

Недостаточно просто подключить модель и дать ей инструменты. Нужно еще смотреть, как именно она запускается, что получает в контекст, какие задачи выполняет фоном и не делает ли одну и ту же проверку по кругу. Иначе агент будет жечь ресурсы там, где можно было обойтись меньшими потерями.

А вы как боритесь с оптимизацией? Может посоветуете что-нибудь еще, буду благодарен