TL;DR
TokenEconomizer — внешний контроллер для кодинг-агентов (Claude Code, Codex, Copilot CLI). Он наблюдает за прошлыми запусками в одном репозитории и по ним делает три вещи. Он вписывает в инструкцию однострочные факты о проекте («тесты запускаются так-то»), убирает из загрузки инструменты, которыми агент не пользуется, и останавливает или перенаправляет агента, когда тот зациклился на одной и той же ошибке. Агент при этом остаётся «чёрным ящиком»: контроллер правит только инструкции, набор инструментов и следит за событиями.
Главная находка: нет универсального рецепта экономии. Готовые плагины сжатия вывода и карт репозитория в одних проектах экономят, в других удорожают работу. Зато в логах агента видны три постоянные утечки. Во-первых, он заново открывает одно и то же: 12–28% его обращений к инструментам повторяют действия из прошлых задач того же репозитория. Во-вторых, он таскает на каждом шаге лишнее: из 23 загруженных инструментов ни один репозиторий не использовал больше 7, а 16 не вызывались вообще. В-третьих, он дорого буксует: провальные задачи составляют 17% от числа, но съедают 32% бюджета.
Метод закрывает эти утечки тремя ходами: микро-скиллы (короткие факты о проекте в инструкции), отключение неиспользуемых инструментов и охранник от зацикливания. В среднем это даёт –18…–31% стоимости при том же уровне успеха. Снижение reasoning effort (глубины «раздумий» модели) экономит больше, но заметно роняет качество. Полный контроллер — это код, но сами три принципа можно применять руками: аудит логов, CLAUDE.md/AGENTS.md и настройка набора инструментов.
Схема метода
ПЕРЕД КАЖДОЙ ЗАДАЧЕЙ контроллер смотрит на историю репозитория и решает:
1. МИКРО-СКИЛЛЫ: сжать прошлые трейсы → LLM предлагает однострочные факты
→ факт включается, если подтверждён на нескольких задачах
с РАЗНЫМИ файлами и реально был нужен
→ факт снимается, если хоть раз опровергнут (штраф > награды)
2. ЧИСТКА ТУЛОВ: инструмент убран, если N задач подряд не вызывался
ИЛИ LLM-судья считает его нерелевантным задаче
→ раз в какое-то время вернуть всё и перепроверить
3. ОХРАННИК: бюджет ходов = высокий перцентиль ходов УСПЕШНЫХ прошлых задач × запас
→ дешёвая проверка правилами после каждого вызова
→ при подозрении судья смотрит дайджест: застрял или идёт?
→ застрял: перенаправить («смени подход») → повтор: остановить
→ жёсткий стоп как страховка
Всё это отдельный контроллер на коде. Одним промптом в чате он не воспроизводится, воспроизводятся его принципы.
Пример применения
Задача: Команда делает бэкенд сервиса быстрой доставки на Django, примерно как «Самокат» или «Яндекс Лавка». Используют Claude Code. На каждой задаче агент тратит первые ходы на одно и то же: выясняет, как запускать тесты (docker compose exec web pytest), пробует pip install там, где всё уже стоит, и ищет, где лежат фикстуры. К тому же подключено шесть MCP-серверов, из которых реально нужны два. Счёт за месяц вырос, а причину никто не понимает.
Промпт (ручной аудит последних сессий; логи или экспорт сессий вставляются ниже):
Ты — аудитор расходов кодинг-агента. Ниже логи 10 последних сессий агента
в репозитории «delivery-backend» (Django, docker compose, pytest).
<Задача>
Найди, на что агент тратит ходы зря, и предложи правки инструкции и набора инструментов.
<Шаг_1_повторы>
Выпиши действия, которые повторяются минимум в половине сессий
(поиск команды запуска тестов, лишние установки, поиск одних и тех же файлов).
Для каждого сформулируй ОДНУ строку-факт для CLAUDE.md.
Для каждого факта укажи:
- как проверить, что факт верен (команда или признак в логе);
- в скольких сессиях он подтвердился и в каких файлах (файлы не должны совпадать во всех сессиях);
- в скольких сессиях агент реально из-за него терял ходы.
Факт, который хоть раз оказался неверным, помечай «ОПРОВЕРГНУТ — не включать».
<Шаг_2_инструменты>
Составь таблицу: инструмент / сколько раз вызван / в скольких сессиях.
Предложи отключить те, что не вызывались ни разу. Для спорных напиши,
в какой задаче они всё же могли бы понадобиться.
<Шаг_3_буксование>
Найди сессии, где агент долго повторял одну и ту же ошибку.
Для каждой: на каком ходу стало ясно, что он застрял, чем отличалась
застрявшая сессия от успешной, и какую фразу-перенаправление
стоило ему дать («смени подход: ...»).
<Формат>
Верни: (а) блок строк для CLAUDE.md, (б) список инструментов на отключение,
(в) правило «когда останавливать агента». Не придумывай факты, которых нет в логах.
[сюда вставить логи сессий]
Результат: Модель вернёт три блока. Первый — короткий список проверяемых фактов для CLAUDE.md с отметкой, на скольких сессиях каждый подтверждён. Второй — таблицу вызовов инструментов и список кандидатов на отключение. Третий — признаки «агент застрял» с готовой фразой для перенаправления. Правки вы вносите руками и сравниваете счёт за следующие 5–10 задач.
Почему это работает
Слабость: агент ничего не помнит между сессиями, а каждый его ход оплачивается вместе со всей накопленной историей и со схемами всех загруженных инструментов. Поэтому всё, что агент заново выясняет в начале задачи, и все лишние инструменты он оплачивает на каждом шаге. «Универсальные» ускорители не помогают, потому что у каждого проекта своя специфика: то, что сжимает вывод в Django, мешает в SymPy.
Сила: LLM хорошо сжимает трейсы в короткие факты и различает «застрял» и «трудно, но движется», если дать ей компактный дайджест. Однострочный факт в инструкции стоит копейки, а экономит ходы во всех следующих задачах. Лишний инструмент убрать проще всего: он оплачивается на каждом ходу каждой задачи. Поэтому в абляциях чистка инструментов дала самый большой вклад (–13…–18%), микро-скиллы почти столько же (–12…–14%), охранник заметно меньше (–5…–7%). Но ни один приём в одиночку не повторил общий результат.
Рычаги управления: - Порог подтверждения факта → строже, и в инструкцию попадает меньше фактов, но все надёжные. Требуйте подтверждения на задачах с разными файлами, чтобы отсечь «факты одной задачи». - Асимметрия штрафа → один опровергнутый факт перевешивает одно подтверждение. Устаревший факт оплачивается на каждой задаче и опасен, а вычеркнутый зря факт можно предложить снова. - Число задач без вызова инструмента → меньше, и чистка агрессивнее. Всегда оставляйте базовые инструменты (shell, чтение, запись, правка). - Перепроверка набора инструментов → время от времени возвращайте полный набор и смотрите, не понадобилось ли что-то. - Запас бюджета ходов → считайте по успешным прошлым задачам этого репозитория. Единого лимита на все проекты нет: у Matplotlib провалы идут по 45 ходов против 20 у успешных, у Sphinx 36 против 31. - Перенаправить, потом остановить → сначала просите сменить подход, и только при повторе обрывайте.
Шаблон промпта
В показанной части статьи нет готовых промптов контроллера. Ниже ручной перенос принципов метода в чат: роль «предложителя» микро-скиллов из первой мета-стратегии. Структура сохраняет логику оригинала: кандидат, детектор, подтверждение, отзыв.
Ты — предложитель микро-скиллов для кодинг-агента в репозитории {репозиторий}.
Микро-скилл = ОДНА строка операционного факта о проекте + способ его проверить.
{логи_или_дайджесты_последних_сессий}
For each повторяющееся действие в Evidence:
1. Сформулируй кандидата: одна строка-инструкция для {файл_инструкций}.
2. Придумай детекторы:
- scope: по какому признаку в логе видно, что ситуация вообще возникла;
- contradicts: по какому признаку видно, что факт ОШИБОЧЕН;
- need: по какому признаку видно, что агент потерял на этом ходы
или использовал этот факт.
3. Проверь по каждой сессии: exercised? confirmed / contradicts? needed?
4. Статус:
- ACTIVE — подтверждён минимум в {мин_задач} сессиях с НЕПЕРЕСЕКАЮЩИМИСЯ
наборами файлов И нужен в доле сессий не ниже {порог_нужности};
- WITHHELD — подтверждён, но редко нужен (не вставлять, не удалять);
- RETIRED — есть опровержение, которое перевешивает подтверждения
(одно опровержение весит больше одного подтверждения); больше не предлагать;
- CANDIDATE — данных мало.
Что подставлять:
- {репозиторий} — название проекта и стек.
- {логи_или_дайджесты_последних_сессий} — команды, запуски тестов, названия изменённых файлов и тексты ошибок из 5–10 сессий.
- {файл_инструкций} — CLAUDE.md, AGENTS.md или аналог.
- {мин_задач} — например, 3.
- {порог_нужности} — например, 50%.
🚀 Быстрый старт — вставь в чат:
Вот шаблон «предложителя микро-скиллов» для кодинг-агента. Адаптируй под мой проект: [описание репозитория и агента].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про стек и способ запуска тестов, про то, какой агент и какой файл инструкций вы используете, и какие логи сессий у вас есть. Это нужно, чтобы корректно сформулировать детекторы: по чему в вашем логе видно «ситуация возникла», «факт ложен» и «время потеряно». Дальше она подстроит шаблон под ваш формат логов.
Ограничения
⚠️ Полный метод — это код: контроллер следит за событиями агента в реальном времени, считает перцентили, запускает судью на ходу. В обычном чате воспроизводится только ручная версия: аудит логов, правка инструкции, отключение инструментов. Эффект ручной версии авторы не измеряли.
⚠️ Нужен сигнал успеха: бюджет ходов считается по успешным прошлым задачам. Без тестов или другого понятного критерия «задача решена» охранник от зацикливания работает вслепую.
⚠️ Первые задачи дороже: контроллер платит за собственные вызовы LLM и ничего не знает о проекте. Почти во всех репозиториях сначала расходы выросли, и экономия пошла только к шестой задаче. На разовых задачах в новом репозитории выигрыша не будет.
⚠️ Факты быстро устаревают: если факт в инструкции стал ложным, вы платите за него на каждом ходу и ведёте агента не туда. Нужен механизм отзыва, а для ручной версии — регулярный пересмотр
CLAUDE.md.
⚠️ Вне кода выигрыш меньше: на последовательных веб-задачах и аудите безопасности экономия 6–21%, и она зависит от структуры задач. Качество при этом осталось сопоставимым, но в одной из пяти связок «агент–модель» Pass@1 на SWE-Bench упал на 1 п.п.
⚠️ Чужие плагины вслепую вредят: сжатие вывода команд (RTK) и карта репозитория (RepoMap) в заметной части случаев удорожали работу. Ставить их «потому что все ставят» нельзя без замера на своём проекте.
⚠️ Снижать effort ради экономии рискованно: это сильнее всего режет счёт, но роняет долю решённых задач на 2–10 п.п.
Как исследовали
Сначала авторы не стали предлагать метод, а выяснили, где утекают деньги. Они взяли 60 задач SWE-Bench из шести репозиториев и прогнали три популярных «ускорителя»: сжатие вывода команд (RTK), семантическую навигацию (Serena) и карту репозитория от Aider. Ни один не экономил стабильно: в Django помогали все три, в SymPy все три удорожали работу. Это показало, что фиксированных рецептов нет и политику нужно учить на истории конкретного репозитория. Затем авторы посмотрели на нетронутые трейсы и увидели три утечки: повторы действий (12–28% обращений, после пятой задачи около 30% вызовов повторяют прошлое), мёртвые инструменты (16 из 23 не вызваны никогда) и дорогие провалы (17% задач дали 32% затрат).
Дальше построили контроллер и проверили его на пяти связках «агент–модель»: Claude Code с двумя моделями, Copilot CLI и Codex с двумя моделями. Это 277 задач из шести репозиториев, по три прогона на каждую, и все расходы контроллера включены в счёт. Задачи шли в хронологическом порядке, чтобы контроллер учился только на «прошлом». Результат: стоимость упала на 18–31%, Pass@1 вырос в четырёх связках из пяти. Экономия есть в каждой из 30 пар «репозиторий × связка» (5–40%), тогда как RTK удорожал работу в 12 парах, RepoMap — в 15. Перенос на веб-разработку (102 задачи) и аудит безопасности (200 задач) дал 16–21% и 6–20%.
Неожиданностей две. Самый крупный вклад дала не умная «память», а скучная чистка инструментов, потому что она действует на каждом ходу каждой задачи. Охранник дал меньше всего: почти половина повторяющихся ошибок происходит в запусках, которые потом успешно завершаются, поэтому «повторил ошибку» ещё не значит «пора останавливать». Практический вывод: сначала уберите лишнее, потом записывайте повторяющиеся факты и только потом занимайтесь остановкой.
Адаптации и экстраполяции
🔧 Техника: убрать инструмент из набора → проверять, чем его заменить
Перед отключением попросите модель проверить, не потеряете ли вы нужное:
Для каждого инструмента из таблицы на отключение назови задачу из моего
бэклога ниже, где он был бы незаменим. Если такой задачи нет — «можно отключать».
Бэклог: {список_ближайших_задач}
Это ручной аналог «судьи релевантности» из метода: решение принимается с учётом того, что вы собираетесь делать.
🔧 Техника: фраза-перенаправление → вместо отмены «смени подход»
Когда видите, что агент долбится в одну ошибку, дайте ему сводку, а не просто «стоп»:
Остановись. Вот что ты сделал за последние шаги: {список_команд}. Ошибка не меняется:
{текст_ошибки}. Назови 2 гипотезы, почему не получается, выбери ту, что отличается
от твоих прежних попыток, и проверь одной командой.
Это ручная версия «перенаправить, а при повторе остановить». Расчёт простой: сменить подход дешевле, чем платить за новый круг тех же действий.
Экстраполяция: правило «лимит ходов по истории» в
CLAUDE.md. Авторы считают бюджет по успешным задачам своего репозитория. Ручная версия — записать в инструкции типичное число ходов для ваших задач и правило: «если пошёл третий круг с той же ошибкой — остановись и опиши, что пробовал». Это мой перенос, он в статье не проверялся.
Ресурсы
- Название: TokenEconomizer: Experience-Driven Black-Box Cost Control for Coding Agents
- Авторы: Aaron J. Li, Weijia Xu, Chandan Singh, Zixiao Chen, Jeevana Priya Inala, Charlotte Siska, Acar Tamersoy, Bin Yu, Ion Stoica, Michel Galley, Jianfeng Gao
- Организации: UC Berkeley, Microsoft Research, Microsoft Security
- Страница проекта: https://tokeneconomizer.github.io
- Код: https://github.com/microsoft/TokenEconomizer
- Связанные инструменты: Rust Token Killer (RTK), Serena, Aider RepoMap
- Бенчмарки: SWE-Bench, Web-Bench, CredData, ReposVul
Часть приложений и таблиц в предоставленном тексте обрезана, поэтому тексты промптов контроллера и примеры микро-скиллов (Приложение I) здесь не приводятся.