Вступить в чат

AI и агенты

Чеклист экономии токенов для AI-агентных систем

Почему агент сжигает лимит за полдня: где прячутся невидимые токены — в постоянном контексте, описаниях инструментов и памяти — и что с этим делать.

У многих первое знакомство с ИИ-агентами проходит по одному сценарию.

Сначала восторг: агент сам читает файлы, ходит в браузер, вызывает инструменты, пишет код, помнит контекст, отвечает в Telegram или Discord и вообще начинает напоминать маленького Джарвиса.

Потом приходит реальность: лимит закончился за полдня, API-биллинг неприятно подрос, Claude Code внезапно стал «дорогим сотрудником», а OpenClaw или Hermes вроде бы ответил всего парой строк — но где-то внутри сжёг гору токенов.

Обычно расход собирается незаметно:

  • длинный AGENTS.md, CLAUDE.md или SOUL.md грузится в каждый запуск;
  • история сессии растёт и повторно отправляется модели;
  • десятки tools и MCP-серверов приносят с собой описания и JSON-схемы;
  • результаты инструментов возвращаются в контекст целиком;
  • cron будит дорогую модель ради одной строки;
  • включённый reasoning генерирует тысячи невидимых токенов;
  • субагенты получают собственные окна контекста;
  • браузер, shell и поиск запускаются «на всякий случай».

Снаружи это выглядит как обычный короткий ответ. Внутри — маленькая фабрика, где модель несколько раз думает, вызывает инструменты, читает результаты, снова думает и тащит за собой всё больше контекста.

Эта статья — не про «попросите отвечать короче». Это слабая оптимизация.

Она про другое: как устроить агента так, чтобы он делал ту же работу, но не таскал на каждый шаг половину вашей цифровой жизни.

TL;DR

Если коротко:

  1. Вы платите не за сообщение, а за весь агентный цикл.
  2. Самый дорогой токен — тот, который повторяется на каждом шаге.
  3. Reasoning может быть невидимым, но он всё равно занимает место и обычно тарифицируется как output.
  4. Tools стоят не только в момент вызова: их описания, схемы и результаты тоже попадают в контекст.
  5. Большой SOUL.md или CLAUDE.md — это постоянный налог.
  6. Cron-задачи не должны будить флагманскую модель, если результат детерминирован.
  7. Самая сильная экономия начинается не с выбора дешёвой модели, а с вопроса: «Что модели вообще не надо видеть?»

Сначала главное: вы платите не за сообщение

Обычный чат работает примерно так:

пользователь → модель → ответ

Агент работает иначе:

пользователь
  → модель думает
  → вызывает инструмент
  → получает результат
  → снова думает
  → вызывает следующий инструмент
  → снова получает результат
  → пишет ответ

И это только простой случай.

В реальной агентной системе сверху добавляются память, системные инструкции, bootstrap-файлы, список инструментов, schema каждого tool, история диалога, результаты предыдущих вызовов, вложения, логи и иногда субагенты.

Грубую стоимость одного агентного запуска можно представить так:

расход ≈ постоянный контекст
       + история сессии
       + входные данные
       + описания и схемы инструментов
       + результаты инструментов
       + видимый ответ
       + скрытый reasoning
       × число агентных шагов

Последний множитель — самый неприятный.

Если вы добавили 10 000 токенов в постоянную инструкцию, это не обязательно 10 000 токенов на задачу. Если агент сделал 8–10 шагов, эти 10 000 токенов могут обрабатываться снова и снова. На практике один «безобидный» большой файл в базовом контексте превращается в постоянную абонентскую плату за каждое действие агента.

Официальные документы OpenAI прямо разделяют input, output, cached input и стоимость tools; встроенные tools также могут добавлять плату за вызовы и контент, который подаётся модели вместе с запросом.

Невидимые токены: почему короткий ответ может быть дорогим

Самая обманчивая часть агентной экономики — reasoning.

Пользователь видит:

Готово, я обновил конфиг.

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

В документации OpenAI reasoning tokens описаны как отдельные токены, которые модель использует для «думания»; они не видны через API, но занимают место в контекстном окне и тарифицируются как output tokens. OpenAI также показывает пример, где из 1186 output-токенов 1024 — reasoning tokens.

