Anthropic показала, как срезать счёт за Claude без потери качества

Anthropic 8 сентября опубликовала разбор того, где приложения на Claude переплачивают, и заявила, что во многих случаях счёт можно снизить без потери качества. Рычагов три: доля попаданий в кэш промптов, инструкции, написанные под старые модели, и уровень усилия (effort). Все три вынесены в скилл claude-api, который встроен в Claude Code, и у него появились три команды: /claude-api prompt-audit, /claude-api cost-optimize и /claude-api hillclimb.

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

Почему кэш промптов промахивается и как это увидеть?

Перед генерацией ответа модель прогоняет весь промпт в рабочее состояние, и этот этап, prefill, и есть дорогая часть обработки входа. Кэш промптов сохраняет это состояние (KV-кэш), и если следующий запрос начинается с того же префикса, модель читает его из кэша вместо пересчёта. Чтение из кэша тарифицируется в разы дешевле полной цены входных токенов: у Fable 5.1 это $0,25 за миллион против $10 за обычный вход.

Три условия, при которых кэш вообще работает: он привязан к конкретной модели, префикс должен совпадать байт в байт, и у него ограниченный срок жизни. Отсюда типичные промахи, которые Anthropic перечисляет по опыту клиентов: динамический таймстамп или идентификатор в системном промпте, описания инструментов, которые меняют порядок между вызовами, и смена уровня усилия посреди диалога, потому что effort рендерится в промпт перед вашим контентом и входит в кэшируемый префикс. Исключение сделано только для части моделей, включая Opus 5 и Fable 5.1: у них effort можно менять без сброса кэша. Отдельная ловушка у субагентов и веток диалога: они делят кэш родителя только при байт-идентичном префиксе, той же модели и том же effort.

Диагностика кэша в Claude Console показывает долю чтений из кэша и причины промахов: изменились сообщения, системный промпт, инструменты или модель. Изображение: Anthropic

Что с этим делать, по списку Anthropic. Смотреть долю попаданий в кэш в Claude Console и через API диагностики кэша: он показывает причину промаха и место, где два запроса разошлись. Редко используемые инструменты объявлять с defer_loading: они не входят в кэшируемый префикс и подгружаются в диалог только когда модель находит их через поиск инструментов. На моделях, которые это поддерживают, обновления системного промпта добавлять как сообщения посреди диалога, а не правкой самого системного промпта. Раскладывать запрос так, чтобы стабильная часть оставалась стабильной: сначала описания инструментов и системный промпт, потом растущий диалог.

Раскладка промпта по слоям кэширования на примере Claude Code. Изображение: Anthropic

Ещё несколько приёмов из той же статьи. Модель или effort менять в тот момент, когда кэш всё равно сброшен, например при компактификации диалога. Двигать точку кэширования по мере роста диалога: автоматическое кэширование ставит её на последний кэшируемый блок. Прогревать кэш заранее: запрос с max_tokens: 0 и явной точкой кэширования на том же effort, что и боевой трафик, обрабатывает промпт и записывает его в кэш, ничего не генерируя. Если отправить его, пока пользователь ещё печатает, первый настоящий запрос попадёт в тёплый кэш. И не выходить за срок жизни кэша: пятиминутный TTL считается с начала запроса, и если агент ждёт инструмент или субагента дольше пяти минут, кэш родителя истекает до возврата результата. На такие случаи есть часовой TTL на префикс.

Какие инструкции вредят новым моделям?

Промпты со временем обрастают правилами, которые латали слабости старых моделей, и после обновления модели эти правила начинают мешать. Anthropic перечисляет шесть антипаттернов. Ритуалы проверки: «перепроверь свою работу», «проверь дважды перед ответом» новые модели выполняют буквально и тратят токены впустую. Усилители вроде «будь максимально тщательным» и «КРИТИЧНО: ТЫ ДОЛЖЕН ВСЕГДА…» дают многословие и лишние вызовы инструментов. Обязательные процедуры и шаблоны рассуждений («думай по шагам в scratchpad») накладываются на встроенное мышление модели и жгут токены. Устаревшие примеры few-shot, подобранные под ошибки старой модели, учат новую имитировать длинные цепочки рассуждений там, где они не нужны. Противоречивые правила («всегда возвращай деньги по политике» против «никогда не возвращай без эскалации») новые модели соблюдают буквальнее, и качество падает. И устаревшая конфигурация: настройки под прошлое поколение, например ручные бюджеты на размышления, платформа с новыми моделями может отвергнуть.

