Короткий ответ: в агентной разработке основной расход часто создают входные токены. Агент снова получает инструкции, историю решений, фрагменты исходного кода, результаты команд, логи и ошибки предыдущих шагов. Финальный ответ при этом может занимать всего несколько строк.
Модель работает в цикле: получает задачу, читает проект, вызывает инструмент, анализирует результат, выполняет следующую команду и снова обращается к API. На каждом шаге ей нужен актуальный контекст. Чем длиннее сессия и чем больше промежуточных данных в истории, тем больше материала приходится обрабатывать повторно.
Короткое сообщение вроде «Готово» почти не влияет на счёт, если перед ним агент несколько раз отправлял большой репозиторий, логи тестов и результаты поиска. При оценке расходов нужно смотреть на всю последовательность входов, tool output и итераций, а не на объём последнего текста модели.
Короткий ответ: агент платит за повторно переданный контекст
В обычном диалоге пользователь отправляет вопрос и получает ответ. В кодинге агентный цикл устроен иначе. Модель должна сохранять связность между действиями, поэтому каждый следующий вызов учитывает состояние проекта и уже полученные результаты.
Условная последовательность выглядит так:
- агент получает системные правила и задачу;
- читает нужные файлы и структуру репозитория;
- запускает поиск, тесты, линтер или сборку;
- получает вывод инструмента;
- выбирает следующую команду с учётом предыдущих решений;
- повторяет цикл до исправления проблемы и проверки результата.
Каждая итерация добавляет новые данные или повторно передаёт уже известные. Расход можно описать простой концептуальной формулой:
расход примерно зависит от суммы размеров контекста на каждом шаге и числа шаговЭто не расчёт для конкретного API. Провайдеры по-разному считают входные, выходные и кэшированные токены. Формула нужна для другой мысли: длинная сессия дорожает из-за накопительного эффекта.
Из чего складывается стоимость AI-агентов в кодинге
Счёт формируют несколько групп данных. Часть появляется в начале работы, часть растёт по мере итераций.
Стартовый контекст: инструкции, репозиторий и правила проекта
Расход начинается до первой полезной правки. Агенту могут передаваться системные инструкции, правила репозитория, глобальные настройки, описание архитектуры, открытые файлы и дополнительные документы.
Большой стартовый контекст увеличивает базовую стоимость каждого цикла. Если в общие инструкции включён подробный справочник на десятки страниц, агент может получать его при работе над задачей, которой нужен один небольшой раздел. Автоматически подключённые файлы создают похожий эффект.
Широкий scope увеличивает неопределённость и число чтений. Запрос «разберись с авторизацией во всём проекте» почти гарантированно потребует больше контекста, чем задача «исправь проверку токена в конкретном middleware и добавь тест на просроченный токен».
Полезно заранее зафиксировать:
- какие каталоги относятся к задаче;
- какие файлы агенту разрешено менять;
- какие документы описывают нужное поведение;
- какие команды подтверждают готовность;
- какие правила проекта обязательны для этого изменения.
Так агент получает рабочее окружение с понятными границами. В контекст не попадают материалы, которые не участвуют в решении.
История диалога и уже прочитанный код
После стартовых инструкций к запросу добавляется история. В ней остаются исходная постановка, план, найденные файлы, изменения, уточнения пользователя и результаты проверок.
Условный пример: сначала агент читает три файла и предлагает план. Затем меняет один модуль, запускает тесты и получает ошибку. После исправления он повторно учитывает предыдущий план, изменённый код и лог теста. На следующем шаге к ним добавляется новый результат.
Повторная передача нужна для связности. Модель должна знать, почему был выбран конкретный файл и какой дефект обнаружила проверка. Экономически этот механизм не бесплатен: история превращается в часть входа последующих запросов.
Проблема усиливается, когда в диалоге остаются большие фрагменты исходников. Повторное чтение одного файла может быть оправдано после изменения его зависимостей. Многократная пересылка неизменного файла из-за слишком широкого поиска создаёт расход без сопоставимой пользы.
Вывод инструментов, логи и ошибки команд
Tool output часто недооценивают. Агент может получать результаты поиска, содержимое файлов, вывод тестов, сообщения сборщика, логи линтера и ответы shell-команд.
Одна команда способна вернуть несколько тысяч строк. В следующий цикл попадут полезные сведения об ошибке и большой объём повторяющегося шума: трассировки, строки успешно пройденных тестов, дублирующиеся предупреждения и нерелевантные сообщения зависимостей.
Особенно быстро контекст растёт в таких сценариях:
- рекурсивный поиск по всему репозиторию вместо поиска в нужном каталоге;
- чтение больших файлов целиком ради одной функции;
- повторный запуск тестов без фильтра по конкретному пакету или сценарию;
- вывод полного лога сборки после каждой небольшой правки;
- многократное добавление одной и той же ошибки в историю.
Узкая команда часто даёт агенту достаточно данных для решения. Для диагностики падающего теста обычно полезнее имя теста, несколько строк вокруг ошибки и релевантный стек вызовов, чем полный лог всего запуска.
Почему длинная сессия раздувает счёт
Длинная задача превращается в цепочку накоплений. Каждый новый шаг может добавлять код, команды, ошибки и пояснения. Чем больше таких элементов, тем тяжелее следующий вызов.
Представьте работу над API-эндпоинтом:
- агент читает роут, контроллер и схему данных;
- запускает тесты и получает ошибку импорта;
- исправляет импорт, но сталкивается с неверным типом;
- читает ещё два файла и запускает полный набор тестов;
- получает большой лог с одной новой проблемой;
- исправляет её и снова проверяет проект.
Финальная правка может быть короткой. Однако последняя итерация учитывает значительную часть накопленной истории и результатов инструментов.
Повторная пересылка важнее длины финального ответа
Короткий ответ не означает дешёвый запрос. Агент может потратить большой объём входных токенов на анализ и вернуть две строки: «Тесты проходят, изменения внесены».
Обратная ситуация тоже возможна. Модель выдаёт подробное объяснение, но работает с небольшим контекстом и выполняет мало итераций. Тогда расходы на выходные токены могут быть заметнее, однако в агентном кодинге главный источник роста часто находится во входе.
Сокращение текстового резюме полезно для читаемости истории. Оно почти не решает проблему, если крупные файлы и логи продолжают пересылаться на каждом шаге.
Как ошибки превращаются в платные итерации
Ошибка команды запускает новую цепочку расходов:
- агент формирует неверную команду;
- терминал возвращает сообщение об ошибке;
- лог попадает в историю;
- агент повторно анализирует старый контекст вместе с новым сообщением;
- следующая попытка создаёт ещё один вывод.
Один сбой не опасен. Серия плохо сформулированных команд, повторное чтение тех же файлов и отсутствие критерия готовности быстро увеличивают число циклов.
Спецификация и тест-план сокращают такой расход. Сначала фиксируется требуемое поведение, затем создаются проверки, после чего агент меняет код небольшими шагами. Для workflow Codex полезна последовательность RED - GREEN: сначала тест подтверждает отсутствие нужного поведения, затем минимальная правка переводит его в проходящий статус.
Failing-тест не следует переписывать только ради зелёного статуса. Иначе агент может одновременно закрепить ошибку в коде и ослабить проверку, а затем потратить новые итерации на поиск последствий.
Почему попытка «дожать» старую сессию после паузы часто невыгодна
После длительной паузы старый диалог может содержать большой объём истории и устаревшие предположения. Проект уже изменился, ветка могла переключиться, а часть решений перестала соответствовать текущей задаче.
В такой ситуации новая короткая сессия часто рациональнее продолжения. В неё можно передать:
- текущую цель;
- состояние рабочей ветки;
- список изменённых файлов;
- краткое описание уже проверенного поведения;
- команды для финальной проверки.
Продолжение старой сессии сохраняет удобство, когда контекст небольшой, задача не изменилась и агенту нужны конкретные незавершённые решения. Универсального правила нет. Решение зависит от размера истории, длительности паузы, числа ошибок и состояния проекта.
Для архитектурных задач с большим количеством итераций полезно заранее записывать компактное состояние. Такой файл или сообщение облегчает переход в новую сессию без переноса всей переписки.
Prompt cache: что он действительно экономит
Prompt cache, или кэш промпта, позволяет повторно использовать часть входного контекста при подходящих условиях провайдера. Идея проста: стабильный префикс не обязательно обрабатывать как полностью новый на каждом вызове.
Кэш снижает стоимость повторного обращения к одной и той же части запроса, однако не превращает длинную сессию в бесплатную. Для оценки нужно разделять повторяющийся префикс, кэшируемые токены и новые данные.
Что может попасть в кэш, а что меняется на каждом шаге
Условно запрос можно разделить на две части. В первой находятся стабильные инструкции, правила проекта и повторяющийся префикс истории. Во второй появляются новые результаты команд, изменённые файлы, уточнения пользователя и свежие ошибки.
Например, правила форматирования могут оставаться одинаковыми на протяжении всей задачи. Вывод теста меняется после каждой правки. Даже при успешном кэшировании стабильной части агент продолжает получать новые токены.
Точные правила зависят от API и поставщика. На результат могут влиять структура запроса, порядок блоков, время жизни записи и способ формирования контекста. Поэтому поведение prompt cache нужно сверять с документацией конкретного сервиса и доступной телеметрией.
Почему кэш не отменяет стоимость длинных сессий
Кэш не убирает расходы на новые результаты инструментов, меняющуюся историю и дополнительные вызовы модели. Если агент запускает десять лишних команд, повторное использование стабильного префикса не компенсирует весь объём созданных данных.
Кэш помогает там, где контекст действительно повторяется. Архитектура workflow определяет, сколько контекста появляется вообще. Поэтому управление scope задачи, размером логов и количеством итераций обычно важнее одной настройки кэширования.
Полезно разделять три вопроса:
- повторяется ли часть промпта;
- попадает ли она в кэш по правилам провайдера;
- какой новый контекст добавляется на каждом шаге.
Куда утекают токены в Claude Code и Codex: карта аудита
Claude Code, Codex и похожие инструменты отличаются интерфейсом, политикой биллинга и внутренней обработкой контекста. При сравнении нельзя приписывать им одинаковую механику. Аудит лучше строить по наблюдаемым категориям: инструкции, файлы, команды, история, tool output, хуки и плагины.
Архитектура обвязки влияет на число шагов и объём передаваемых данных. Практический разбор пяти coding-agent harness опубликован в статье «Архитектурные ставки обвязки кодинг-агентов». Для расходов важен вывод: стоимость задаёт весь контур работы, а модель выступает лишь одной его частью.
Автоматически подключаемые инструкции, хуки и плагины
Пользователь может не добавлять часть контекста вручную. Его способны формировать правила проекта, глобальные инструкции, интеграции, плагины и хуки.
Для каждого элемента полезно выяснить:
- запускается ли он на каждом шаге;
- какой объём текста или лога возвращает;
- нужен ли он для текущего типа задачи;
- можно ли ограничить его область действия;
- создаёт ли он дополнительные вызовы инструментов.
Хук, который сообщает короткий статус после изменения файла, может быть полезен. Автоматизация, каждый раз возвращающая полный список зависимостей или большой диагностический лог, требует отдельной проверки.
Собственный агентный контур удобно сравнивать по latency, cost и reliability, но эти показатели зависят от одинаковости задач и настроек. Практический материал об архитектуре самописного агента доступен в статье «Строим AI-агента с нуля».
Tool output: полезный результат или лишний дамп
Нужный вывод отвечает на вопрос текущего шага. Лишний дамп переносит в историю данные, которые агент уже не использует.
Для контроля tool output применяйте узкие команды:
- ограничивайте число строк;
- ищите в конкретном каталоге или файле;
- запускайте отдельный тест вместо всего набора;
- выводите только строки вокруг ошибки;
- повторно не читайте неизменённые большие файлы без причины.
Ошибки скрывать нельзя, если они нужны для диагностики. Сокращать нужно повторяющийся шум. При сложном логе можно сначала получить необработанный результат, затем передать агенту компактную сводку с точными строками и командой воспроизведения.
Как снизить стоимость агентной разработки без потери качества
Снижение расходов начинается с управления рабочим процессом. Простое ограничение длины ответа даёт слабый эффект, если агент продолжает работать с чрезмерно широким контекстом.
Дробление работы на короткие сессии
Разделяйте исследование, планирование, изменение кода и проверку, когда между этапами есть ясная граница. Новая сессия должна получать компактный статус: цель, затронутые файлы, принятые решения, открытые проблемы и команды проверки.
Короткая сессия уменьшает накопление истории. Её стоимость проще оценить, а устаревшие предположения легче отбросить. Риск тоже существует: при слишком агрессивном дроблении можно потерять важную связь между решениями. Сохраняйте её в кратком техническом резюме.
Ограничение вывода инструментов
Начните с самых шумных команд. Добавьте фильтры, лимиты строк и выборочные тесты. Для поиска используйте конкретный каталог, для логов - диапазон вокруг ошибки, для тестов - нужный пакет или сценарий.
Так уменьшается входной контекст следующих шагов. Цена меры - возможная потеря диагностической детали. Если агенту не хватает данных, запросите расширенный вывод на отдельной итерации, а не отправляйте полный дамп заранее.
Ревизия хуков и плагинов
Составьте список всех автоматизаций, связанных с coding agent. Отдельно отметьте, какие из них запускаются при чтении файлов, выполнении команд, изменении кода и завершении шага.
Отключать всё подряд не нужно. Уберите или сузьте элементы, которые не влияют на текущую задачу и создают повторяющийся вывод. Перед изменением проверьте, не отвечает ли автоматизация за безопасность, форматирование или обязательные проверки.
Спецификация и TDD как средство контроля итераций
Чёткая спецификация уменьшает число уточнений и ошибочных попыток. В ней должны быть описаны входные данные, ожидаемое поведение, ограничения и критерии готовности.
Затем составьте тест-план. Для Codex подходит workflow, где тесты создаются до реализации, а каждое отдельное поведение проходит цикл RED - GREEN. Тест должен проверять исходное требование. Переписывание проверки под уже созданный код экономит одну итерацию сегодня и увеличивает риск новых итераций завтра.
Контрольный список для задачи можно дополнить четырьмя пунктами:
- какое поведение меняется;
- какие файлы входят в scope;
- какая команда подтверждает результат;
- какие изменения нельзя вносить.
Для задач, где агент выполняет много самостоятельных циклов, полезны лимиты и оракулы проверки. Практические примеры такого подхода собраны в статье «Loop Engineering: как спроектировать самоуправляемый цикл для кодинг-агентов».
Как оценивать стоимость задачи до запуска агента
Без данных конкретного API нельзя честно назвать универсальную цену. Зато можно оценить источники расхода до первого вызова.
Минимальный чек-лист перед стартом
- Определите цель одним проверяемым предложением.
- Укажите границы файлов и каталогов.
- Подготовьте критерии готовности.
- Назначьте команды для тестов, линтера или сборки.
- Перечислите инструменты, которые действительно нужны.
- Уберите из контекста справочные материалы, не связанные с задачей.
- Задайте формат краткого состояния для возможного перехода в новую сессию.
Перед запуском оцените четыре величины: размер стартового контекста, ожидаемое число итераций, средний объём tool output и вероятность повторных запусков из-за ошибок.
| Параметр | Что проверить | Как уменьшить расход |
|---|---|---|
| Стартовый контекст | Инструкции, правила, файлы и документы | Сузить scope и убрать нерелевантные материалы |
| Число итераций | Сложность задачи и количество проверок | Разбить работу и заранее описать критерии готовности |
| Tool output | Размер логов, поиска и чтения файлов | Добавить фильтры, лимиты строк и выборочные команды |
| Повторные запуски | Риск неверных команд и неясной постановки | Подготовить спецификацию и тест-план |
Фактическую оценку нужно строить по телеметрии конкретного сервиса: входным, выходным и кэшированным токенам, числу вызовов и правилам тарифа. Универсальные числа из одной статьи для этого не подходят.
Когда новая сессия дешевле продолжения старой
Ориентируйтесь на четыре сигнала: история стала большой, повторяются ошибки, задача изменилась или после паузы прошло достаточно времени, чтобы состояние проекта стало иным.
Продолжение старой сессии оправдано, когда агент уже собрал узкий контекст и находится рядом с проверяемым результатом. Новая сессия рациональнее, когда для каждого следующего шага приходится переносить длинную переписку, старые логи и решения, которые уже требуют пересмотра.
Сравнивайте два варианта по совокупной стоимости: сколько контекста придётся передать, сколько итераций ожидается и каков риск повторить неверное предположение. Удобство одной кнопки не всегда совпадает с экономичностью.
Итог: в агентной разработке нужно оптимизировать контекстный цикл
Главное
- Длинная история увеличивает объём входных данных последующих вызовов.
- Tool output, логи и ошибки команд часто создают больше лишнего контекста, чем финальный ответ.
- Короткий ответ модели не равен дешёвому запросу.
- Prompt cache снижает стоимость подходящей повторяющейся части, но не убирает новые данные и дополнительные итерации.
- Короткие сессии, узкий scope, фильтрация вывода и ясная спецификация уменьшают перерасход.
Практическое правило на каждый день: перед запуском уменьшите стартовый контекст, во время работы контролируйте tool output, после длительной паузы заново соберите компактное состояние проекта. Так вы платите за полезную работу агента, а не за бесконечное хранение истории.
Агентный кодинг требует контроля всей цепочки: от постановки задачи до последней проверки. Почему рост объёма сгенерированного кода сам по себе не гарантирует ускорения, разобрано в статье «Code-агенты: ускорение разработки или когнитивная ловушка?».
Частые вопросы (FAQ)
Почему короткий ответ может быть дорогим?
Потому что цена запроса зависит от всей последовательности входов и выходов. Перед коротким ответом агент мог обработать большой объём истории, исходного кода и логов.
Всегда ли prompt cache уменьшает счёт?
Нет. Кэш помогает при повторном использовании подходящей части контекста по правилам конкретного провайдера. Новые результаты инструментов, изменённая история и дополнительные вызовы остаются расходом.
Нужно ли начинать новую сессию после паузы?
Не всегда. Если задача прежняя, история небольшая и состояние проекта не менялось, продолжение может быть удобным. При большой истории, новых изменениях и повторяющихся ошибках компактная новая сессия часто рациональнее.
Какой tool output особенно вреден для бюджета?
Полные логи сборки, рекурсивные результаты поиска, повторное чтение больших файлов и вывод, который добавляется после каждой команды без фильтрации. Сокращайте шум, сохраняя строки, необходимые для диагностики.
Стоит ли отключать все хуки и плагины?
Нет. Сначала выясните, что они делают и какой вывод создают. Отключайте или ограничивайте автоматизации, которые не нужны текущей задаче. Проверки безопасности и качества нельзя убирать без оценки риска.
Как сравнивать Claude Code и Codex по расходам?
Сравнивайте одинаковые задачи, одинаковый scope, число итераций, объём tool output и фактическую телеметрию. Тарифы, кэширование и правила подсчёта у сервисов различаются, поэтому сравнение по длине финальных ответов вводит в заблуждение.