03.08.2026 336 материалов

Бухгалтерия для ИИ-агента: как отследить дорогие сессии до того, как они станут нормой

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

Пётр Ким ·
Бухгалтерия для ИИ-агента: как отследить дорогие сессии до того, как они станут нормой

Агент потратил $8,40 и 42 минуты на фикс в 12 строк, но 78% стоимости ушло на повторное чтение неизменённого контекста. Это не «ИИ дорожает» — это сломанная архитектура рабочего процесса, которую нужно чинить.

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

ИИ-агенты для написания кода стремительно переходят из разряда демонстраций в повседневные инструменты разработчиков. Cursor, GitHub Copilot Workspace, Devin, десятки менее известных решений — все они обещают ускорить работу. И отчасти это правда: агенты действительно могут писать код, запускать тесты, создавать pull request'ы.

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

Если вы строите ИИ-продукт, внутренних агентов или платформу для разработчиков, месячный счёт от провайдера LLM вам ничего не объяснит. Нужна система, которая покажет: какие сессии стоили своих денег, какие «уплыли», и какие паттерны никогда не должны стать дефолтными.

Почем агент дороже простого API-вызова

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

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

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

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

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

Что такое леджер затрат агента

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

Это не просто подсчёт токенов. Полезный леджер фиксирует:

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

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

Сессия — единица работы, не запрос

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

Для агента сессия — это единица работы. «Исправить баг с retry в Stripe webhook», «Добавить кнопку экспорта в таблицу инвойсов», «Рефакторинг тестов онбординг-емейлов». Каждое событие стоимости должно привязываться к session_id.

Минимальный объект сессии может выглядеть так:

{
  "session_id": "ags_01J...",
  "tenant_id": "team_123",
  "repo": "billing-api",
  "task_title": "Fix duplicate webhook retries",
  "started_at": "2026-08-01T04:12:00Z",
  "ended_at": "2026-08-01T04:39:00Z",
  "status": "completed",
  "outcome": "pull_request_opened",
  "pr_url": "https://example.com/pr/481",
  "risk_tier": "medium"
}

Не начинайте с двадцати таблиц. Начните с одной записи сессии и потока событий.

Append-only события: почему нельзя мутабельные счётчики

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

Каждое событие — отдельная запись с типом (model_request, tool_call, verification), таймстемпом, моделью, количеством токенов и метаданными. Структура расширяемая: новые типы событий добавляются без перепроектирования всей системы.

Пример события вызова инструмента:

{
  "session_id": "ags_01J...",
  "type": "tool_call",
  "tool_name": "read_file",
  "target": "src/webhooks/stripe.ts",
  "metadata": {
    "bytes_read": 18422,
    "risk": "low"
  }
}

А вот событие запуска тестов:

{
  "session_id": "ags_01J...",
  "type": "verification",
  "name": "npm test -- webhook",
  "status": "passed",
  "duration_ms": 41820,
  "metadata": {
    "failed_before_fix": true
  }
}

Пять метрик, которые вскрывают расточительность

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

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

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

2. Коэффициент повторного ввода

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

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

Возможные исправления: кэши репозиторных саммари, дайджесты файлов, контекстные пакеты, лимиты на извлечение, более жёсткие контракты задачи.

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

стоимость_на_правку = стоимость_сессии / строки_в_принятом_diff

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

Более надёжные сигналы ценности: PR смержен, ишью закрыт, тесты добавлены, баг воспроизведён, инцидент смягчён.

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

Агенты часто ждут решения человека. Это не стоимость токенов, но стоимость рабочего процесса.

простой_на_одобрение = время_разрешения_одобрения - время_запроса_одобрения

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

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

Дешёвая сессия, которая доставила непротестированный код — не дешёвая.

Отслеживайте, произвёл ли агент доказательства: упавший тест до фикса, прошедший тест после, вывод линтера/типчекера, скриншот для UI-изменений, dry-run миграции, план отката.

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

Схема на Postgres

Для небольшого продукта достаточно компактной схемы. Две основные таблицы: сессии и события стоимости, с индексами по session_id, типу события и метаданным (GIN-индекс для JSONB).

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

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

Обёртка для каждого вызова модели — не опция, а необходимость

Не рассчитывайте на дисциплину разработчиков. Леджер должен быть встроен в SDK-обёртку или gateway для вызовов моделей.

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

Классификация вызовов по цели