Команда /claude-api prompt-audit ищет всё это в рабочей директории: в коде приложения, который вызывает Claude API, и в конфигурации самого Claude Code, включая CLAUDE.md и скиллы. Для проверки Anthropic взяла бенчмарк службы поддержки и переезд с Opus 4.8 на Opus 5: в чистый промпт по одному подсаживали антипаттерн (снятая настройка thinking, пара противоречивых правил о возвратах, ручной scratchpad, «проверь дважды», «будь максимально тщательным» и обязательная процедура из шести шагов), получили шесть «легаси» промптов и прогнали каждый на Opus 4.8, на Opus 5 с заменой только идентификатора модели и на Opus 5 после одного прогона prompt-audit.

Среднее по шести легаси-промптам на саппорт-бенчмарке: смена модели подняла точность и цену, аудит промпта снизил цену и поднял точность ещё. Изображение: Anthropic

В среднем аудит снизил стоимость на 14,6% и поднял точность на 5,3 пункта. Цена упала за счёт лишних вызовов инструментов и дублирующихся рассуждений: на Opus 5 «проверь дважды» превращалось в повторный поиск заказа при каждом возврате, а «будь максимально тщательным» в десятки ненужных обращений к базе знаний. Точность выросла по трём причинам. Снятая настройка thinking заставляла API отвергать каждый запрос на маршрутизацию. Из-за противоречивых правил Opus 5 придержал четыре возврата, которые был должен, и просил клиента подтвердить. А ручной scratchpad конфликтовал со встроенным мышлением Opus 5: в трёх тикетах модель написала вызов инструмента внутри рассуждений и не выполнила его.

Когда высокий effort не окупается?

Effort задаёт, насколько усердно модель работает: на low она быстрее приходит к выводу, на high дольше рассуждает, проверяет и перебирает альтернативы. Кривая цена-качество у одной и той же модели бывает очень разной. У Fable 5 на FrontierCode Diamond (50 самых сложных задач) low даёт 11,5% за $5,35 на задачу, max даёт 30,9% за $19,00: результат вырос примерно в 2,7 раза за примерно 3,5 раза по цене. А у Fable 5.1 на Humanity's Last Exam без инструментов кривая крутая, но с плоским последним шагом: около 53% на low за примерно $0,30 на вопрос и около 61% на max за $2,23, при этом шаг с xhigh до max добавляет около половины балла за 46% цены сверху. Этот прирост укладывается в разброс между прогонами бенчмарка, то есть переплата идёт ни за что.

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

CursorBench 3.2: пять уровней усилия Fable 5 и Fable 5.1, цена за задачу в логарифмической шкале. Изображение: Anthropic

Совет Anthropic звучит так: пробовать более сильную модель на низком усилии, потому что она может выйти дешевле слабой на высоком. На CursorBench 3.2 Fable 5.1 на low повторяет результат Fable 5 на high за треть цены. Дешевле по двум причинам: на low модель делает меньше работы на задачу, а чтение из кэша у Fable 5.1 стоит $0,25 за миллион токенов против $1,00 у Fable 5. Даже по ценам Fable 5 Fable 5.1 на low обошлась бы примерно на 40% дешевле. Второй совет: понять форму своей задачи, прогнав оценку по всем уровням усилия. Если на ненасыщенном бенчмарке кривая плоская, задача не упирается в вычисления на размышления, и поднимать effort бессмысленно.

Что делают команды hillclimb и cost-optimize?

/claude-api hillclimb автоматизирует этот перебор. Команда делит вашу оценку на обучающую и тестовую части, предлагает изменения конфигурации и читает проваленные примеры из обучающей части, чтобы починить найденное. На том же саппорт-бенчмарке старт был с Opus 4.8 на дефолтном high. Первым шагом hillclimb попробовал Opus 5 на low с prompt-audit, который убрал обязательные ритуалы вызова инструментов, шаги scratchpad и противоречивые правила: это превысило базовый уровень Opus 4.8 с 98,9% точности на обучающей части и снизило цену до 2,6 цента за тикет. Затем он спустился до Sonnet 5 на low: ещё дешевле, 1 цент за тикет, но точность упала до 88,9%. Прочитав проваленные тикеты, Claude добавил в промпт правила маршрутизации и сверку с лимитом на возврат, и Sonnet 5 вернулась к 98,9% при той же цене.