У Anthropic похожая логика для extended thinking: thinking tokens тарифицируются как output, а видимое количество токенов в ответе может не совпадать с billed output; в документации прямо сказано, что пользователь платит за полный thinking process, а не только за видимую сводку.

Отсюда практический вывод:

«Ответ короткий» не значит «запуск дешёвый».

Для простых задач reasoning должен быть низким или выключенным, если платформа это позволяет. Для сложной архитектуры, кода, планирования миграции или опасных действий — наоборот, reasoning может окупаться. Но включать максимум thinking для приветствий, напоминаний и пересылки уведомлений — это как вызывать senior architect, чтобы он подписал открытку.

Где на самом деле прячутся токены

1. Постоянный контекст

Это AGENTS.md, CLAUDE.md, SOUL.md, USER.md, TOOLS.md, memory-файлы, инструкции проекта, политики, правила общения и всё, что агент читает при старте.

Проблема не в том, что эти файлы существуют. Проблема в том, что туда со временем начинают складывать всё подряд:

  • биографию пользователя;
  • историю проекта;
  • старые решения;
  • стиль общения;
  • все edge cases;
  • инструкции для редких сценариев;
  • примеры;
  • заметки;
  • запреты;
  • исключения из запретов;
  • исключения из исключений.

Через месяц агент каждый раз получает энциклопедию вместо короткой инструкции.

Хорошее правило:

В постоянном контексте должно лежать только то,
что нужно почти в каждом запуске.

Всё остальное должно быть загружаемым по требованию.

2. Tools и MCP-серверы

MCP — это стандарт подключения AI-приложений к внешним системам: файлам, базам, календарям, поиску, специализированным prompts и workflows. В официальном описании MCP называется «USB-C портом для AI-приложений».

Звучит прекрасно. Но у каждого инструмента есть цена.

Чтобы модель могла пользоваться tool, она должна знать:

  • что это за инструмент;
  • когда его вызывать;
  • какие параметры он принимает;
  • какой формат результата вернёт;
  • какие ограничения есть у вызова.

В function calling это часто выражено через JSON schema. OpenAI прямо пишет, что function tools определяются схемой, а при большом количестве функций или крупных схемах имеет смысл использовать tool search, чтобы редко используемые tools подгружались только при необходимости.

То есть проблема не только в самом вызове инструмента. Проблема в том, что вы заранее показываете модели слишком большой меню-каталог.

Если задаче нужно только прочитать память, не надо одновременно давать ей Gmail, Calendar, browser, shell, Notion, GitHub, Jira, Linear, Figma и три поисковика.

3. Результаты инструментов

Ещё хуже, когда tool возвращает слишком много.

Плохой вариант:

Прочитай весь лог на 80 000 строк и найди ошибку.

Хороший вариант:

Скрипт заранее отфильтровал ERROR/WARN,
оставил 100 строк вокруг первой ошибки,
и только это передал модели.

Claude Code в своих рекомендациях по снижению расходов прямо предлагает выносить предварительную обработку в hooks и skills: например, не давать Claude читать лог на 10 000 строк, а сначала прогнать grep по ошибкам и вернуть сотни токенов вместо десятков тысяч.

Это один из самых практичных принципов:

Модель должна получать не сырые данные, а уже подготовленный минимум, достаточный для решения.

4. История сессии

Длинная сессия — это удобно психологически: «агент всё помнит».

Но технически длинная сессия — это растущий хвост, который начинает стоить денег на каждом новом шаге. В какой-то момент вы платите не за текущую задачу, а за месячную историю разговора, которая давно не нужна.

Claude Code прямо советует очищать контекст при смене задачи: stale context тратит токены на каждое следующее сообщение.

Знания должны жить в базе знаний, документах, memory и retrieval. Сессия должна жить ровно столько, сколько нужно для текущей задачи.

5. Субагенты и мультиагентность

Мультиагентность звучит круто: один агент пишет код, другой ревьюит, третий ищет факты, четвёртый делает пост.

Но каждый агент — это отдельный контекст.

