Снижение затрат и повышение производительности с помощью Claude Platform

Настройка кэширования промптов, инструкций и уровня усилий может снизить стоимость Claude без ущерба для производительности приложения.

Производительность и стоимость часто рассматриваются как компромисс: чтобы тратить меньше, вы соглашаетесь на худшие результаты. На практике мы обнаружили, что многие приложения, использующие Claude Platform, могут сократить расходы без потери производительности с помощью трех исправлений: максимизировать показатель попаданий в кэш промптов, удалить антипаттерны из ваших промптов при переходе на передовые модели Claude и откалибровать уровень усилий под задачу. Мы включили эти рекомендации в навык claude-api. В этой статье мы показываем, как Claude Code с навыком claude-api часто может найти способы снизить затраты, сохраняя или улучшая производительность.

Кэш промптов

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

Есть несколько практических соображений для эффективного использования кэша промптов. Во-первых, кэш промптов привязан к конкретной модели. Во-вторых, чтения из кэша промптов должны быть побайтно точными по всему префиксу. Наконец, кэш промптов имеет ограниченное время жизни (TTL).

Учитывая эти моменты, вот несколько практических советов:

• Будьте осторожны при изменении настройки усилий в середине разговора. Эти настройки отображаются в промпт перед вашим контентом, поэтому они являются частью кэшированного префикса. Только с отдельными моделями Claude, включая Opus 5 и Fable 5.1, вы можете обновить уровень усилий в середине разговора без нарушения кэша.
• Держите изменчивые значения вне префикса. Динамическая временная метка или ID в системном промпте могут меняться между вызовами модели и нарушать кэш.
• Избегайте определений инструментов, которые меняют свой порядок. При использовании Claude messages API промпт собирается в фиксированном порядке, причем определения инструментов отображаются вверху. Любое изменение определения инструмента нарушит кэш.
• Будьте осторожны при разветвлении разговоров. Саб-агенты и ветки разделяют кэш родителя только тогда, когда префикс ветки побайтно идентичен, на той же модели и с тем же уровнем усилий.

Как это исправить

Мы накопили несколько уроков по управлению кэшем промптов:

• Внимательно отслеживайте показатель попаданий в кэш промптов. Claude Console и API диагностики кэша предоставляют диагностику кэша промптов, включая причины промахов кэша (Рисунок 1) и точное место, где два запроса разошлись.

• Откладывайте редко используемые инструменты. Объявите все свои инструменты заранее, но пометьте редко используемые как defer_loading: они остаются вне кэшированного префикса и добавляются в разговор только тогда, когда Claude ищет их с помощью поиска инструментов, таким образом кэш сохраняется.
• Применяйте обновления системного промпта как сообщения. Некоторые модели Claude позволяют добавить системную инструкцию как сообщение в середине разговора вместо редактирования системного промпта, что сохраняет кэш.
• Структурируйте запрос так, чтобы стабильная часть оставалась стабильной. Сначала добавляйте статический контекст (определения инструментов и системный промпт), а затем растущий разговор за ними (Рисунок 2).

• Вносите изменения в модель или уровень усилий, когда кэш промптов уже будет нарушен. Некоторые операции, такие как компактизация, уже перезаписывают большую часть кэша (разговор). Это хороший момент для смены модели или уровня усилий, так как вы все равно платите за промах.
• Перемещайте точку разрыва кэша по мере роста разговора. С Claude Platform вы можете установить автоматическое кэширование, чтобы применить точку разрыва кэша к последнему кэшируемому блоку.
• Предварительно прогревайте кэш. Чтобы уменьшить задержку, отправьте запрос с max_tokens: 0 и явной точкой разрыва кэша, используя ту же настройку усилий, что и для вашего реального трафика. Это обработает промпт и запишет его в кэш без генерации чего-либо. Если вы запустите его в начале сессии (например, пока пользователь печатает), первый реальный запрос попадет в теплый кэш.
• Не превышайте TTL кэша промптов. 5-минутный TTL кэша отсчитывается от начала запроса. Если агент блокируется на вызовах инструментов или запросах к саб-агентам, которые выполняются дольше 5 минут, кэш родителя истекает до того, как вернется результат. В таких случаях рассмотрите установку 1-часового TTL для префикса.

Инструкции

Промпты могут накапливать инструкции, которые исправляют слабые места модели. Эти инструкции могут дрейфовать относительно возможностей новейших моделей Claude. Вот распространенные «антипаттерны» промптинга, которые сковывают передовые модели Claude и могут непреднамеренно увеличивать затраты:

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

Как это исправить

Мы обновили навык claude-api новой командой, которая отслеживает эти антипаттерны. В Claude Code запустите /claude-api prompt-audit для ваших промптов, навыков или описаний инструментов. Аудит охватывает все в вашей рабочей директории, включая код приложения, который вызывает Claude API, и собственную конфигурацию Claude Code (например, CLAUDE.md или навыки).