Четыре шага hillclimb на обучающей части саппорт-бенчмарка: точность решения и цена за тикет. Изображение: Anthropic

На 14 отложенных тикетах, которых поиск не видел, итоговая конфигурация набрала 90,5% против 78,6% у исходной, при цене примерно в пять раз ниже. Разрыв между 98,9% на обучающей части и 90,5% на тестовой стоит держать в уме: на отложенных примерах прирост заметно меньше.

/claude-api cost-optimize нужна для полного аудита расходов кода, который ходит в Claude API. Сначала она выясняет, куда уходят токены: из отчётов об использовании и затратах организации, если есть ключ Claude Admin API, из объекта usage в каждом ответе API, если приложение его логирует, а если нет ни того, ни другого, читает код сборки запросов и оценивает. Затем ранжирует доступную экономию: кэш промптов, урезание того, что несёт каждый запрос (включая prompt-audit), ограничение вывода и отправка неинтерактивной работы через Batch API. Если дать ей оценку качества, она ещё и считает цену и результат по уровням усилия и моделям.

cost-optimize на четырёх открытых бенчмарках с Sonnet 5 как базой: цена за прогон и изменение результата с 95% доверительными интервалами. Изображение: Anthropic

Anthropic прогнала её на четырёх открытых бенчмарках с Sonnet 5 как базой. На LegalBench команда предложила кэшировать общий префикс между задачами, поставить low и гнать задачи через Batch API: токены на размышления упали со 102 779 до 8 284, доля решённых осталась в пределах шума, цена снизилась примерно на 58%. На tau2-bench retail кэш с явной расстановкой точек кэширования дал минус 72% при той же доле решённых. На OfficeQA Pro пакетная обработка и кэширование документов снизили цену со $136,20 до $64,87. На SWE-bench Verified cost-optimize обнаружила, что кэш в дефолтной конфигурации уже настроен правильно, и экономию дали medium вместо high и ограничение вывода агента несколькими короткими фразами: медиана шагов на задачу упала с 29 до 17, входные токены с 75,2 млн до 33,7 млн, минус 55% по цене. По графику на SWE-bench результат при этом просел на 3,3 пункта при интервале от минус 9,6 до плюс 3,1, то есть значимого изменения не установлено, но интервал допускает и ухудшение, и на своих задачах это стоит перепроверить.

С чего начать?

Порядок, который предлагает сама Anthropic. Если вы переехали на новую модель Claude и хотите проверить старые промпты, запускайте /claude-api prompt-audit: она сканирует промпты, скиллы и описания инструментов в рабочей директории, будь то код приложения или конфигурация Claude Code. Если приложение ходит в Claude API и нужен аудит расходов, берите /claude-api cost-optimize: она профилирует расход токенов и проверяет рычаги по очереди, а с оценкой качества ещё и меряет компромиссы по effort и выбору модели. Если есть оценка и нужен поиск по цене и качеству, /claude-api hillclimb разобьёт её на обучающую и тестовую части, предложит изменения и оценит финальную конфигурацию на отложенных примерах.

Скилл claude-api встроен в Claude Code, отдельно он лежит на GitHub. Подробности по каждому рычагу собраны в документации и в кукбуке по снижению затрат. Все цифры в статье получены в прогонах Anthropic, в том числе на четырёх открытых бенчмарках; сторонних проверок в публикации нет. О том, на что способна Fable 5.1 в агентных сценариях, мы писали на примере агентов, собравших копию Юнион-сквер, а про открытый чертёж торгового агента на Claude есть отдельный разбор.

Источники: Claude Blog: Reducing cost and improving performance with Claude Platform, Анонс @ClaudeDevs в X, Документация: Optimizing for cost and intelligence, Скилл claude-api на GitHub, Cookbook: Cost optimization

Изображение на обложке: Anthropic, заставка статьи «Reducing cost and improving performance with Claude Platform»