Anthropic в документации по Claude Code прямо предупреждает: agent teams запускают несколько экземпляров Claude Code, каждый со своим context window, а token usage масштабируется с числом активных «тиммейтов».

Иными словами:

3 агента ≠ один агент, только умнее.
3 агента = 3 контекстных окна + координация + передача результатов.

Мультиагентность окупается, когда задачи действительно независимы или требуют разных специализаций. Если вы делегируете три пункта одного списка трём агентам просто потому, что можете, вы часто покупаете хаос за токены.

6. Cron и фоновые задачи

Cron — тихий убийца бюджета.

Пользователь спит, а агент каждые 15 минут просыпается, грузит память, читает tools, вызывает флагманскую модель, проверяет что-то, видит, что ничего не изменилось, и засыпает.

Через неделю выясняется, что самый дорогой пользователь вашего агента — не вы, а расписание.

Правильная архитектура фоновой задачи выглядит так:

cron → дешёвый pre-check → есть изменения? → да/нет

Если изменений нет, LLM вообще не нужна.

Самая выгодная строка в системе автоматики:

{ "wakeAgent": false }

Главный принцип: самый дешёвый токен — тот, который не отправили

Можно поставить модель дешевле.

Можно снизить reasoning.

Можно включить caching.

Можно сокращать ответы.

Но самая сильная оптимизация почти всегда звучит проще:

Не отправляйте модели то, что ей не нужно для текущего шага.

Это касается всего:

  • инструкций;
  • памяти;
  • tools;
  • схем;
  • логов;
  • HTML;
  • истории диалога;
  • вложений;
  • результатов поиска;
  • промежуточных артефактов.

Если данные можно отфильтровать кодом — фильтруйте кодом.

Если задачу можно решить шаблоном — решайте шаблоном.

Если большой документ нужен редко — не держите его в базовом контексте.

Если skill нужен один раз в месяц — пусть он лежит в references, а не в AGENTS.md.

Чеклист экономии токенов: 14 правок в порядке отдачи

1. Сначала измерьте, потом режьте

Не начинайте с «сократим промпт». Сначала найдите, что реально дорого.

Минимальный baseline — 7 дней.

Смотрите отдельно:

  • интерактивные сессии;
  • cron и фоновые задачи;
  • tool calls;
  • input tokens;
  • output tokens;
  • reasoning/thinking tokens;
  • cache hit rate;
  • количество шагов на задачу;
  • стоимость завершённой задачи, а не одного запроса.

Полезная таблица:

МетрикаЧто показываетInput tokens / запускРаздутый контекст, история, tool outputOutput + reasoning / запускСлишком большой thinking или многословные ответыTool calls / задачуЛишний поиск, плохая маршрутизация, неудачные toolsЗапросов / задачуЗацикливание, плохой план, повторные попыткиTokens / cron jobАвтоматизацию, которую пора заменить скриптомCache hit rateНасколько стабилен повторяющийся префиксБез baseline легко неделю героически сокращать SOUL.md, а потом выяснить, что 70% расхода давал ночной мониторинг.

2. Не используйте флагман как универсальный процессор

Флагманская модель нужна для:

  • сложной архитектуры;
  • неоднозначных решений;
  • тяжёлого кода;
  • синтеза из разных источников;
  • рискованных действий;
  • задач, где ошибка дорогая.

Но ей не обязательно:

  • классифицировать письма по трём категориям;
  • вытаскивать дату из текста;
  • форматировать JSON;
  • писать однотипные напоминания;
  • проверять, появился ли новый файл;
  • пересылать уведомление.

Дешёвая модель тоже не всегда лучше. Если она ошибается и запускает пять дополнительных tool calls, один хороший ответ флагмана мог быть дешевле.

Оптимизируйте не цену токена, а стоимость завершённой задачи.

3. Снизьте reasoning по умолчанию

Базовое правило:

low/medium — по умолчанию
high — только по явной причине

Для бытовых задач, коротких уведомлений, классификации, простых summaries и шаблонных ответов высокий thinking обычно не нужен.

