Claude 5.5: Припиніть платити за невдалі завдання

Налаштування Sonnet та Opus, яке має значення: effort, кеш, верифікація та вартість виконаного завдання

Найдешевша модель — це не та, у якої найнижча ціна за токен

Це та, яка завершує роботу, проходить перевірку і не змушує вас платити за той самий контекст ще п'ять разів

Sonnet 5.5 та Opus 5.5 роблять цю різницю надзвичайно важливою. Одна оцінена для обсягу. Інша — для складнішої роботи. Обидві мають нову поведінку параметра effort, і обидві можуть виявитися напрочуд дешевими всередині добре закешованого циклу агента

Скопіюйте стару конфігурацію в будь-яку з цих моделей, і результат може стати повільнішим, дорожчим або завершитися помилкою 400

Ось налаштування, яке я б побудував натомість

1ЗАВДАННЯ → SONNET 5.5 → ПЕРЕВІРКА → OPUS 5.5 ЗА ПОТРЕБИ → ВЕРИФІКОВАНИЙ РЕЗУЛЬТАТ
2             ↘ effort ↗         ↘ кеш + журнал використання ↗

Я публікую практичні розбори AI-агентів, воркфлоу та продакшн-систем на Substack

Підписуйтесь на розсилку тут

Показник, який має визначати ваш стек

Більшість порівнянь моделей починаються з доларів за мільйон токенів

Ваш агент не постачає токени. Він постачає виконані завдання

https://x.com/claudeai/status/2102435511222890900

Ще раз: це їхні тести. Вашій архітектурі потрібні ваші цифри

Це означає, що перевірка не може бути розмитим «схвалено» після прочитання однієї вражаючої відповіді. Для коду використовуйте тест, який заблокував би злиття (merge). Для вилучення даних — порівняйте обов'язкові поля з розміченим набором. Для досліджень — фіксуйте, чи дійсно процитоване джерело підтверджує кожне твердження. Включайте вартість завдань, які ніколи не проходять перевірку, а не лише гарні приклади з вашого демо

І окремо аналізуйте «важкий хвіст». Якщо найдешевше налаштування обробляє 90% ваших запитів, але спалює половину бюджету на решті 10%, його середній показник може приховувати ту частину воркфлоу, якій потрібна інша модель

Що насправді написано в прайс-листі 5.5

Станом на 3 жовтня 2026 року, за стандартними тарифами Claude API, на мільйон токенів:

1SONNET 5.5
2Новий input  $2       Output  $10
3Cache read   $0.20    Cache write  $2.50 / 5m, $4 / 1h
4
5OPUS 5.5
6Новий input  $4       Output  $20
7Cache read   $0.20    Cache write  $5 / 5m, $8 / 1h

Обидві моделі мають контекстне вікно на 1M токенів і максимальний output на 128K токенів. Це стелі, а не привід забивати їх до відмови.

Характеристики та ціни моделей

Незвичний рядок — cache read

Opus коштує вдвічі дорожче за новий input та output, але закешований префікс коштує однаково — $0.20 за мільйон на обох моделях. Це не робить запуск Opus таким самим дешевим: він усе одно платить більше за новий input, output та запис у кеш. Але це означає, що розрив у ціні між моделями може скоротитися під час сесії з переважним читанням

Є й друга відмінність, яку часто пропускають. Заява Anthropic «на 40% дешевше за Opus 5» — це оцінка типової \вартості запуску\. Ціни на нові токени Opus 5.5 впали на 20%; ціна на cache-read впала на 60%. Ці цифри пов'язані, але вони не взаємозамінні

Effort — це рішення про маршрутизацію, а не повзунок якості

Sonnet 5.5 підтримує low, medium, high, xhigh та max. В API за замовчуванням стоїть high, а в додатках Claude, за словами Anthropic, дефолтом є medium. Opus 5.5 в API за замовчуванням використовує medium. Ці рівні не відкалібровані так, щоб означати точно те саме, що й ті ж слова в попередніх моделях.

Моя стартова карта:

