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

Повторюсь: это их тесты. Твоей архитектуре нужны твои цифры

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

И отдельно изучай «тяжёлый хвост». Если самая дешёвая настройка закрывает 90% запросов, но сжигает половину бюджета на оставшихся 10%, её средние показатели скроют ту часть воркфлоу, где нужна другая модель

Что на самом деле написано в прайс-листе 5.5

По состоянию на 3 октября 2026 года, по стандартным тарифам Claude API, за миллион токенов:

1SONNET 5.5
2Новый ввод   $2       Вывод   $10
3Чтение кэша  $0.20    Запись в кэш  $2.50 / 5 мин, $4 / 1 ч
4
5OPUS 5.5
6Новый ввод   $4       Вывод   $20
7Чтение кэша  $0.20    Запись в кэш  $5 / 5 мин, $8 / 1 ч

У обеих моделей контекстное окно в 1M токенов и максимальный вывод в 128K токенов. Это потолки, а не руководство к тому, чтобы забивать их под завязку.

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

Самая странная строчка — чтение кэша

Opus стоит вдвое дороже за новый ввод и вывод, но закэшированный префикс обходится в те же $0.20 за миллион у обеих моделей. Это не делает запуск Opus таким же дешёвым: он всё равно платит больше за новый ввод, вывод и запись в кэш. Но это значит, что разрыв в цене между моделями может сократиться в сессиях с большим количеством чтений

Есть и второе отличие, которое многие упускают. Фраза Anthropic «на 40% дешевле Opus 5» — это оценка типичной \стоимости запуска\. Цены на новые токены у Opus 5.5 упали на 20%; цена чтения кэша — на 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 Только если твои эвалы показывают выигрыш, оправдывающий лишнее время и токены

Это стартовая гипотеза, а не универсальная иерархия. В опубликованных Anthropic результатах FrontierCode для Sonnet 5.5 уровень xhigh набрал больше баллов, чем max. Больше усилий — не гарантия лучшего результата

Сноска Anthropic объясняет этот контринтуитивный результат: на уровне max модель чаще запускала дополнительную работу по ревью кода. В двух рассмотренных случаях это привело к таймауту или правкам, выходящим за рамки задачи.

Проблема была не в том, что «модель недостаточно подумала». Она тратила усилия не туда. Если твой агент уже проходит проверки, лишние циклы ревью превращаются в расходы и источник новых ошибок

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

И не надо ставить низкий max_tokens и называть это оптимизацией. Лимит покрывает и размышления, и видимый вывод. Обрежешь его посреди задачи — получишь обрезанный ответ и второй запуск вместо экономии

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("новый ввод", usage.input_tokens, "вывод", usage.output_tokens)
15print("чтение кэша", usage.cache_read_input_tokens)
16print("запись в кэш", usage.cache_creation_input_tokens)

Код предполагает использование официального Python-пакета Anthropic и переменной окружения ANTHROPIC_API_KEY. Это один изолированный вызов без включённого кэширования, поэтому счётчики кэша ожидаемо будут нулевыми. В следующем разделе показано, что это меняет

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

Перед выбором дефолтной настройки сравнивай общую сумму в долларах за один успешный проход

Держи тест честным:

• Зафиксируй набор задач и верификатор до сравнения конфигов
• Используй одни и те же инструменты, права, контекст и требования к выводу для всех кандидатов
• Фиксируй процент успехов, общие расходы, стоимость одного успеха, задержку и самые долгие или дорогие фейлы
• Считай stop_reason: "max_tokens" незавершённой попыткой, а не дешёвым успехом

В коротком примере выше используется лимит вывода в 8K для одношагового пробника. Не копируй этот лимит в длинного кодинг-агента.

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

Ставь лимит под задачу, а расходы контролируй через effort, кэширование и бюджет задачи, а не принудительно обрывая ответ на полуслове

Кэшируй стабильную часть работы

Агенты раз за разом отправляют одни и те же системные инструкции, определения инструментов, карту репозитория и историю диалога. Если этот префикс стабилен, кэширование промпта изменит экономику сильнее, чем мелкая переформулировка

Например, 200K закэшированных токенов, прочитанных 50 раз, — это 10M токенов чтения кэша. По $0.20 за миллион, эти чтения обойдутся в $2 на любой из моделей 5.5.

На Opus 5.5 отправка тех же 10M токенов как нового ввода стоила бы $40. Первая пятиминутная запись 200K токенов в кэш — это ещё $1.

Это иллюстрация только расходов на префикс: новый ввод, вывод, другие записи, истечение TTL и реальные промахи кэша добавятся к счёту

Практические правила:

• В Claude API включай кэширование промпта через верхнеуровневый cache_control={"type": "ephemeral"} или явные точки разрыва кэша. Пробник выше не делает ни того, ни другого, поэтому его счётчики кэша обычно останутся на нуле
• Ставь стабильные инструкции и инструменты перед меняющимся пользовательским запросом
• Держи общий префикс идентичным между шагами; проверяй реальные cache_read_input_tokens
• Относись к смене модели как к новому бюджету беседы, а не бесплатному продолжению. Кэш работает для каждой модели отдельно: запрос к Opus не сможет прочитать префикс, который только что закэшировал Sonnet
• Избегай изменения верхнеуровневого effort на каждом шаге; это меняет итоговый промпт и инвалидирует закэшированные префиксы

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

У Sonnet 5.5 есть и оговорка between_tools: в этом режиме effort нельзя менять посреди диалога.

Документация по кэшированию промптов

Не делай вывод о попадании в кэш по быстрому ответу. Читай объект usage. Он разделяет новый ввод, создание кэша и чтения из кэша

Обе модели 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» будет дешевле и быстрее

