Представьте исправление ошибки, которое меняет 12 строк. Агент изучает проект, составляет план, запускает вспомогательный процесс, выполняет тесты, читает сообщения об ошибках и пробует снова — и только после этого выдаёт исправление.
В счёт включён каждый запрос, который привёл к этому результату.
Из-за этого за короткую задачу неожиданно легко переплатить. Длинный разговор может переносить старые файлы в последующие запросы. Инструмент может возвращать целые страницы данных, хотя для следующего решения нужна всего одна запись. Несколько агентов могут повторять одно и то же расследование.
Эти расходы можно найти в истории выполнения. Начните с одной задачи, отслеживайте все затраты и проверьте, действительно ли результат проходит проверку. Затем измените ту часть, которая выполняет лишнюю работу.
1. Оцените стоимость завершённой задачи
Выберите задачу, которую выполняете регулярно: исправление описанной ошибки, подготовка исследовательской справки или проверка пакета клиентских записей. До запуска определите, что будет считаться завершением.
Для исправления ошибки критерии приёмки могут требовать тест, воспроизводящий исходный сбой, успешный результат после изменения и отсутствие сбоев в связанных интеграционных тестах. Сообщения «ошибка исправлена» для этого недостаточно.
Присвойте задаче идентификатор. Используйте его при повторах, работе вспомогательных агентов, проверке и фиксации конечного результата. Для каждого вызова модели записывайте отдельный идентификатор запроса, чтобы находить дубликаты в журналах.
Основной расчёт выглядит так:
Стоимость одной принятой задачи = общие записанные расходы / количество принятых задач
Учитывайте неудачные попытки. Если 10 задач обошлись в $8, а успешны только 4, стоимость одной принятой задачи составляет $2. Укажите рядом долю принятых задач — 40%. Если не принято ни одной задачи, укажите расходы и нулевое число принятых задач; отношение не определено.
Отдельно учитывайте время человека на исправления. Стоит видеть компромисс между рабочим процессом, который экономит $1 на оплате API, и 20 минутами на последующую обработку.
При работе с API сохраняйте ответ провайдера со сведениями об использовании, идентификатор модели, дату тарифов, расходы на инструменты, результат задачи и временные метки. Если после тайм-аута сведения об использовании отсутствуют, отметьте стоимость как неизвестную и сверьте её с данными провайдера. Отсутствие ответа не означает, что запрос был бесплатным. Если стоимость хотя бы одного запроса не рассчитана, укажите, что итог по пакету неполный.
Пользователи Claude Code могут начать с команд /usage и /context. Первая помогает проверить использование, вторая показывает, что занимает место в беседе. При подписке локальная оценка в долларах не является отдельным счётом, а окно контекста — это не то же самое, что лимит вашего тарифного плана.
2. Найдите контекст, который постоянно повторяется
Последнее сообщение — лишь часть запроса к модели. В Claude Code запросы также могут включать инструкции проекта, описания инструментов, историю беседы, содержимое файлов и результаты предыдущих вызовов инструментов.
Допустим, неизменённый документ объёмом 12,000 токенов попадает в 8 запросов. За эти вызовы на документ приходится 96,000 входных токенов. За подходящие для кэширования данные при чтении из кэша может взиматься меньшая плата. При этом документ всё равно может быть не нужен для некоторых решений.
Рассмотрите последовательность действий в рамках одной задачи. Какие файлы читались? Какие результаты остались в беседе? Какой запрос вызвал самый большой прирост? Продолжал ли агент использовать эти сведения к концу работы?
При ошибке в итоговой сумме счёта начните с входных данных, вызывающих сбой, расчёта, мест его вызова и соответствующих тестов. Пусть агент прослеживает ссылки по мере необходимости. Если заранее загрузить весь репозиторий, в каждом последующем ходе может передаваться материал, никак не повлиявший на исправление.
Храните все подтверждающие материалы на диске. Возвращайте краткий результат с путём к файлу и достаточными подробностями, чтобы можно было проверить оригинал. Для запуска теста укажите команду, код завершения, названия упавших тестов, относящуюся к делу ошибку и расположение журнала.
Если в кратком изложении пропущена единственная важная зацепка, это создаёт дополнительную работу. Сохраняйте точный текст ошибки, затронутый идентификатор и доказательства, необходимые для следующего действия.
3. Проверьте, приносит ли кэш пользу
Кэширование запросов повторно использует совпадающее начало запроса, если оно подходит для кэширования. Сначала размещайте стабильные инструкции, а после них — изменяющиеся данные задачи.
В пользовательском рабочем процессе с Claude API временная метка перед границей кэширования может создавать новую запись при каждом вызове. Размещайте границу после содержимого, которое повторяется. Сверьтесь с актуальной документацией по кэшированию для своей модели и структуры запроса.
Сравнивайте чтения и записи в кэш между запросами. Если записей много, а чтений мало, проверьте изменения префикса, минимальную длину для кэширования, срок хранения и временные интервалы.
Чтение из кэша всё равно стоит денег. Большое число чтений может означать, что кэширование работает; также проверьте, помогает ли этот контекст завершить задачу.
В Claude Code обычные субагенты используют собственный контекст и кэширование. Форк работает иначе. Уплотнение контекста тоже использует запрос к модели и заново формирует контекст беседы. Не запускайте уплотнение вручную каждые несколько минут, не измерив результат.
4. Сократите объём данных, возвращаемых инструментами
Ответ инструмента может стать входными данными для последующих вызовов модели. Поэтому большой ответ может повлиять не только на запрос, который изначально получил эти данные.
Возьмём ежедневный отчёт по заказам. Инструмент получает все заказы, модель читает каждую строку, а следующий запрос просит её подсчитать итоги. Скрипт может отфильтровать записи, подсчитать итоги и вернуть исключения, требующие оценки.
Так меняется то, что поступает в модель. Кроме того, расчёт можно независимо протестировать.
Применяйте тот же подход к журналам, таблицам и результатам поиска. Прежде чем возвращать данные, отфильтруйте их по нужному клиенту, дате, ошибке или типу записи. Укажите применённый фильтр, количество обработанных записей, было ли усечение, а также путь или идентификатор исходных данных.
Проверяйте пагинацию. Если обработать только первую страницу и выдать её за весь набор данных, вы получите более дешёвый, но неверный ответ.
Промежуточные результаты могут оставаться в среде выполнения, а в модель можно передавать только выбранные данные. Этот принцип можно применить в небольшом локальном скрипте, не создавая сложную систему агентов.
При загрузке описания инструментов тоже занимают место в контексте. Некоторые клиенты уже откладывают загрузку полных описаний до момента, когда они понадобятся. Прежде чем удалять интеграции, изучите свою конфигурацию: одно лишь количество подключений ничего не говорит об их расходе токенов.
5. Сохраните процедуру, когда разберётесь в ней
Обращайте внимание на задачи, в которых агент снова и снова ищет одни и те же команды, переписывает один и тот же план или каждый раз с нуля решает, какие тесты запускать.
Когда процедура станет понятна, сохраните её. Запишите проектные инструкции в коротком руководстве, которое можно использовать повторно. Фиксированные расчёты, преобразования файлов и последовательности команд оформите в проверенный скрипт.
Для ошибки в расчёте счёта скрипт может подготовить тестовые данные, выполнить расчёт, сравнить результат с ожидаемым и сообщить итог. Агенту по-прежнему нужно диагностировать неожиданное расхождение и выбрать правильное исправление. Но ему не нужно каждый раз заново придумывать команду для запуска теста.
Указывайте предположения, на которых основана процедура. Запишите необходимые зависимости, ожидаемые входные данные и условия, при которых выполнение должно остановиться. Если среда изменится, явный сбой диагностировать проще, чем правдоподобное сообщение об успехе.
Повторяющиеся проверки статуса требуют такого же подхода. Если сервис предоставляет идентификатор задания, используйте событие о его завершении или функцию опроса с ограничением по времени. Обращайтесь к модели, когда задание завершится, завершится с ошибкой или превысит установленный срок.
При действиях, которые что-то создают или отправляют, к повторам нужно подходить особенно осторожно. Прежде чем повторять попытку, проверьте, не завершилась ли успешно первая. Если это поддерживается, повторное использование ключа идемпотентности поможет не допустить, чтобы после неопределённого ответа появились два заказа или два сообщения.
6. Дайте каждому агенту отдельную задачу
Параллельная работа агентов может сократить общее время выполнения. Но их вызовы, контекст и координация тоже увеличивают общие расходы.
Распределяйте работу, если задачи независимы, а результаты легко объединить. Один агент может воспроизвести описанную ошибку, а другой — проверить контракт затронутого интерфейса. Сформулируйте для каждого конкретный вопрос и ожидаемый результат.
Не поручайте нескольким помощникам одну и ту же широкую задачу — проверить всё подряд. В результате они могут провести одно и то же расследование, а затем потребуется ещё один проход, чтобы свести их выводы.
В полезной передаче задачи указаны сама задача, нужные файлы, допустимые изменения, ожидаемый результат и условие остановки. Запросите пути к подтверждающим материалам и выводы, нужные для следующего шага. Подробные промежуточные результаты оставьте в файлах помощника.
Продуманно распределяйте проверки. Во время реализации запускайте целевые проверки, а затем выполните необходимые более широкие проверки для объединённого результата. Повторяйте проверку, если код изменился, предыдущий запуск завершился с ошибкой или появились новые основания. Записывайте причину каждого запуска.
Измеряйте изменения модели отдельно от изменений рабочего процесса. При тестировании другой модели или настройки рассуждений используйте тот же набор задач и те же критерии приёмки. Учитывайте повторы и время на исправления. Более низкая цена одного вызова полезна только в том случае, если вся работа остаётся оправданной.
7. Правильно интерпретируйте поля сведений об использовании
Разные провайдеры по-разному учитывают кэшированный ввод. Если применить формулу одного провайдера к журналам другого, можно получить убедительный, но неверный счёт.
В стандартном ответе Claude Messages поля input_tokens, cache_creation_input_tokens и cache_read_input_tokens обозначают отдельные категории входных токенов. Создание кэша также может разбиваться по сроку хранения. Применяйте тариф для каждой соответствующей категории.
В текущей схеме OpenAI Responses кэшированный ввод и применимые счётчики записи в кэш входят в общий объём ввода. Перед расчётом стоимости обычного ввода их нужно вычесть в соответствии с документацией. Используйте формулу провайдера для конкретной модели и API, к которым обращаетесь.
Храните исходный ответ со сведениями об использовании рядом с нормализованной записью. Так вы сможете исправить расчёт при смене провайдера, модели или тарифов.
Некоторые функции также создают дополнительную оплачиваемую нагрузку. При уплотнении контекста через Claude API итоговые счётчики ввода и вывода верхнего уровня не включают итерацию уплотнения. Один раз рассчитайте стоимость записей в usage.iterations, используя поля usage каждой записи. Не прибавляйте итоговые счётчики верхнего уровня повторно.
Выполнение инструментов, поиск, хостинг и хранение данных могут оплачиваться отдельно. Если такие расходы не включены, указывайте, что сумма отражает стоимость модели. Для потоковых запросов используйте итоговые сведения об использовании после завершения, если они доступны, и не учитывайте накопительные обновления многократно.
8. Разберите один пакет задач
Ниже приведён примерный расчёт, который можно воспроизвести. Число запросов, объёмы токенов, расходы на инструменты и результаты — вымышленные. Для их получения агент не запускался.
В примере нужно извлечь по три значения и подтверждающие их фрагменты из каждого из четырёх документов. Результат считается успешным, только если корректны JSON, значения и подтверждающие источники.
В обоих сценариях предполагаются три принятых результата, одна отклонённая попытка, требующая повтора, и одна задача, которая в итоге завершается неудачей. Это пять попыток для четырёх задач. Каждая попытка учитывается в расходах.
В первом сценарии — 15 запросов к модели: 375,000 некэшированных входных токенов и 15,000 выходных токенов. По стандартным тарифам Claude Haiku 4.5, проверенным 7 сентября 2026 года, миллион входных токенов стоит $1, а миллион выходных — $5. Стоимость модели составляет $0.45. Добавьте $0.06 вымышленных расходов на внешние инструменты — итого $0.51.
Разделите $0.51 на три принятых результата: $0.17 за каждый принятый результат.
Во втором сценарии предполагаются 10 запросов с меньшим объёмом новых входных данных и некоторым объёмом кэшированных данных. Расходы на модель распределяются так:
• 55,000 некэшированных входных токенов по $1 за миллион: $0.055.
• 25,000 токенов записи в кэш со сроком хранения пять минут по $1.25 за миллион: $0.03125.
• 25,000 токенов записи в кэш со сроком хранения один час по $2 за миллион: $0.05.
• 50,000 токенов чтения из кэша по $0.10 за миллион: $0.005.
• 7,500 выходных токенов по $5 за миллион: $0.0375.
Итого расходы на модель составляют $0.17875. Добавьте $0.05 вымышленных расходов на внешние инструменты: $0.22875 за все попытки, или $0.07625 за каждый принятый результат. Разные сроки хранения в кэше демонстрируют категории учёта, а не рекомендуемую конфигурацию.
Эти цифры показывают стоимость указанного объёма использования. Они не доказывают, что сокращение контекста или изменение границы кэширования даст такие же показатели или сохранит качество. Для реального сравнения нужны записанные запросы и результаты, проверенные независимо. Неудачные задачи тоже нужно учитывать в общей сумме.
9. Проверьте это на собственном рабочем процессе
Выберите небольшой набор типичных задач и не меняйте их входные данные. Включите обычную успешную задачу, сложный случай и задачу, которая уже завершалась неудачей. Прежде чем вносить изменения, сформулируйте критерии приёмки.
Запустите текущий рабочий процесс и сохраните записи запросов. Отметьте, где в беседу попали ненужные данные, процедура была построена заново, проверка повторилась или неизменённая ошибка вызвала ещё одну попытку.
Измените один механизм. Отфильтруйте большой результат инструмента. Сохраните часто используемую последовательность команд. Исправьте границу кэширования. Сузьте задачу одного помощника. Для этого сравнения не меняйте модель и критерии приёмки.
Повторно запустите те же входные данные в чистой тестовой среде. Разделяйте первые запуски и запуски с уже прогретым кэшем. Повторите запуск достаточное число раз, чтобы понять, стабилен ли результат, и включайте неудачные попытки в общие показатели.
Используйте этот запрос с агентом для программирования, у которого есть доступ к вашей реализации и журналам:
Изучи этот рабочий процесс и доступные журналы выполнения.
Определи границы задачи и критерии приёмки. Проследи вызовы основного агента и помощников, повторы, проверки и конечный результат.
Создай локальный отчёт, в котором указаны записанные расходы на модель, отдельные расходы на инструменты, отсутствующие сведения об использовании, принятые и неудачные задачи, затраченное время и участие человека. Используй актуальные поля учёта конкретного провайдера и тарифы с датой. Сохраняй исходные ответы со сведениями об использовании. Удаляй дубликаты по идентификаторам запросов.
Определи самую крупную предотвратимую статью расходов, подтверждаемую журналами. Укажи конкретные вызовы и объясни, почему эта работа была лишней. Не смешивай оценки с записанными суммами.
Предложи одно изменение и способ сравнения на тех же входных данных, с той же моделью и критериями приёмки. Раздели первые запуски и запуски с прогретым кэшем. Если необходимых подтверждений нет, остановись и точно укажи, чего не хватает.
Во время этой проверки не выполняй платные вызовы API и не меняй рабочий процесс в эксплуатации. Сохрани отчёт и предлагаемый патч для проверки.
Именно критерии приёмки делают сравнение достоверным. Если фильтрация журнала скрывает сбой или меньшей модели требуются повторные исправления, зафиксируй это и пересмотри изменение.
Здесь я пишу о практическом применении ИИ в рабочих процессах. Подписывайтесь — скоро выйдет следующий материал.