• Sonnet low Для вузьких, чутливих до затримки запитів із дешевою перевіркою
• Sonnet medium Для добре специфікованого кодингу та рутинної багатокрокової роботи
• Sonnet high Коли запуск на medium не проходить реальну перевірку, або завдання має доведений патерн складності
• Opus medium Для неоднозначної, міжфайлової, довгострокової роботи, де Sonnet витрачає кроки, ходячи навколо проблеми
• Xhigh/max Лише після того, як ваші evals покажуть виграш, вартий додаткового часу та токенів

Це початкова гіпотеза, а не універсальна ієрархія. У результатах FrontierCode для Sonnet 5.5, опублікованих Anthropic, xhigh набрав більше балів, ніж max. Більше зусиль — не гарантія кращого результату

Виноска Anthropic пояснює цей нелогічний результат: на рівні max модель частіше запускала додаткову роботу з код-рев'ю. У двох досліджених випадках це призвело до таймауту або правок, що виходили за межі завдання.

Проблемою було не «модель недостатньо подумала», а те, що зусилля витрачалися не туди. Якщо ваш агент уже проходить перевірки, додаткові ітерації рев'ю можуть перетворитися на витрати та джерело нових помилок

https://x.com/edwinarbus/status/2104675431853248816

Також не варто ставити низький max_tokens і називати це оптимізацією. Ліміт охоплює і роздуми (thinking), і видимий output. Якщо ви обріжете його посеред завдання, то замість економії отримаєте обрізану відповідь і другий запуск

https://x.com/claudeai/status/2104633115620823187

Це переконлива заява на момент релізу. Але продакшн-конфігурація все одно має перевершити ваш власний базовий рівень

Зробіть невеликий прогін, перш ніж винаходити маршрутизатор моделей

Візьміть 10–30 завдань, які вам справді важливі. Додайте просту роботу, неоднозначну роботу та ті дратівливі фейли з ваших логів. Дайте кожному завданню верифікатор: тести, структуроване порівняння, відому відповідь або людський рубрик, зафіксований до запуску

Ось найменший корисний API-зонд. Він логує потрібні вам поля usage. Запустіть його на кожній моделі та рівні effort проти того самого завдання, а потім додайте власну перевірку pass/fail. Це не повноцінний бенчмарк агента

1import anthropic
2
3client = anthropic.Anthropic()
4response = client.messages.create(
5    model="claude-sonnet-5-5",  # повторіть із claude-opus-5-5
6    max_tokens=8192,
7    output_config={"effort": "medium"},  # повторіть на high
8    messages=[{"role": "user", "content": "Замініть це на реальне завдання."}],
9)
10
11answer = "".join(b.text for b in response.content if b.type == "text")
12usage = response.usage
13print(answer)
14print("fresh", usage.input_tokens, "output", usage.output_tokens)
15print("cache read", usage.cache_read_input_tokens)
16print("cache write", usage.cache_creation_input_tokens)

Передбачається використання офіційного Python-пакета Anthropic та змінної середовища ANTHROPIC_API_KEY. Це один ізольований виклик без увімкненого кешування, тому очікується нульове читання та запис у кеш. У наступному розділі показано, що це змінює

Для реального агента сумуйте usage по всіх викликах API в межах одного ID завдання, включно з повторними спробами та викликами інструментів. Зараховуйте успіх лише тоді, коли верифікатор каже, що роботу завершено

Порівнюйте загальну суму в доларах за один успішний прохід, перш ніж обирати дефолтне налаштування

Зробіть тест чесним:

• Зафіксуйте набір завдань і верифікатор до порівняння конфігурацій
• Використовуйте однакові інструменти, дозволи, контекст і вимоги до output для кожного кандидата
• Фіксуйте pass rate, загальні витрати, вартість одного успіху, затримку, а також найдовші чи найдорожчі невдачі
• Вважайте stop_reason: "max_tokens" незавершеною спробою, а не дешевим успіхом

Короткий приклад коду вище використовує ліміт output у 8K для однокрокового зонда. Не копіюйте цей ліміт у довготривалого кодинг-агента.

Anthropic рекомендує значно більший запас для агентної роботи, оскільки приховані роздуми (thinking) зараховуються до того самого ліміту.

Встановіть ліміт під завдання, а потім контролюйте витрати через effort, кешування та бюджет завдання, замість того щоб примусово зупиняти відповідь на півдорозі

Кешуйте стабільну частину роботи