Для сложной задачи сделайте eval:

  • один и тот же набор задач;
  • разные уровни reasoning;
  • сравнить качество;
  • сравнить ошибки;
  • сравнить токены;
  • сравнить время.

Если high даёт +2% качества и +300% стоимости, это плохая сделка.

4. Уберите LLM из детерминированных задач

Если выход заранее известен, модель не нужна.

Плохой вариант:

cron → загрузить агента → загрузить память → загрузить tools
     → попросить написать «Пора пить воду»

Хороший вариант:

cron → script-only → отправить готовую строку

LLM нужна там, где есть неопределённость:

  • понять смысл;
  • выбрать действие;
  • синтезировать информацию;
  • объяснить;
  • принять решение;
  • адаптироваться к контексту.

Если задача — просто дата, таймер, формат, health check или фиксированная строка, это работа обычного кода.

5. Сократите постоянный контекст

Проверьте все файлы, которые грузятся в каждый запуск:

  • AGENTS.md;
  • CLAUDE.md;
  • SOUL.md;
  • USER.md;
  • TOOLS.md;
  • MEMORY.md;
  • bootstrap-инструкции;
  • глобальные правила проекта.

Задайте к каждому блоку один вопрос:

Это нужно почти в каждом запуске?

Если нет — вынести в отдельный reference.

Хорошая структура:

AGENTS.md
  короткие глобальные правила
  карта документов
  когда что читать

references/
  security.md
  sales-process.md
  content-style.md
  deployment-guide.md
  rare-edge-cases.md

AGENTS.md должен быть не энциклопедией, а навигатором.

6. Переведите skills на progressive disclosure

Progressive disclosure — это когда агент сначала видит короткое описание skill, а подробности читает только при необходимости.

Плохой skill:

SKILL.md на 30 страниц,
где сразу лежат все сценарии, примеры, исключения и шаблоны.

Хороший skill:

skill/
├── SKILL.md              # короткий роутер
├── references/
│   ├── interview.md      # только для интервью
│   ├── landing.md        # только для лендингов
│   ├── bugfix.md         # только для багфиксов
│   └── full-protocol.md  # редкий полный режим
└── scripts/
    └── preprocess.py

Claude Code в официальной документации прямо рекомендует переносить специализированные инструкции из CLAUDE.md в skills: CLAUDE.md грузится на старте, а skills загружаются по требованию.

7. Подключайте только нужные инструменты

Не надо давать агенту весь toolbox на каждую задачу.

Для задачи «найди в памяти, что мы решили по pricing» не нужны:

  • Gmail;
  • browser;
  • shell;
  • Calendar;
  • GitHub;
  • Notion;
  • Figma;
  • Sentry;
  • Stripe.

Нужны memory/retrieval и, возможно, один файловый инструмент.

Для каждой категории задач заведите минимальный toolset:

memory-only
research
coding
calendar
email-draft
browser-heavy
admin

Чем меньше tools в рантайме, тем меньше schema-шум и тем меньше вероятность, что агент выберет не тот молоток.

8. Ограничьте результаты инструментов до входа в модель

Не давайте модели всё.

Давайте ей то, что уже отфильтровано.

Примеры:

Вместо: весь HTML страницы
Лучше: title, h1, main text, links, meta, relevant snippets

Вместо: весь лог
Лучше: первые ошибки + 50 строк вокруг + последние 100 строк

Вместо: весь репозиторий
Лучше: tree + 3 релевантных файла

Вместо: все письма
Лучше: 20 новых писем с sender, subject, date, snippet

Вместо: полный JSON API
Лучше: выбранные поля

Это экономит дважды:

  1. меньше input на текущем шаге;
  2. меньше мусора в дальнейшей истории сессии.

9. Ограничьте длину агентного цикла

Поставьте лимиты:

  • max_turns;
  • max_tool_calls;
  • лимит повторных попыток;
  • stop при одинаковой ошибке;
  • stop при одинаковом tool call;
  • обязательный новый план после 2–3 неудач.

Агент без ограничений похож на стажёра, которому дали корпоративную карту и сказали: «Разберись».

Он разберётся. Но счёт может удивить.

10. Управляйте жизненным циклом сессии