Например, мы протестировали миграцию модели с Opus 4.8 на Opus 5 на бенчмарке поддержки клиентов. Мы начали с чистого промпта и добавляли по одному антипаттерну за раз (устаревшая настройка мышления, пара противоречивых правил возврата, ручной черновик, "проверь дважды", "будь максимально тщательным" и обязательная шестишаговая процедура), получив шесть устаревших промптов.

Мы запустили каждый на Opus 4.8, на Opus 5 только с измененным ID модели и на Opus 5 после однократного запуска /claude-api prompt-audit для каждого промпта (Рисунок 3 показывает среднее по шести).

С Opus 5 ритуалы проверки ("проверь дважды") используют ненужные токены, дублируя поиск заказа при каждом возврате. Усилители акцента ("будь максимально тщательным") превратились в десятки ненужных поисков по базе знаний.

Запуск /claude-api prompt-audit удалил антипаттерны, снизив затраты на 14.6% и повысив точность в среднем на 5.3%. Затраты снизились, потому что были устранены лишние вызовы инструментов и дублированные рассуждения. Точность повысилась по трем причинам. Устаревшая настройка мышления заставляла API отклонять каждый маршрутизирующий запрос. Противоречивые правила возврата привели к тому, что Opus 5 удержал четыре возврата, которые должен был сделать, пока просил клиента подтвердить. А ручной черновик столкнулся со встроенным мышлением Opus 5: по трем тикетам он написал вызов инструмента внутри своих рассуждений и никогда его не выполнил.

Уровень усилий

Уровень усилий говорит Claude «как усердно работать». При низком уровне усилий Claude обычно приходит к выводам быстрее. При высоком уровне усилий Claude обдумывает, проверяет и исследует альтернативы перед ответом.

Соотношение затрат и производительности при разных уровнях усилий на одной модели может различаться. Например, Claude Fable 5 набирает 11.5% при низком уровне усилий за $5.35 за задачу на FrontierCode Diamond (самые сложные 50 задач). При максимальном уровне усилий Fable 5 получает 30.9% за $19.00 за задачу; изменение уровня усилий повышает результат примерно в 2.7 раза (+19 пунктов) при увеличении стоимости примерно в 3.5 раза (Рисунок 4).

На Claude Fable 5.1, Humanity's Last Exam (без инструментов) показывает крутую кривую с убывающим последним шагом. Он набирает около 53% при низком уровне усилий за примерно $0.30 за вопрос и около 61% при максимальном уровне усилий за примерно $2.23; последний шаг до максимума добавляет около половины пункта за 46% увеличения стоимости. Выигрыш находится в пределах шума запуска бенчмарка, поэтому вы платите больше без измеримого улучшения.

Уровень усилий может быть неправильно откалиброван в любом направлении:

• Предположение, что выше всегда лучше. Высокий уровень усилий может вызвать чрезмерное обдумывание. Claude тратит больше времени на размышления, чем требует задача, что увеличивает стоимость и задержку и может ухудшить качество ответа. Размышления помогают только до тех пор, пока есть еще доказательства для поиска.
• Склонность к низкому уровню усилий. Установленный слишком низким, Claude останавливается, прежде чем у него будет достаточно доказательств. Он делает меньше вызовов инструментов, поэтому может ответить на основе первого результата поиска вместо третьего. Он меньше думает над сложными шагами и пропускает проверку, которую обычно выполняет сам. Ответ выглядит законченным, но построен на неполной информации.

Как это исправить

Есть несколько полезных способов откалибровать уровень усилий:

• Тестируйте более сильные модели при низком уровне усилий. Более сильная модель при низком уровне усилий может быть дешевле, чем более слабая модель, работающая усердно (высокий уровень усилий). Например, на CursorBench 3.2, Claude Fable 5.1 при низком уровне усилий соответствует производительности Fable 5 при высоком уровне усилий при трети стоимости (Рисунок 5). Две вещи делают новую модель дешевле: при низком уровне усилий она выполняет меньше работы на задачу, и чтение из кэша промптов для Fable 5.1 стоит $0.25 за миллион токенов против $1.00 для Fable 5. Даже по ценам Fable 5, Fable 5.1 при низком уровне усилий стоила бы примерно на 40% меньше.

• Поймите форму вашей задачи. Измерение производительности приложения в диапазоне уровней усилий — полезный способ понять компромисс между стоимостью и производительностью для вашей конкретной задачи. На ненасыщенной оценке плоская кривая стоимости-производительности по уровням усилий предполагает, что задача не ограничена вычислительными ресурсами мышления; увеличение усилий не приносит пользы.

