Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Затраты кодовых агентов научились сокращать не в одной задаче, а на протяжении работы с репозиторием. Хотя работа не рецензирована и числа получили сами авторы, TokenEconomizer снизил среднюю стоимость токенов на 18,4–30,9% при сопоставимой доле решённых задач. Команда может оставить выбранную модель и агент, а экономию искать во внешнем управлении их работой.
Расходы повторяются вместе со способом работы
Кодовый агент платит не только за итоговый ответ. На каждом ходе модель снова получает системные инструкции, описание доступных инструментов и растущую историю команд, результатов и собственных сообщений. Кэширование удешевляет повторную передачу контекста, но не делает её бесплатной.
Обычные способы экономии работают непредсказуемо. Сжатие вывода команд, семантическая навигация по коду и карта структуры репозитория снижали расходы в одних проектах, но повышали в других. Одна постоянная конфигурация не учитывает, какие действия и инструменты полезны именно в этой кодовой базе.
История запусков показывает, где возникает повторяемый расход. Агент каждый раз получал описания 23 инструментов, хотя в отдельном репозитории использовал не больше 7. При этом три инструмента обеспечивали 98% всех вызовов, а остальные занимали место в контексте постоянно или требовались лишь изредка.
Другой источник затрат — повторное открытие локальных правил проекта. Агент заново выясняет, как запускать тесты, где искать нужные файлы и какой командой воспроизвести ошибку. Неудачные запуски также могут долго повторять одну и ту же ошибку, но простой предел по числу ходов не подходит: длинная траектория иногда заканчивается рабочим исправлением.
Как контроллер решает, что убрать из контекста
TokenEconomizer работает поверх агента и считает его чёрным ящиком. Он не меняет веса модели и внутренний цикл выполнения, а использует доступные точки управления: инструкции, набор инструментов и поток событий во время запуска. После каждой задачи контроллер обновляет состояние репозитория и применяет накопленный опыт к следующей.
Первый механизм превращает повторяющиеся факты в короткие микроподсказки. Например, контроллер может запомнить штатную команду тестирования или способ воспроизвести типовую ошибку. Подсказка включается только после подтверждения на нескольких задачах с разными изменёнными файлами; противоречащий запуск снижает доверие к ней, а устаревшее правило удаляется.
Второй механизм сокращает список инструментов. Базовые средства чтения, записи, редактирования файлов и запуска команд остаются всегда. Неиспользуемые инструменты скрываются, но периодическая повторная проверка возвращает полный набор: если ранее исключённый инструмент понадобился, контроллер больше его не убирает.
Третий механизм следит за циклами ошибок. Контроллер сравнивает текущую длину работы с успешными запусками в этом репозитории, ищет повторяющиеся сообщения об ошибках и плотный поток сбоев. Сначала он предлагает агенту сменить подход и передаёт краткое резюме уже сделанного; завершает запуск только после повторного признака зацикливания. Неуверенная оценка не останавливает работу.
Собственные вызовы контроллера входят в общий расход. Это важно для практического расчёта: метод не переносит часть стоимости в отдельную строку, а должен окупить анализ истории за счёт более коротких последующих запусков.
Командам стоит планировать слой управления, а не смену модели
Метод проверили на 579 задачах из четырёх бенчмарков: исправлениях из SWE-Bench, последовательной веб-разработке и двух видах аудита безопасности. В экспериментах участвовали Claude Code, Codex и GitHub Copilot CLI с несколькими моделями. Задачи внутри репозитория шли по времени, поэтому контроллер мог использовать только опыт, накопленный ранее.
Экономия появляется не сразу. В начале контроллер ещё не знает проект и сам добавляет расходы, но во всех репозиториях SWE-Bench совокупный запуск становился дешевле к шестой задаче. Поэтому подход лучше подходит продуктам с постоянной кодовой базой и потоком изменений, чем разовым запросам в новых репозиториях.
На последовательной веб-разработке стоимость снизилась на 16,0–21,2%, а доля выполненных задач осталась сопоставимой. На аудитах, где каждый запуск мог относиться к новому репозиторию, контроллер отключал локальные микроподсказки и сохранял управление инструментами и циклами ошибок. Экономия там зависела от длины траекторий и повторяемости самой процедуры.
Для архитектуры это означает, что контроль расходов можно вынести в отдельный слой рядом с агентом. Такой слой должен хранить историю по среде, измерять полную стоимость вместе со своими вызовами и уметь откатывать ошибочные решения. Менять модель ради экономии необязательно, если значительная часть счёта возникает из-за повторных инструкций, лишних схем инструментов и безрезультатных циклов.
Граница применимости проходит по наличию повторяемого контекста. Работа охватывает коммерческие агенты и несколько типов программных задач, но потоки SWE-Bench состоят из связанных исправлений, а не из реальных пользовательских сессий. Перед внедрением команде нужен собственный последовательный прогон на типичных репозиториях: средняя цена отдельной задачи не покажет, окупается ли накопление опыта.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
