Как отследить реальную стоимость ИИ-агентов для кодирования: руководство по построению журнала затрат

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

Обычный дашборд показывает общие цифры. Журнал затрат объясняет транзакции: какой сеанс агента стоил $8,40 и занял 42 минуты, но 78% стоимости ушло на перечитывание неизменённого контекста.

Проблема: агент выглядит продуктивным, а бюджет тает

ИИ-агенты для написания кода перестали быть экспериментом. Их используют ежедневно: фиксят баги, рефакторят тесты, генерируют PR. Но есть оборотная сторона — реальная стоимость сеанса агента часто оказывается в разы выше, чем кажется из отчёта провайдера LLM.

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

Статья на dev.to предлагает конкретный ответ: построить журнал затрат (cost ledger) для ИИ-агентов — структурированную запись каждого значимого события стоимости внутри сессии. Не замена дашборду, а его дополнение, которое превращает «ИИ стал дороже» в доказательную базу на уровне отдельных сессий.

Почему учёт затрат агента сложнее, чем учёт API

Классический расход на API-вызовы прозрачен: endpoint, количество запросов, время ответа, привязка к клиенту. Всё просто.

С ИИ-агентом всё сложнее. Одна задача может включать:

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

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

Именно поэтому журнал затрат — это не просто расширенный дашборд. Дашборд показывает итоги. Журнал объясняет, откуда они взялись.

Что именно должен отслеживать журнал

Полезный журнал фиксирует значительно больше, чем просто токены. Вот минимальный набор:

• запросы к модели (input/output токены);
• попадания и промахи кеша (cache hits/misses);
• вызовы инструментов (чтение файлов, запись, shell-команды);
• запуски тестов;
• циклы ретраев;
• время ожидания одобрения;
• сгенерированные diff'ы;
• созданные коммиты или PR;
• ошибки и откаты;
• оценочная стоимость от провайдера;
• доказательства ценности: смерженные PR, пройденные тесты, закрытые ишью.

Цель — не идеальный бухгалтерский учёт, а «видимость, достаточная для принятия решений». Если вы можете сказать: «Этот агент потратил $8,40 за 42 минуты на 12-строчный фикс, причём 78% стоимости — перечитывание неизменённого контекста. Нужно кешировать саммари репозитория» — значит, система работает.

Пять метрик, которые обнаруживают потери

Не нужен гигантский аналитический стек на старте. Достаточно пять чисел на каждую сессию.

1. Общая стоимость сессии

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

2. Доля повторного ввода

повторные_токены_ввода / общие_токены_ввода

Высокая доля означает, что агент снова и снова читает один и тот же контекст репозитория, логи или предыдущее состояние разговора. Это, пожалуй, самый быстрый способ обнаружить скрытые потери. Типовые решения: кеши саммари репозитория, дайджесты файлов, лимиты на retrieval, более жёсткие контракты задачи.

3. Стоимость на принятую строку кода

стоимость_сессии / количество_строк_в_принятом_diff

Метрика несовершенная — 5-строчный security-фикс может стоить дороже 400-строчного реформатирования. Но она помогает выявить сессии, где агент «молотил» без значимого результата. Более точные сигналы ценности: смерженный PR, закрытый баг, добавленные тесты, воспроизведённый инцидент.

4. Время простоя на одобрение

Агенты часто ждут решения человека. Это не стоимость токенов, но стоимость рабочего процесса. Если агенты простаивают часами у gate'ов одобрения — нужны лучшие тиеры риска, маршрутизация ревьюеров, автоодобрение для низкорисковых действий и таймауты с безопасным откатом.

5. Покрытие верификации

Дешёвая сессия, которая выкатила непротестированный код — не дешёвая. Стоит трекать, создал ли агент доказательства: падающий тест до фикса, проходящий — после, lint/typecheck вывод, скриншот для UI-изменений, dry-run миграции, план отката.

Сессия с высокой стоимостью и слабой верификацией должна попасть на ревью до того, как станет шаблоном рабочего процесса.

Архитектура: сессия как единица работы