Эта калибровка часто включает запуск оценки по моделям и уровням усилий. В Claude Code, /claude-api hillclimb выполняет этот поиск за вас: он разделяет вашу оценку на обучающий и тестовый наборы, предлагает изменения конфигурации и читает неудачные обучающие примеры, чтобы исправить то, что находит.

Мы запустили его на бенчмарке поддержки клиентов, начиная с Opus 4.8 с его уровнем усилий по умолчанию (высокий). Hillclimber сначала попробовал Opus 5 при низком уровне усилий, применив prompt-audit для удаления обязательных ритуалов вызова инструментов, шагов черновика и противоречивых правил. Это превзошло базовый уровень Opus 4.8 с точностью 98.9% на обучающем наборе и снизило стоимость до 2.6 центов за тикет (Рисунок 6).

Затем он перешел на Sonnet 5 при низком уровне усилий, что было еще дешевле — 1 цент за тикет, но точность упала до 88.9%. Читая неудачные обучающие тикеты, Claude добавил правила маршрутизации и перекрестную ссылку на лимит возврата в промпт, вернув Sonnet 5 к точности 98.9% при той же стоимости.

На 14 отложенных тикетах, которые поиск никогда не видел, финальная конфигурация набрала 90.5% против 78.6% у исходной настройки, при примерно одной пятой стоимости.

Автоматизация снижения затрат

Кэширование промптов, инструкции и уровень усилий — это распространенные рычаги для снижения затрат. Наша документация охватывает еще больше. Чтобы провести комплексный аудит затрат кода приложения, использующего Claude API, мы добавили /claude-api cost-optimize: он профилирует, куда уходят ваши расходы, применяет меры по снижению затрат и, если вы предоставите оценку, показывает, как экономия соотносится с производительностью.

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

Затем он ранжирует доступные варианты экономии, начиная с кэширования промптов, сокращения того, что несет каждый запрос (включая prompt-audit), ограничения вывода и пакетной обработки фоновой работы. Если вы предоставите оценку, он идет дальше и вычисляет стоимость и производительность по уровням усилий и выбору моделей. Мы запустили это на четырех публичных бенчмарках с Sonnet 5 в качестве базового уровня (Рисунок 7):

• LegalBench (~58% снижение затрат): cost-optimize предложил кэшировать общий префикс между задачами, установить низкий уровень усилий и обрабатывать задачи через Batch API. Количество токенов на размышления упало со 102,779 до 8,284, показатель успешности остался в пределах шума, а затраты снизились примерно на 58%.
• tau2-bench retail (~73% снижение затрат): Внедрив кэширование промптов с явным размещением точки разрыва, cost-optimize сократил расходы на 72%, сохранив показатель успешности на прежнем уровне.
• OfficeQA Pro (~52% снижение затрат): cost-optimize добавил пакетную обработку и кэширование документов, что снизило стоимость с $136.20 до $64.87.
• SWE-bench Verified (~55% снижение затрат): cost-optimize обнаружил, что конфигурация по умолчанию уже правильно кэширует. Экономия была достигнута за счет установки среднего уровня усилий и ограничения вывода агента всего несколькими краткими предложениями. Медианное количество шагов на задачу сократилось с 29 до 17, а количество токенов промпта упало с 75.2M до 33.7M.

Начало работы

Начните с /claude-api prompt-audit, когда вы перешли на передовую модель Claude и хотите проверить свои существующие промпты. Он сканирует промпты, навыки и описания инструментов в вашей рабочей директории. Это может быть код приложения, вызывающий Claude API, или конфигурация Claude Code (CLAUDE.md, навыки). Он удаляет распространенные антипаттерны, которые сковывают передовые модели.

Используйте /claude-api cost-optimize, когда ваше приложение использует Claude API и вы хотите провести аудит затрат. Он профилирует расход токенов, а затем тестирует различные рычаги: применяет prompt-audit, но также проверяет способы снижения затрат через кэширование промптов, пакетную обработку фоновой работы или ограничение вывода. Если вы предоставите оценку, он измеряет компромиссы между уровнем усилий и выбором модели.

Наконец, используйте /claude-api hillclimb для поиска по стоимости и производительности. Имея оценку, Claude разделяет ее на обучающий и тестовый наборы, затем предлагает обновления вашего приложения, направленные на снижение затрат при сохранении базовой производительности. Claude читает неудачные обучающие примеры, чтобы направлять поиск, и финальная конфигурация оценивается на отложенном тестовом наборе.

Чтобы узнать больше:

• Смотрите нашу документацию здесь
• Смотрите нашу кулинарную книгу по снижению затрат здесь
• Смотрите навык claude-api здесь; навык также встроен в Claude Code
• Смотрите эту статью в блоге Claude здесь

Написано Лэнсом Мартином (@RLanceMartin), Брэдом Абрамсом (@brada), Изабеллой Хе (@IsabellaKHe) и Беном Лербургером (@benlehrburger).