Налаштування кешування підказок, інструкцій та зусиль може зменшити вартість 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 та можуть ненавмисно збільшувати витрати:
- Ритуали перевірки. Інструкції на кшталт «перевірте свою роботу» або «перевірте двічі перед відповіддю» часто сприймаються передовими моделями буквально та можуть витрачати токени.
- Підсилювачі ретельності та акценту. «Будьте максимально ретельними», «КРИТИЧНО: ВИ ЗАВЖДИ ПОВИННІ…» можуть призвести до багатослівності та додаткових викликів інструментів під час роботи з передовими моделями.
- Обов'язкові процедури та шаблони чернеток. Покрокові процеси (наприклад, «думайте крок за кроком у чернетці») або шаблони міркувань — це ритуали, які не потрібні передовим моделям. Ці конструкції можуть накладатися на власні міркування моделі та використовувати непотрібні токени.
- Застарілі приклади. Приклади з кількома зразками, налаштовані на режими збоїв старішої моделі, можуть навчити передову модель імітувати довгі ланцюжки міркувань на запитах, які їх не потребують.
- Суперечливі правила. Передові моделі краще слідують інструкціям. Суперечливі інструкції («завжди повертайте кошти відповідно до політики» проти «ніколи не повертайте кошти без ескалації») можуть виконуватися передовими моделями більш буквально, що призводить до погіршення продуктивності.
- Застаріла конфігурація. Налаштування, написані для старшого покоління 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, з об'єкта використання в кожній відповіді 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).