Агенти раз за разом надсилають ті самі системні інструкції, визначення інструментів, карту репозиторію та попередню розмову. Якщо цей префікс стабільний, prompt caching змінює економіку сильніше, ніж дрібний перепис промпту

Наприклад, 200K закешованих токенів, прочитаних 50 разів — це 10M токенів cache-read. За ціною $0.20 за мільйон, читання коштуватимуть $2 на будь-якій з моделей 5.5.

На Opus 5.5 надсилання тих самих 10M токенів як нового input коштувало б $40. Перший п'ятихвилинний запис у кеш для 200K токенів — це ще $1.

Це ілюстрація лише витрат на префікс: новий input, output, інші записи, закінчення TTL та фактичні cache misses додаються до рахунку

Практичні правила:

• В Claude API вмикайте prompt caching через cache_control={"type": "ephemeral"} на верхньому рівні або через явні точки розбиття кешу. Наведений вище зонд не робить жодного з цього, тому його лічильники кешу зазвичай залишатимуться на нулі
• Розміщуйте стабільні інструкції та інструменти перед змінним запитом користувача
• Тримайте спільний префікс ідентичним між кроками; перевіряйте фактичне значення cache_read_input_tokens
• Ставтеся до зміни моделі як до нового бюджету розмови, а не безкоштовного продовження. Кеш працює для кожної моделі окремо: запит до Opus не може прочитати префікс, який щойно закешував Sonnet
• Уникайте зміни effort на верхньому рівні на кожному кроці; це змінює згенерований промпт і робить закешовані префікси недійсними

На підтримуваних моделях зміна effort для окремого повідомлення може зберегти попередній кеш, але це потребує бета-заголовка Anthropic і не те саме, що зміна output_config на верхньому рівні.

Sonnet 5.5 також має застереження between_tools: у цьому режимі effort не можна змінювати посеред розмови.

Документація з prompt caching

Не робіть висновок про cache hit на основі швидкої відповіді. Читайте об'єкт usage. Він розділяє новий input, створення кешу та читання з кешу

Обом моделям 5.5 потрібно щонайменше 512 токенів у префіксі, який можна кешувати. Крихітний системний промпт не дасть економії з прикладу вище. Стандартний час життя кешу — п'ять хвилин, що добре підходить для швидкого циклу інструментів.

Запис на одну годину коштує дорожче і має сенс лише тоді, коли реальні сесії часто призупиняються настільки довго, що не вкладаються у п'ятихвилинне вікно. Виміряйте ці паузи, перш ніж платити за довший TTL

Ескалюйте на основі доказів, а не тривоги

Більшість команд будують маршрутизатор задом наперед: класифікують завдання як «складне», відправляють його дорогій моделі й ніколи не дізнаються, чи пройшов би дешевший шлях

Використовуйте верифікатор як сигнал для маршрутизації

11  Sonnet 5.5 · обраний effort  → виконати завдання
22  Верифікатор                  → прийняти, якщо пройшло
33  Opus 5.5 · medium            → повторити лише за наявності доказів невдачі
44  Верифікатор                  → прийняти або передати далі з доказами

Перевіркою може бути набір тестів, валідація схеми, відома відповідь або рев'юер. Вона має пояснювати, що саме не спрацювало.

«Відповідь здається слабкою» — поганий сигнал для ескалації, «змінений ендпоінт не проходить два інтеграційні тести» — корисний

Не повторюйте сліпо ідентичний промпт. Дайте наступній спробі невдалу перевірку, відповідні артефакти та конкретну інструкцію виправити прогалину. Обмежте «драбину», щоб агент не спалив бюджет, намагаючись виправити завдання, яке потребує людського рішення

Ви можете протестувати повторну спробу Sonnet high у своєму офлайн-прогоні. Залишайте її в живому маршруті лише якщо вона знижує вартість верифікованого завдання. Немає сенсу змушувати кожну невдачу оплачувати два запуски Sonnet перед Opus

Сама зміна моделі може зламати закешований префікс. Враховуйте це, коли порівнюєте «шлях порятунку» з маршрутом, де Opus іде першим

Точку перетину легко пропустити. Припустимо, спроба Sonnet коштує $0.06 і проходить 80% ваших завдань.

