Один прогон сверки документации с кодом запустил 85 агентов и стоил бы около $26 по прайсу API. Все 85 работали на самой дорогой модели, хотя её никто не выбирал: в скрипте модель не была указана, и агенты взяли модель сессии. Я разобрал журналы этого и ещё трёх прогонов, чтобы понять, куда уходит расход токенов Claude Code в workflow. Ответы модели почти ничего не стоят. Деньги уходят на то, что каждый агент снова и снова читает свой контекст.
Это вторая статья про workflow. Что это за режим, как его запускать и какие у него лимиты, я разбирал в первой статье про Claude Code workflow. Здесь только цифры и то, что я поменял в своих скриптах после замера.
Главное:
- Ответы модели — около 2 % стоимости прогона. От 65 до 84 % уходит на запись контекста в кэш.
- Самый дорогой этап — перепроверка находок: от 50 до 78 % прогона.
- Модель, которую никто не выбирал, оказалась главной статьёй расходов. После того как я назначил модель каждой роли, ревью коммита подешевело с $3,20 до $1,23.
- Повторный запуск без новых коммитов теперь стоит меньше цента: один маленький агент сверяет состояние и выходит.
- Экономию без эталонного набора задач честно не измерить. Его у меня пока нет, и это главный открытый пункт.
Как я считал#
У каждого агента workflow есть журнал: ~/.claude/projects/<проект>/<сессия>/subagents/workflows/wf_*/agent-*.jsonl. В каждой записи ответа модели лежит поле message.usage: входные токены, чтение кэша, запись кэша, выход. Я сложил их по этапам и умножил на прайс API на 6 ноября 2026 года:
| Модель | Вход | Запись кэша, 5 мин | Чтение кэша | Выход |
|---|---|---|---|---|
| Opus 5.5 | $4 | $5 | $0,20 | $20 |
| Sonnet 5.5 | $2 | $2,50 | $0,10 | $10 |
| Haiku 5.5, промпт до 100 тыс. | $0,10 | $0,125 | $0,01 | $0,50 |
Цены за миллион токенов. На подписке деньги за прогон не списываются, но те же токены расходуют лимиты плана, так что пропорции те же.
Одна оговорка. Выходных токенов в журналах подозрительно мало, 30–100 на запрос: похоже, размышления модели туда не попадают. Поэтому доля выхода — нижняя оценка. Вывод это не меняет: даже если умножить выход на десять, он останется меньше 20 % стоимости.
Куда уходит расход токенов Claude Code#
Четыре прогона на одной ветке, все агенты на Opus 5.5:
| Прогон | Агентов | Запросов | ≈ $ | Перепроверка, доля |
|---|---|---|---|---|
| Ревью всей ветки, 60 файлов | 58 | 379 | 14,2 | 66 % |
| Ревью одного коммита, 4 файла | 10 | 57 | 3,2 | 50 % |
| Сверка документации с кодом и правка страниц | 85 | 349 | 26,1 | 78 % |
| Сборка и тесты до зелёного | 1 | — | ≈ 0,1 | — |
Механика простая. Агент стартует с контекстом около 50 тыс. токенов: системный промпт, инструменты, CLAUDE.md, память, задача. Только CLAUDE.md и память дают 11–13 тыс. токенов до первой строки задачи. Затем агент делает 5–8 запросов, и каждый запрос несёт весь накопленный контекст вместе с результатами инструментов. Итог примерно такой: агенты × запросы на агента × размер контекста × цена модели. Каждый из четырёх множителей можно уменьшить.
Кэш спасает не всегда. Чтение кэша у Opus 5.5 стоит $0,20, запись — $5, в 25 раз дороже. В ревью проверяющие читали общий префикс из кэша соседа: медиана записи на первом запросе — ноль. В сверке документации каждый из 76 проверяющих записывал свой префикс заново, по 32 тыс. токенов. Это примерно $12 из $26 только на то, чтобы положить в кэш одно и то же 76 раз.
Почему там кэш не делился, я так и не выяснил. По документации workflow агенты читают кэш друг друга, только если у них совпадают модель, уровень усилия, тип агента, инструменты, схема ответа и рабочая папка. Кэш агента workflow живёт пять минут даже на подписке.
Перепроверка: дорого и часто впустую#
Схема «один агент нашёл, другой пытается опровергнуть» — лучшее, что есть в workflow. Но она же съедает больше всего. На каждую находку запускается отдельный проверяющий со своим контекстом.
В сверке документации проверяющие опровергли 36 из 76 расхождений, 47 %. Почти половина денег этапа ушла на то, чтобы отсеять расхождения, которых не было. Стоимость одной подтверждённой находки во всех прогонах вышла одинаковой, $0,9–1,2.
Отсюда вывод, который сначала кажется странным: дешевле сделать строже поиск, чем держать больше проверяющих. Если поисковик обязан привести дословную цитату страницы и строку кода, которую он прочитал, мнимых расхождений становится меньше ещё до проверки.
Внешние работы говорят то же. В препринте Refute-or-Promote десять ревьюеров единогласно подтвердили уязвимость в OpenSSL, которой не существовало, и убил её один эмпирический тест. Контролируемого сравнения там нет, это один случай. Но урок понятный: десять согласных агентов ещё не факт. В CodeX-Verify каждый следующий проверяющий давал меньше предыдущего: +14,9, затем +13,5 и +11,2 процентного пункта точности.
Что я поменял в скриптах#
Пять правок. Каждая бьёт по одному из множителей.
Модель у каждого агента явно. По документации агент без указанной модели работает на модели сессии. Теперь в начале каждого скрипта лежит таблица, и её можно переопределить при запуске:
const M = {
scope: 'haiku',
find: A.thorough ? 'opus' : 'sonnet',
verify: A.thorough ? 'opus' : 'sonnet',
state: 'haiku',
...(A.models || {}),
}Haiku 5.5 пишет кэш за $0,125 против $5 у Opus, в 40 раз дешевле. Ему достаются разведка (какие файлы изменились) и запись состояния. Поиск и проверка идут на Sonnet. Opus остаётся для релизного прогона и для одного исключения: в аудите стороннего кода я оставил его на чтении install-скриптов, потому что пропущенный вредоносный хук стоит дороже любых токенов. Механике и проверке мелких находок я дал effort: 'low'.
Дубли сливаются до проверки. Три ревьюера часто находят одну ошибку с разных сторон. Если файл тот же и строки отличаются не больше чем на три, находка проверяется один раз. Мелкие находки сверх лимита не проверяются и уходят в отдельный список с записью в лог, чтобы урезание не было тихим.
Проверяющий обязан принести факт. Вызов, условие выше по стеку, вывод команды, дословная цитата. Нет факта — находка отклонена:
`Keep a finding only with evidence — what you found and where ` +
`(file:line or command output). No evidence → reject.`Три голоса остались только для серьёзных находок в релизном прогоне.
Проверять только новое. Ревью сохраняет последний проверенный коммит в файл внутри .git (git rev-parse --git-path change-review-state.json), так что в коммит он не попадает. Следующий запуск смотрит lastReviewedSha..HEAD и переносит открытые находки по нетронутым файлам. Полный прогон делается перед pull request, после rebase и после смены промптов: для этого в скрипте есть номер версии промптов. Так работают инкрементальные ревью у CodeRabbit и выбор затронутых тестов в CI.
Полный прогон я не отменил, и у этого есть причина. Самую серьёзную ошибку дня нашёл именно он: она связывала клиент, сервис и настройки в трёх разных файлах. Инкрементальный проход по одному файлу её бы не увидел.
Ранний выход. Если с прошлого прогона ничего не изменилось, после разведки скрипт сразу возвращает результат и не запускает ни одного ревьюера.
Результат на том же репозитории:
| Прогон | Агентов | Запросов | Модели | ≈ $ |
|---|---|---|---|---|
| Ревью коммита, старый скрипт | 10 | 57 | Opus | 3,20 |
| Ревью коммита, новый скрипт | 10 | 40 | Haiku + Sonnet | 1,23 |
| Тот же, повтор без новых коммитов | 1 | 2 | Haiku | < 0,01 |
Сравнение качества здесь нестрогое. Старый скрипт смотрел коммит до правок по ревью, новый — после, и находки у них разные: три подтверждённые против двух. Цена сравнима, потому что объём тот же: 4–6 файлов, 10 агентов.
Ещё одна правка касается не денег, а цикла «проверка → правка». В моём скрипте переводов фикс-агент вносил правки последним, и их никто не перечитывал. Теперь после правки идёт короткая перепроверка на Sonnet с effort: 'low'. Цикл должен кончаться проверкой, иначе последние изменения уходят в коммит непрочитанными.
Чего я ещё не проверил#
- Эталонного набора нет. Нужны 30–50 прошлых pull request с известными ошибками и несколько намеренно внесённых ошибок. Без этого я не могу сказать, сколько тонких находок Sonnet пропускает по сравнению с Opus.
- Почему не делился кэш в сверке документации, неясно. Это до $12 на прогон.
- Общие правила на 11–13 тыс. токенов по-прежнему грузятся в каждого агента:
CLAUDE.mdна 21 КБ и память. Документация по стоимости советует держатьCLAUDE.mdкороче 200 строк и выносить специальные правила в скилы, которые грузятся по требованию. Я этого пока не сделал. - Все оценки экономии, кроме замера ревью, — расчёт, а не измерение.
Отдельно о сверке документации. Её главная беда — проверять каждую страницу целиком при каждом прогоне. Следующий шаг — сверять только страницы, привязанные к изменённым файлам. Как привязать страницу к коду так, чтобы она сама знала, что устарела, я описывал в статье про якоря документации в коде.
Если у вас уже есть сохранённые workflow, начните с одной команды: grep -n "agent(" ~/.claude/workflows/*.js. Каждый вызов в её выводе, где в опциях нет model, скорее всего работает на модели вашей сессии.