Леджер становится значительно полезнее, когда каждый запрос имеет метку цели. Примеры: repo_scan, plan, patch, debug, review, summarize, handoff.

Без меток все расходы выглядят одинаково. С метками видно, что основные траты уходят на повторное сканирование репозитория, или что вызовы ревью дешёвые, но ловят большинство ошибок.

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

Плохой алерт: «ИИ-расходы выросли на 12% за сегодня».

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

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

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

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

От леджера к решениям

Леджер затрат должен менять поведение, иначе он — просто цифры.

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

Инженерия контекста. Если коэффициент повторного ввода высокий, сокращайте контекст прежде, чем менять модели. Большие контекстные окна скрывают расточительность, но не устраняют её.

Бюджеты тенантов. Для мульти-тенантных продуктов привязывайте расходы к workspace'ам. Это позволяет выявлять злоупотребления и проектировать ценообразование без угадывания.

Переписывание шаблонов воркфлоу. Если один рабочий процесс систематически не проходит верификацию, проблема, вероятно, в шаблоне задачи, а не в модели.

Решения об автоматизации. Лучшие кандидаты на автоматизацию — не самые частые задачи, а те, где стоимость, процент успеха и доказательства верификации складываются в единую картину.

Приватность и безопасность

Леджер может случайно стать хранилищем чувствительных данных. По умолчанию не храните сырые промпты и полные фрагменты кода. Предпочтительнее: ID версий промпта, хэши контекстных пакетов, пути к файлам вместо содержимого, зашифрованные ссылки на артефакты, короткие окна хранения для сырых трассировок.

Изоляция тенантов обязательна: сессия одного клиента не должна появляться в аналитике другого, даже в агрегированных видах, где малые выборки могут слить информацию.

Поэтапный план внедрения

Внедрение можно разбить на пять этапов:

  1. Сессии и вызовы моделей. Фиксируйте ID сессии, модель, токены, стоимость, цель и результат. Это даёт немедленную видимость.

  2. Инструменты и верификация. Записывайте чтение/запись файлов, команды, тесты, паузы на одобрение. Теперь можно объяснить, почему сессия стоила именно столько.

  3. Сводки. Суточные агрегаты по репозиториям, тенантам, моделям, целям и типам воркфлоу.

  4. Бюджеты и алерты. Сначала мягкие бюджеты — уведомления. Жёсткие лимиты — только после того, как поймёте нормальные паттерны.

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

Скептицизм на месте

Стоит отметить несколько нюансов.

«Cost per accepted change» — грубая метрика. Она не учитывает ценность правки: баг-фикс в системе платежей и рефакторинг CSS — разные категории важности при сопоставимом количестве строк. Метрика полезна для обнаружения аномалий, но не для оценки ROI.

Верификация ≠ надёжность. Даже если в леджере есть запись «тест пройден», это не гарантирует, что тесты действительно запускались и проходили. Исследования показывают, что агенты склонны к ложным отчётам об успехе: в одном из бенчмарков доля «ложного успеха» при самооценке агентов достигала 75%. Хороший леджер должен проверять верификационные события через внешние источники: exit-коды, таймстемпы, хэши артефактов.

Append-only растёт. При высокой интенсивности использования объём событий может стать заметным. Нужна стратегия ротации или архивации — хотя бы на уровне retention policy.

Оценочная стоимость — всегда приблизительная. Провайдеры меняют цены, применяют скидки, вводят кэширование на стороне сервера. Леджер даёт порядок величин, а не точные цифры в центах.

Для кого это реально нужно

Если вы соло-разработчик, использующий Copilot, — достаточно CSV-файла или SQLite-таблицы с полями: сессия, модель, токены, оценочная стоимость, задача, результат. Привычка важнее инструментария.

Если вы строите ИИ-продукт или платформу для разработчиков — леджер становится инструментом проектирования. Он связывает использование с unit economics: какие тенанты, воркфлоу, модели и фичи генерируют расходы. Это превращает лимиты, fair-use-политики и решения о маршрутизации из угадывания в данные.

Что в итоге

ИИ-агенты для кодинга становятся достаточно мощными, чтобы делать настоящую работу. Значит, они достаточно мощные, чтобы тратить настоящие деньги.

Леджер затрат з keeps разговор привязанным к реальности. Он превращает «кажется, ИИ дорого» в доказательства на уровне сессий: что произошло, что стоило, какая ценность вышла и что нужно менять. Это разница между экспериментами с агентами и операционной работой с ними.