Якщо кожне невдале завдання потім коштує $0.20 для завершення на Opus, ваша ілюстративна середня вартість становить $0.10 за виконане завдання: $0.06 плюс $0.20 на порятунок одного завдання з п'яти. Це краще, ніж платити $0.20 за Opus на кожному завданні. Але якщо Sonnet коштує $0.14 і проходить лише половину, та сама драбина коштуватиме $0.24, ще до того, як ви оціните зміну моделі. У такому навантаженні Opus-first буде дешевшим і швидшим

Ці цифри — приклади, а не виміряні результати Claude. Їхня мета — зробити правило маршрутизації таким, що можна спростувати. Драбина заслуговує на місце лише тоді, коли зекономлені виклики Opus переважують невдалі спроби Sonnet, промахи кешу та додаткову затримку

Є й середній шлях: бета-версія advisor tool від Anthropic. Sonnet може продовжувати виконувати завдання і просити Opus про допомогу у складному рішенні, замість того щоб віддавати всю роботу Opus.

Це не автоматично дешевше. Логуйте, як часто Sonnet реально звертається до advisor, скільки коштують ці виклики і чи покращують вони фінальний pass rate. Якщо виконавець рідко запитує пораду, advisor — просто невикористана функція.

У цих моделях 5.5 сама порада повертається клієнту в зашифрованому вигляді, тому оцінюйте результуючу роботу, а не робіть вигляд, що можете перевірити приватний текст поради

Чотири витоки, які збільшують рахунок ще до того, як вибір моделі матиме значення

Не кожна проблема з витратами потребує нового маршрутизатора

Спершу перевірте це:

• Output, що постійно зростає На обох моделях 5.5 токени output коштують уп'ятеро дорожче за токени нового input. У розмові довга відповідь може повернутися як контекст на наступних кроках. Просіть артефакт і коротку нотатку про завершення, а не озвучену стенограму кожного кроку. Приховані роздуми (thinking) також тарифікуються як output, тому лише лаконічна фінальна відповідь не вирішить проблему з effort. Але не приховуйте докази, необхідні для верифікації результату
• Зображення більші, ніж потрібно для завдання Sonnet 5.5 може обробляти зображення вищої роздільної здатності, ніж старіші версії Sonnet, що може збільшити кількість токенів зображення. Якщо агенту потрібна лише мітка кнопки чи один абзац, спершу обріжте або змініть розмір. Якщо потрібен насичений графік чи дрібні деталі інтерфейсу, залиште роздільну здатність і виміряйте вартість, замість того щоб сліпо її зменшувати
• Контекст, який ніхто не використовує Визначення інструментів, застарілі логи, старі результати пошуку та розлогий CLAUDE.md можуть тягнутися за кожним запитом. Винесіть незмінні правила у короткий стабільний префікс; тримайте тимчасові докази поруч із завданням, яке їх потребує. Скорочення контексту не повинно видаляти факти, які моделі все ще потрібні для правильного завершення
• Інтерактивні ціни за роботу, на яку ніхто не чекає Message Batches API дає знижку 50% на input і output для обох моделей. Це корисно для офлайн-оцінок, дозаповнення документів та інших асинхронних задач. Це не заміна живому циклу інструментів, де людині потрібен наступний крок прямо зараз

Патерн однаковий для всіх чотирьох: приберіть роботу, якої завдання не потребує, перш ніж купувати більше інтелекту або знижувати effort до рівня, коли ламається якість

Пастки міграції, які перетворюють економію на помилку 400

Старі тіла запитів — погана відправна точка для сімейства 5.5.

Зокрема:

• Thinking в Opus 5.5 завжди увімкнений Видаліть thinking: {"type": "disabled"} та старі фіксовані налаштування budget_tokens; керуйте глибиною через output_config.effort
• Примусовий вибір інструменту не працює на обох моделях 5.5

Значення tool_choice any та tool повертають 400. Використовуйте auto, вказуйте, коли слід застосовувати інструмент, і валідуйте результат інструменту у власному коді

• Блоки thinking — це не текстові блоки Читайте content за полем type, а не через content[0]. У циклах інструментів повертайте блоки thinking без змін разом із кроком асистента
• Ваш UI може здаватися «німим» На Opus 5.5 прогрес між інструментами може надходити у блоках thinking, які порожні за стандартних налаштувань відображення. Якщо раніше ви показували ці нотатки користувачам, запитуйте підтримуваний режим відображення thinking і рендерте блоки за типом. Інакше агент може працювати, поки інтерфейс виглядатиме завислим
• Старі версії computer-use tool можуть не працювати Перевірте актуальну версію інструменту перед міграцією браузерного/комп'ютерного агента
• Менший ліміт max_tokens може обірвати роботу