Эти цифры — примеры, а не измеренные результаты Claude. Их цель — сделать правило маршрутизации проверяемым. Лестница оправдана только если сэкономленные вызовы Opus перевешивают проваленные попытки Sonnet, промахи кэша и добавленную задержку

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

Это не автоматически дешевле. Логируй, как часто Sonnet реально обращается к советнику, сколько стоят эти вызовы и улучшают ли они итоговый процент успехов. Если исполнитель редко спрашивает, советник — просто неиспользуемая фича

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

Четыре утечки, которые раздувают счёт ещё до выбора модели

Не каждая проблема с расходами требует нового роутера

Сначала проверь это:

• Вывод, который постоянно растёт На обеих моделях 5.5 выходные токены стоят в пять раз дороже новых входных. В диалоге длинный ответ может вернуться как контекст на следующих шагах. Проси артефакт и короткую заметку о завершении, а не озвученную стенограмму каждого шага. Скрытые размышления тоже тарифицируются как вывод, поэтому один лишь краткий финальный ответ не решит проблему с effort. Но не подавляй данные, которые нужны для проверки результата
• Изображения крупнее, чем нужно задаче Sonnet 5.5 умеет обрабатывать картинки в более высоком разрешении, чем старые версии Sonnet, что может увеличить количество токенов изображений. Если агенту нужна только надпись на кнопке или один абзац, сначала кадрируй или уменьши картинку. Если нужен плотный график или мелкие детали UI, оставь разрешение и измерь стоимость, вместо того чтобы слепо его резать
• Контекст, который никто не использует Определения инструментов, устаревшие логи, старые результаты поиска и разросшийся CLAUDE.md могут тянуться за каждым запросом. Помести постоянные правила в короткий стабильный префикс; временные данные держи рядом с задачей, где они нужны. Обрезка контекста не должна удалять факты, которые всё ещё нужны модели для корректного завершения
• Интерактивные цены за работу, которую никто не ждёт Message Batches API даёт скидку 50% на ввод и вывод для обеих моделей. Это полезно для офлайн-оценок, дозагрузки документов и других асинхронных задач. Но это не замена живому циклу инструментов, где человеку следующий шаг нужен прямо сейчас

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

Ловушки миграции, превращающие экономию в ошибку 400

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

В частности:

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

Значения tool_choice — any и tool — возвращают 400. Используй auto, указывай, когда инструмент должен применяться, и валидируй результат инструмента в своём коде

• Блоки размышлений — это не текстовые блоки Читай контент по type, а не по content [0]. В циклах инструментов возвращай блоки размышлений без изменений вместе с ходом ассистента
• Твой UI может казаться зависшим В Opus 5.5 прогресс между вызовами инструментов может приходить в блоках размышлений, которые пусты при настройках отображения по умолчанию. Если раньше ты показывал эти заметки пользователям, запрашивай поддерживаемый режим отображения размышлений и рендерь блоки по типу. Иначе агент может работать, пока интерфейс выглядит замершим
• Старые версии computer-use tool могут падать Проверь актуальную версию инструмента перед миграцией браузерного/компьютерного агента
• Меньший лимит max_tokens может оборвать работу

Размышления учитываются, даже когда текст скрыт

Это изменения поведения 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Завершай отчётом: Изменено / Подтверждено / Оставшийся риск.
7Спрашивай перед деструктивными действиями, публикацией или изменениями вне этого репозитория.

Этот блок волшебным образом не сделает каждый запуск дешёвым. Он делает успехи и провалы видимыми. После этого ты сможешь сравнить воркфлоу «сначала Sonnet» и «сначала Opus» на одних и тех же задачах

Сообщение с задачей всё равно должно быть конкретным. Вот разница между «почини код платежей» и работой, которую агент реально способен закончить

1Изменить: перевести эндпоинт платежей на новый клиент
2Готово: старый клиент удалён, тесты эндпоинта проходят, дифф ограничен этим путём
3Стоп: спрашивать перед удалением данных или любыми изменениями вне репозитория
4Отчёт: изменённые файлы, точные пройденные проверки, оставшийся риск

Такой маленький контракт даёт верификатору что-то конкретное для проверки. А модели — причину остановиться. Размытая инструкция «ревьюй до идеала» может превратить проходящее изменение в очередной платный цикл

Для длинных проектов держи чек-лист в файле, который переживёт сжатие контекста. Для сабагентов проси ведущего агента проверять их доказательства, прежде чем принимать отчёты. И если ты просил только идеи, скажи Claude не начинать писать код. Это границы воркфлоу, а не промпты в стиле «будь умнее»

Архитектура, которую я бы выкатил первой

• Выбери 10–30 реальных задач и определи проверку для каждой
• Прогони свип Sonnet 5.5 на medium и high, затем Opus 5.5 на medium
• Логируй новый ввод, вывод, записи в кэш, чтения из кэша, задержку, ретраи и статус pass/fail по каждой задаче
• Держи стабильный префикс пригодным для кэширования и подтверждай попадания в usage
• Маршрутизируй наверх только провалы, прикрепляя их доказательства
• Пересматривай лестницу при изменении нагрузки. Сохранённый бенчмарк — не истина в последней инстанции

Если сложные 10% раз за разом идут от провала на Sonnet сразу к успеху на Opus, подумай о том, чтобы изначально маршрутизировать этот узнаваемый класс задач в Opus. Если Sonnet high справляется с теми же кейсами дешевле — оставляй их там. Роутер — это измеренная политика, а не вечное мнение о том, какая модель умнее

Обновление до 5.5 — это не просто «используй Sonnet для дешёвой работы, а Opus для сложной»

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

Если дочитал до сюда

-> Подписывайся на мой Substack

-> Заходи в мой Telegram

-> Добавь эту статью в закладки

-> Подписывайся на @0xwhrrari