Открывайте новую сессию при смене:

  • проекта;
  • репозитория;
  • темы;
  • клиента;
  • типа задачи.

Используйте compaction, но не как мусорный пресс, который превращает всё в кашу.

OpenAI в документации по compaction описывает подход, где длинное окно заменяется компактным состоянием, которое несёт ключевой prior state and reasoning в меньшем числе токенов.

Но compaction требует контроля качества. После сжатия проверьте, что сохранились:

  • запреты;
  • решения;
  • незавершённые действия;
  • важные constraints;
  • текущий план;
  • источники правды.

Плохая compaction экономит токены и создаёт дорогие ошибки.

11. Разделите память по назначению

Не вся память одинаковая.

Есть четыре слоя:

  1. Core memory — что агент должен знать всегда.
  2. Retrieval memory — что нужно найти по текущей теме.
  3. Session memory — что важно в рамках текущей задачи.
  4. Log memory — журнал событий, который нужен редко.

Плохая архитектура памяти:

Всё лежит в одном MEMORY.md,
который грузится каждый раз.

Хорошая архитектура:

core.md          # коротко, только постоянное
projects/*.md    # по проектам
people/*.md      # по людям
logs/YYYY-MM.md  # журнал
vectors/         # retrieval

Большие справочники не должны грузиться в каждый запуск. Они должны искаться.

12. Сделайте cron событийным

Cron должен отвечать на вопрос:

Есть ли новая работа?

И только потом будить агента.

Плохая схема:

каждые 15 минут → LLM → проверить всё заново

Хорошая схема:

каждые 15 минут → script pre-check
если изменений нет → спать
если изменения есть → короткий пакет данных → LLM

Для мониторинга, новостей, почты, задач, логов и цен это критично.

13. Просите короткий и проверяемый output

Для автоматизаций не нужен красивый роман.

Нужен компактный результат:

{
  "status": "needs_attention",
  "reason": "3 new invoices over budget",
  "next_action": "ask_user"
}

Форматируйте ответы:

  • максимальная длина;
  • JSON для автоматики;
  • bullet summary для человека;
  • отдельный artifact только по запросу;
  • без вступлений;
  • без пересказа входа;
  • без «вот что я сделал», если это не нужно.

Output часто дороже input, поэтому краткость — это не стиль, а бюджетная политика.

14. Закрепите экономию evals и бюджетами

Оптимизация без evals легко превращается в самообман.

После правок проверяйте:

  • стало ли меньше токенов;
  • не выросло ли число ошибок;
  • не стало ли больше повторных запусков;
  • не начал ли пользователь чаще исправлять агента;
  • не ухудшилось ли качество результата.

Главная метрика:

стоимость надёжно завершённой задачи

Не стоимость одного запроса.

Как это выглядит на разных платформах

OpenClaw

OpenClaw особенно чувствителен к архитектуре контекста, потому что живёт как постоянный агент: каналы, skills, memory, hooks, cron, browser, workspace.

Сначала проверьте:

  • какие bootstrap-файлы грузятся всегда;
  • насколько раздуты AGENTS.md, SOUL.md, USER.md, TOOLS.md;
  • сколько skills видно агенту;
  • какие MCP/tools подключены по умолчанию;
  • что возвращают tools;
  • как настроены cron jobs;
  • есть ли sandbox и allowlist/denylist для опасных инструментов.

В статьях по OpenClaw отдельно подчёркивается роль memory, compaction, hooks и sandbox: при длинной переписке агент сжимает контекст и пишет важное в memory, а sandbox нужен, чтобы не давать групповым сессиям опасный доступ к системе.

Для OpenClaw хорошая стратегия такая:

1 агент ≠ весь мир
1 агент = конкретная роль + минимальные tools + короткая память + понятные workflows

Claude Code

Claude Code уже имеет встроенные механизмы экономии: prompt caching, auto-compaction, /usage, /clear, модельные настройки, MCP-управление.

Anthropic прямо пишет: token costs scale with context size — чем больше контекст, тем больше токенов; Claude Code оптимизирует расходы через prompt caching и auto-compaction, но разработчику всё равно нужно держать контекст маленьким.

Практический набор:

/usage        # смотреть расход
/clear        # чистить контекст при смене задачи
/compact      # сжимать с инструкцией, что сохранить
/model        # менять модель по сложности
/mcp          # отключать лишние серверы

И главное: не превращайте CLAUDE.md в корпоративный талмуд.

Codex

Для Codex логика похожая:

  • корневой AGENTS.md — только глобальные правила;
  • локальные инструкции — рядом с модулем;
  • повторяемые процессы — в skills;
  • длинные регламенты — в references;
  • новая задача — новая сфокусированная сессия;
  • tools и коннекторы — только если нужны.

Codex, как и Claude Code, особенно выигрывает от короткого контекста и понятной структуры репозитория. Чем меньше агенту нужно «исследовать мир», тем меньше токенов он сожжёт на разведку.

Hermes

В Hermes, семейных ассистентах и Telegram/Discord-агентах главный источник расхода часто не кодинг, а повседневная автоматика.

Типичный набор оптимизаций:

  • reasoning по умолчанию снизить до medium/low;
  • простые напоминания перевести в script-only;
  • cron снабдить pre-check;
  • разделить диалоговый контекст и фоновую автоматику;
  • ограничить tool output;
  • сделать короткий SOUL.md;
  • вынести редкие инструкции в references;
  • поставить лимиты turns/tool calls;
  • добавить бюджет и telemetry.

Семейный ассистент может быть «тёплым» в диалоге, но это не значит, что каждое напоминание о школе должно грузить всю семейную историю и флагманскую модель.

Быстрый аудит за 30 минут

Если у вас уже есть агент и нужно быстро понять, где он жрёт токены, идите по этому порядку.

Шаг 1. Найдите два самых дорогих сценария

Обычно это:

  • один интерактивный сценарий;
  • один cron/automation сценарий.

Не распыляйтесь на всё сразу.

Шаг 2. Проверьте reasoning

Спросите:

Эта задача реально требует глубокого reasoning?

Если нет — снижайте.

Шаг 3. Проверьте постоянный контекст

Откройте:

  • AGENTS.md;
  • CLAUDE.md;
  • SOUL.md;
  • memory;
  • skills.

Удалите дубли. Уберите редкое в references. Сократите примеры.

Шаг 4. Проверьте tools

Для выбранного сценария выпишите:

Какие tools реально нужны?
Какие просто подключены исторически?

Отключите всё лишнее.

Шаг 5. Проверьте tool output

Если tool возвращает простыню, поставьте лимиты:

  • строки;
  • символы;
  • поля;
  • количество результатов;
  • время;
  • размер файлов;
  • глубина поиска.

Шаг 6. Проверьте cron

У каждого cron должен быть pre-check:

изменилось ли что-то с прошлого запуска?

Если нет — модель не будить.

Шаг 7. Проверьте качество после экономии

Через неделю сравните:

  • токены;
  • ошибки;
  • повторные запуски;
  • ручные исправления;
  • время выполнения;
  • стоимость завершённой задачи.

Финальная формула экономного агента

Экономный агент — не обязательно маленький и не обязательно глупый.

Это агент, у которого:

  • сильная модель вызывается только там, где окупается;
  • reasoning соответствует сложности задачи;
  • постоянный контекст короткий;
  • skills загружаются по требованию;
  • tools подключаются минимально;
  • результаты инструментов фильтруются до модели;
  • детерминированную работу делает код;
  • cron будит LLM только при изменениях;
  • циклы ограничены;
  • память разделена по слоям;
  • compaction проверяется;
  • качество и стоимость измеряются вместе.

В агентных системах токены расходуются не только текстом.

Их расходует архитектура.

Поэтому главный вопрос звучит не так:

Как попросить агента отвечать короче?

А так:

Что из отправляемого модели действительно необходимо именно на этом шаге?

Если задавать этот вопрос к каждому файлу, tool, skill, cron, MCP-серверу и агентному циклу, расходы начинают снижаться без превращения полезного помощника в дешёвый, но беспомощный чат-бот.

Самый дешёвый токен — не тот, который обработала маленькая модель.

Самый дешёвый токен — тот, который вы вообще не отправили.

По теме