Thinking включається у ліміт, навіть коли текст прихований

Це зміни поведінки API, а не трюки з написання промптів.

Гайд з міграції Opus та гайд з міграції Sonnet

Закріпіть контракт у Claude Code, а не в голові

API — це місце, де ви можете виміряти кожне поле usage. Claude Code — це місце, де багато хто вперше відчує зміну моделі. Принцип той самий: дайте агенту обмежене визначення готовності, а потім змусьте його показати докази

У Claude Code команда **/model обирає модель, а /effort — підтримуваний рівень effort. Перевіряйте активні налаштування перед порівнянням сесій. Дефолтне значення API для Sonnet — не надійний опис того, що зараз використовує ваш додаток Claude або сесія Claude Code

Ось повний, придатний для повторного використання стартовий блок CLAUDE.md. Змініть команди відповідно до вашого проєкту

1# Робочий контракт
2
3Внось лише запитану зміну. Не чіпай непов'язаний код.
4Після редагування запусти відповідні тести. Повідом про будь-яку перевірку, яку не можеш запустити.
5Зупинись, коли запитана робота пройде перевірку. Не додавай зайвих фіч чи циклів рев'ю.
6Завершуй так: Changed / Verified / Remaining risk.
7Запитуй дозволу перед деструктивними діями, публікацією або змінами поза цим репозиторієм.

Цей блок магічно не зробить кожен запуск дешевим. Він робить успіх і невдачу видимими. Після цього ви зможете порівняти воркфлоу Sonnet-first із Opus-first на тих самих завданнях

Повідомлення із завданням все одно має бути конкретним. Ось різниця між «пофіксь код платежів» і роботою, яку агент справді може завершити

1Change: перенести платіжний ендпоінт на новий клієнт
2Done: старий клієнт видалено, тести ендпоінта пройдено, diff обмежено цим шляхом
3Stop: запитати перед видаленням даних або змінами поза репозиторієм
4Report: змінені файли, точні виконані перевірки, залишковий ризик

Цей маленький контракт дає верифікатору щось конкретне для перевірки. А моделі — причину зупинитися. Відкрита інструкція «перевіряй, поки не стане ідеально» може перетворити успішну зміну на ще один оплачуваний цикл

Для довгих проєктів тримайте чеклист у файлі, який переживе стиснення контексту. Для сабагентів просіть головного агента перевіряти їхні докази, перш ніж приймати звіти. І якщо ви просили лише ідеї, скажіть Claude не починати будувати. Це межі воркфлоу, а не промпти в стилі «будь розумнішим»

Налаштування, яке я б запустив першим

• Візьміть 10–30 реальних завдань і визначте перевірку для кожного
• Проганяйте Sonnet 5.5 на medium і high, потім Opus 5.5 на medium
• Логуйте новий input, output, записи в кеш, читання з кешу, затримку, повторні спроби та pass/fail для кожного завдання
• Тримайте стабільний префікс придатним для кешування і підтверджуйте cache hits у usage
• Маршрутизуйте вгору лише невдачі, додаючи до них докази
• Переглядайте драбину, коли навантаження змінюється. Збережений бенчмарк — не істина в останній інстанції

Якщо складні 10% раз за разом ідуть напряму від невдачі Sonnet до успіху Opus, подумайте про те, щоб одразу маршрутизувати цей впізнаваний клас завдань до Opus. Якщо Sonnet high проходить ті самі випадки дешевше, залишайте їх там. Маршрутизатор — це виміряна політика, а не постійна думка про те, яка модель розумніша

Оновлення 5.5 — це не просто «використовуй Sonnet для дешевої роботи, а Opus для складної»

Це шанс перестати оцінювати модель і почати оцінювати виконану роботу

Якщо ви дочитали досюди

-> Підписуйтесь на мій Substack

-> Приєднуйтесь до мого Telegram

-> Додайте цю статтю в закладки

-> Підписуйтесь на @0xwhrrari