Самая частая ошибка — трекать отдельные вызовы модели, не группируя их в сессии. Для ИИ-агента сессия — это единица работы: «Исправить баг с webhook'ами Stripe», «Добавить кнопку экспорта в таблицу инвойсов».

Каждое событие стоимости привязывается к session_id. Это единственное место, где сходятся стоимость, время, инструменты и результат. Автор предлагает начать с одного объекта сессии и одного потока событий, а не проектировать двадцать таблиц.

События лучше хранить как append-only записи — неизменяемые, с временными метками. Это проще для отладки и надёжнее, чем мутабельные счётчики. Каждое событие содержит тип (model_request, tool_call, verification), привязку к сессии и метаданные. Новые типы событий можно добавлять без перепроектирования всей системы.

Классификация вызовов модели по назначению

Журнал становится значительно полезнее, когда каждый запрос имеет метку назначения: repo_scan, plan, patch, debug, review, summarize, handoff. Без меток все затраты выглядят одинаково. С метками становится видно, что основная доля уходит на повторное сканирование репозитория, а ревью-вызовы дёшевы, но отлавливают большинство ошибок.

Схема PostgreSQL для старта

Автор предлагает компактную схему из двух таблиц:

• agent_sessions — метаданные сессии (ID, репозиторий, задача, статус, результат, PR-ссылка, временные метки, тир риска);
• agent_cost_events — поток событий с привязкой к сессии, типом, моделью, токенами, стоимостью, продолжительностью и JSON-метаданными.

Индексы по session_id, типу события и GIN-индекс по метаданным. Для небольшого продукта этого достаточно — саммари можно рассчитывать по запросу или сворачивать ночной джобой.

Обёртка над каждым вызовом модели

Не стоит полагаться на дисциплину разработчиков. Логирование должно быть встроено в SDK-обёртку или gateway модели. Каждый вызов проходит через функцию-обёртку, которая фиксирует токены, кеш, стоимость и продолжительность — автоматически, без возможности пропустить запись.

Эта обёртка становится «истинным источником» (source of truth). Промпты, маршруты моделей, ретраи, кеш-поведение — всё проходит через неё.

Алерты, которые не раздражают

Плохой алерт: «ИИ-расходы выросли на 12% сегодня». Хороший алерт: «Три сессии превысили нормальный диапазон стоимости для репозитория. У двух доля повторного ввода выше 70%. Одна ждала одобрения 94 минуты».

Полезные триггеры:

• стоимость сессии выше p95 для данного репозитория;
• доля повторного ввода выше 60%;
• больше трёх ретраев модели;
• ожидание одобрения дольше 30 минут;
• отсутствие верификации перед созданием PR;
• использование инструмента высокого риска без одобрения.

Каждый алерт должен указывать на конкретную сессию, а не на абстрактный график.

Как журнал влияет на продукт

Журнал затрат — не просто инструмент мониторинга. Он должен менять решения:

• Маршрутизация моделей. Если planning-вызовы дороги, но предотвращают плохие патчи — оставляем сильную модель. Если суммаризация дорога и низкорискова — маршрутизируем на дешёвую.
• Инженерия контекста. Высокая доля повторного ввода — сигнал уменьшать контекст, а не менять модель. Большие контекстные окна прячут потери, но не устраняют их.
• Бюджеты для тенантов. В мультитенантных продуктах привязка стоимости к workspace позволяет выстраивать fair-use политики и ценообразование без гаданий.
• Переписывание шаблонов. Если рабочий процесс регулярно проваливает верификацию — проблема в шаблоне задачи, а не в модели.
• Автоматизация. Лучшие кандидаты — не самые частые задачи, а те, где стоимость, процент успеха и верификация складываются в убедительную картину.

Приватность: журнал как чувствительное хранилище

Журнал может случайно стать хранилищем конфиденциальных данных. Автор рекомендует по умолчанию не хранить сырые промпты и полные сниппеты кода — вместо этого использовать ID версий промптов, хеши контекстных пакетов, пути к файлам вместо содержимого, обфусцированные входные данные инструментов и корот