Claude Opus 5.5: цена, изменения API и переход с Opus 5
Anthropic выпустила Claude Opus 5.5 22 сентября 2026 года. Для команд, которые используют Opus 5 через Claude API, Claude Code или в системах с ИИ-агентами, релиз затрагивает не только цену и производительность. Изменились правила адаптивного мышления (thinking), вызова инструментов, передачи блоков рассуждения (thinking blocks) и управления компьютером (computer use).
Практический вывод: Opus 5.5 стоит тестировать уже сейчас на дорогих или длительных задачах программирования и в сценариях с ИИ-агентами, но переводить рабочий трафик только на основании тестов Anthropic преждевременно. Сначала запустите одинаковый набор реальных задач на Opus 5 и 5.5 и сравните долю успешных выполнений, задержку, расход токенов, работу кэша, вызовы инструментов, повторные попытки и время ручной доработки.
Цена Opus 5.5 и где переход может дать наибольший эффект
Начинать проверку Opus 5.5 рациональнее с процессов, где Claude уже выполняет многошаговую работу: анализирует большую кодовую базу, использует инструменты, выполняет длительные задачи, собирает и проверяет данные или участвует в рабочем процессе через API.
По документации Claude Opus 5.5 базовая цена составляет $4 за миллион входных и $20 за миллион выходных токенов. Для Opus 5 — $5 и $25 соответственно, то есть основные тарифы снизились на 20%. Anthropic также заявляет примерно 40% снижения стоимости типичной задачи при стандартных настройках за счёт более низкой цены и меньшего расхода токенов. Это оценка производителя для его тестовых сценариев, а не универсальное снижение стоимости API-запросов на 40%.
Контекст остаётся 1 млн токенов, максимальный обычный ответ — 128 тыс. токенов. Чтение из кэша подешевело с $0,50 до $0,20 за миллион токенов. Запись в кэш для Opus 5.5 стоит $5 за миллион токенов при TTL 5 минут и $8 при TTL 1 час; для Opus 5 — $6,25 и $10. Batch API даёт скидку 50% на входные и выходные токены.
Для обычных текстовых запросов, которые не зависят от thinking, инструментов и многошагового состояния разговора, переход может быть сравнительно простым. В системах с ИИ-агентами, маршрутизацией между моделями, вызовами инструментов и computer use Opus 5.5 нужно проверять как изменение интеграции, а не только как новый идентификатор модели.
thinking и значение effort по умолчанию. Источники: Anthropic — Claude Opus 5.5; Anthropic — Claude Opus 5.5 overview; Anthropic — Migrating to Claude Opus 5.Основные изменения Claude Opus 5.5
Anthropic позиционирует Opus 5.5 для длительных задач с ИИ-агентами, программирования и работы со знаниями. Идентификатор модели в Claude API — claude-opus-5-5. Модель также доступна через Amazon Bedrock, Google Cloud, Microsoft Foundry и Claude Platform on AWS.
| Параметр | Claude Opus 5 | Claude Opus 5.5 | Что это означает |
|---|---|---|---|
| Цена входных токенов | $5 / 1M | $4 / 1M | снижение на 20% |
| Цена выходных токенов | $25 / 1M | $20 / 1M | снижение на 20% |
| Запись в кэш, 5 минут | $6,25 / 1M | $5 / 1M | снижение на 20% |
| Запись в кэш, 1 час | $10 / 1M | $8 / 1M | снижение на 20% |
| Чтение из кэша | $0,50 / 1M | $0,20 / 1M | снижение на 60% |
| Контекст | 1M токенов | 1M токенов | объём контекста сам по себе не вырос |
| Максимальный обычный ответ | 128K токенов | 128K токенов | базовый лимит ответа не изменился |
Адаптивное мышление (thinking) |
включено по умолчанию; при high и ниже можно отключить |
адаптивное, всегда включено | thinking в 5.5 отключить нельзя |
effort по умолчанию |
high |
medium |
одинаковый запрос без явного effort может вести себя иначе |
Экономия и скорость: как читать цифры производителя
Снижение тарифов на входные и выходные токены на 20% не равно заявленной экономии около 40% на типичной задаче. Anthropic связывает больший эффект с тем, что Opus 5.5 в её тестах использует меньше токенов и шагов. Компания также сообщает, что выходные токены генерируются более чем на 30% быстрее, чем у Opus 5.
Обе оценки относятся к тестам производителя. В рабочей системе итоговая стоимость и время зависят от числа шагов рассуждения, вызовов инструментов, повторных попыток, попаданий в кэш и ручной проверки. Поэтому более низкий тариф может не дать экономии, если возрастёт число перезапусков или объём ручной коррекции; при сокращении лишних шагов и ошибок эффект, наоборот, может оказаться выше изменения прайс-листа.
Результаты тестов Opus 5.5 и их ограничения
В анонсе Claude Opus 5.5 Anthropic приводит результаты собственных тестов. В Terminal-Bench 4.0 указано 66,4% для Opus 5.5 против 52,3% для Opus 5, в CursorBench 4.0 — 57,8% против 46,6%. Эти тесты относятся к задачам агентного программирования.
Сама Anthropic предупреждает, что по мере роста возможностей моделей результаты тестов всё хуже отражают различия в реальной работе. Они описывают конкретную тестовую среду и не подтверждают такой же прирост на другой нагрузке.
Для рабочей системы эти цифры полезны как основание для собственного сравнения. Длина контекста, структура репозитория, набор инструментов, требования к точности, задержке и цене ошибки могут существенно изменить итог.
Opus 5.5 в программировании и длительных задачах
Релиз ориентирован прежде всего на длительную многошаговую работу. Anthropic и участники раннего доступа сообщают о меньшем числе шагов и токенов при работе с кодом, длительных миграциях, анализе больших кодовых баз и других сценариях с ИИ-агентами.
Это ранние данные самой Anthropic и компаний, участвовавших в тестировании, поэтому они не доказывают универсального преимущества модели. Практическая ценность определяется тем, меняются ли измеримые показатели конкретного процесса.
Если агент работает с терминалом, читает множество файлов и многократно вызывает инструменты, сокращение лишних шагов может одновременно повлиять на стоимость, время выполнения, вероятность сбоя и объём ручной проверки. Поэтому в первую очередь имеет смысл тестировать длинные задачи, где этот эффект можно измерить; на коротких запросах выигрыш может оказаться меньше стоимости самой миграции.
Риски совместимости при переходе с Opus 5
Для уже работающей интеграции ключевой вопрос — совместимость. В руководстве по миграции Anthropic выделяет четыре изменения, способные нарушить код, рассчитанный на Opus 5: thinking больше нельзя отключить, принудительный tool_choice не поддерживается, изменились правила передачи thinking blocks, а старый computer_20251124 ограничен на Claude API и Google Cloud. Отдельно нужно проверить поведенческие изменения, которые могут не вызывать ошибку API, но влиять на интерфейс и цикл автономного агента.
Отключить thinking больше нельзя
В Opus 5.5 адаптивное мышление всегда включено. Запрос с thinking: {"type": "disabled"} возвращает ошибку 400 при любом уровне effort. Глубина рассуждения регулируется параметром effort.
Эту миграцию важно отделять от более старого изменения API. Ручной режим thinking: {"type": "enabled", "budget_tokens": N} был удалён ещё в Opus 4.7 и уже не поддерживается в Opus 5. Поэтому при переходе именно с Opus 5 на 5.5 новое несовместимое изменение — невозможность отключить thinking. Параметр budget_tokens имеет смысл искать только в устаревшем коде, который раньше работал с Opus 4.6 или более ранними моделями.
Значение effort по умолчанию тоже изменилось: у Opus 5.5 это medium, у Opus 5 — high. Поэтому одинаковый запрос без явно заданного effort может вести себя иначе даже без ошибки API. Для корректного сравнения стоимости и качества параметр лучше задавать явно и проверять несколько уровней на одном наборе задач.
Принудительный tool_choice больше не поддерживается
Opus 5.5 не принимает tool_choice с типом any или с принудительно указанным tool: такой запрос возвращает 400 invalid_request_error. Поддерживаются auto и none.
Если приложение требовало обязательного вызова конкретного инструмента, этот участок нужно изменить до миграции. Anthropic рекомендует использовать auto вместе со строгой проверкой вызовов инструментов (strict tool use) или структурированным выводом (structured outputs) и явно описывать в промпте условия применения инструмента.
Thinking blocks: правила передачи состояния
Блоки рассуждения thinking blocks в Opus 5.5 связаны с моделью и конкретным состоянием разговора. Это влияет на системы, где запросы маршрутизируются между моделями или во время сессии меняются системный промпт, набор инструментов либо ранняя история сообщений.
Базовое правило интеграции — возвращать thinking blocks в следующие запросы полностью и без изменений: не редактировать и не переставлять уже сохранённые блоки. Если меняется модель, системный промпт, инструменты или ранняя история, совместимость такого сценария нужно проверять отдельно.
Маршрутизацию и резервное переключение между моделями стоит вынести в отдельный регрессионный сценарий. Для длительной сессии безопасная базовая стратегия — добавлять новые сообщения к истории, не переписывая уже сформированный префикс (append-only), если архитектура приложения это позволяет.
Computer use: совместимость зависит от платформы
На Claude API и Google Cloud Opus 5.5 не поддерживает старый тип computer_20251124. Для этих платформ Anthropic переводит интеграции на computer_toolset_20260801.
На Amazon Bedrock старый инструмент по текущей документации продолжает работать, поэтому требования зависят от платформы. Если система управляет браузером или интерфейсом через computer use, нужно проверять не только идентификатор модели, но и описание инструмента вместе с полным циклом работы агента.
Промежуточный прогресс и end_turn
В Opus 5 промежуточный текст между вызовами инструментов возвращался как обычные блоки text. В Opus 5.5 такие сообщения передаются в блоках thinking для обновлений прогресса. При стандартном thinking.display="omitted" их текст клиенту не возвращается. Приложение, которое использовало промежуточный текст как статус выполнения, из-за этого может выглядеть зависшим. Для кратких обновлений Anthropic предлагает thinking.display="updates" в соответствующем beta-интерфейсе.
Отдельный риск возникает в автономном цикле. В длительной задаче Opus 5.5 иногда завершает ход промежуточным текстовым сообщением с stop_reason: "end_turn", а не очередным вызовом инструмента. Если приложение воспринимает любой end_turn как завершение всей задачи, агент может остановиться раньше времени. Этот сценарий нужно отдельно проверять на длинных заданиях; Anthropic описывает его в рекомендациях по Opus 5.5.
Refusal: отдельная обработка отказов
Согласно рекомендациям Anthropic по Opus 5.5, модель использует дополнительные защитные классификаторы, в том числе для отдельных биологических, кибербезопасностных сценариев и попыток извлечения внутренних рассуждений. Отказ приходит как обычный ответ API с stop_reason: "refusal" и объектом stop_details, а не обязательно как транспортная ошибка.
Если система автоматически повторяет запрос или переключается на резервную модель, refusal нужно включить в регрессионные тесты. Клиент должен отличать отказ модели от сетевой ошибки, исчерпания токенов и обычного завершения задачи.
Матрица решения по переходу на Opus 5.5
Сценарий перехода определяется состоянием интеграции, наличием воспроизводимых тестов и ценой ошибки. Матрица ниже сводит исходные условия к практическому действию.
| Ситуация | Рекомендация | Что проверить в первую очередь |
|---|---|---|
| Длительные задачи программирования и сценарии с ИИ-агентами на Opus 5 дороги по токенам и времени | ТЕСТИРОВАТЬ СЕЙЧАС | успешность задачи, число шагов, токены, задержка, повторные попытки |
| Есть набор регрессионных и оценочных тестов и можно безопасно направить часть трафика на 5.5 | ПРОВЕСТИ A/B-ТЕСТ | одинаковый набор задач и одинаковые критерии успешности |
Используется принудительный tool_choice |
СНАЧАЛА ИЗМЕНИТЬ КОД, ПОТОМ ТЕСТИРОВАТЬ | новая схема вызова инструментов, строгий режим (strict tool use), ошибки 400 |
Используется computer_20251124 через Claude API или Google Cloud |
СНАЧАЛА ОБНОВИТЬ ИНСТРУМЕНТ | переход на computer_toolset_20260801 и цикл агента |
Есть маршрутизация между моделями с резервным переключением и сохранением thinking blocks |
A/B-ТЕСТ ДО РАБОЧЕГО ПЕРЕКЛЮЧЕНИЯ | переключение моделей, неизменность истории, резервный сценарий |
| Интерфейс показывает текстовый прогресс между вызовами инструментов | ПРОВЕРИТЬ ИНТЕРФЕЙС ДО МИГРАЦИИ | thinking.display, порядок блоков, потоковая передача |
| Автономный агент продолжает работу, пока не выполнит многошаговую задачу | ПРОВЕРИТЬ ЦИКЛ ЗАВЕРШЕНИЯ | stop_reason, промежуточный end_turn, критерий фактического завершения |
| Есть автоматическое резервное переключение или повторные попытки | ДОБАВИТЬ ТЕСТЫ НА refusal |
stop_reason: refusal, stop_details, политика повторов и резервного переключения |
| Текущий Opus 5 стабилен, цена процесса невелика, набора регрессионных тестов нет | ПОКА ОСТАТЬСЯ НА OPUS 5 | сначала создать воспроизводимый набор оценки |
| Цена ошибки высока и поведение модели критично для рабочей системы | СНАЧАЛА МАЛАЯ ДОЛЯ ТРАФИКА | небольшая доля трафика, резервная модель, откат, ручной контроль |
Если исходного уровня для сравнения нет, сначала зафиксируйте текущую долю успешных задач, стоимость и поведение Opus 5. Без этой базы невозможно надёжно оценить эффект после замены модели.
Проверка Opus 5.5 на собственных задачах
Для оценки Opus 5.5 нужен набор задач, который повторяет реальную рабочую нагрузку и заранее определяет, что считается успешным результатом.
- Выберите репрезентативные задачи: исправление бага, изменение нескольких файлов, подготовка отчёта, поиск по большой базе документов или операция ИИ-агента с несколькими инструментами.
- Для каждой задачи заранее зафиксируйте критерий успешности: тесты прошли, нужный файл создан, данные совпали с источником, оператор принял результат без правок и т. п.
- Запустите один и тот же набор на Opus 5 и Opus 5.5 с сопоставимыми настройками. Для 5.5 явно задайте
effort, поскольку значение по умолчанию отличается. - Измерьте задержку, входные и выходные токены, чтение и запись кэша, число вызовов инструментов, повторные попытки, ошибки,
refusalи долю успешно завершённых задач. - Добавьте стоимость ручной проверки и исправлений. Для B2B-систем она может быть значимее небольшой разницы в тарифе API.
- Проверьте граничные сценарии: резервное переключение, длинную историю, изменение набора инструментов, потоковую передачу, промежуточный
end_turnи восстановление после ошибок. - Если сравниваете несколько уровней
effort, учитывайте кэш отдельно: изменение верхнеуровневогоeffortмежду запросами может инвалидировать кэш промпта (prompt cache) и исказить сравнение стоимости. - Переводите рабочий трафик постепенно, начиная с контролируемой небольшой доли запросов и сохраняя возможность отката.
Стоимость успешной задачи как основная метрика
Для модели, встроенной в бизнес-процесс, полезнее оценивать стоимость полученного результата, а не только тариф за миллион токенов.
Методика B2B-Partners: стоимость успешной задачи = (токены модели + кэш + стоимость инструментов и выполнения + повторные попытки + время ручной коррекции) / число успешно завершённых задач
Это не формула Anthropic и не универсальный финансовый стандарт, а практический способ учитывать расходы, которых нет в цене одного токена.
Если Opus 5.5 расходует меньше токенов, но чаще требует повторного запуска или исправления человеком, выгода от более низкого тарифа может исчезнуть. Если одновременно сокращаются число шагов, ошибки и ручная доработка, экономия на успешно завершённой задаче может оказаться выше снижения тарифа.
Контрольный список перед переключением рабочей системы
Перед переводом рабочей системы на Opus 5.5 проверьте интеграцию по этому списку:
- идентификатор модели заменён на
claude-opus-5-5; - удалены запросы с
thinking: {"type": "disabled"}; - устаревший код отдельно проверен на
budget_tokens, если интеграция раньше поддерживала Opus 4.6 или более ранние модели; effortзадан явно и повторно протестирован;- клиент читает ответ по типу блока и не предполагает, что первый блок всегда
text; - нет зависимости от принудительного
tool_choice: any/tool; - вызовы инструментов проверены в режиме
autoи при необходимости в строгом режиме; thinking blocksвозвращаются без изменений, а маршрутизация между моделями проверена отдельно;- история разговора не переписывается без необходимости; сценарии изменения системного промпта и набора инструментов протестированы;
- старый
computer_20251124заменён там, где он больше не поддерживается; - потоковая передача и интерфейс прогресса проверены с блоками
thinkingдля промежуточных обновлений; - автономный цикл не принимает промежуточный
end_turnза гарантированное завершение всей задачи; - обработаны
stop_reason: "refusal"иstop_detailsв логике повторов и резервного переключения; - резервное переключение и откат протестированы;
- набор регрессионных тестов прогнан на тех же задачах, что и Opus 5;
- повторно измерены стоимость, задержка, доля успешных задач и объём ручной коррекции.
Что пока нельзя подтвердить
На день релиза опубликованных данных достаточно, чтобы подтвердить характеристики модели, цены и изменения, важные для миграции. Их недостаточно для вывода, что Opus 5.5 будет лучше Opus 5 во всех рабочих сценариях.
Большая часть количественных сравнений принадлежит Anthropic или компаниям, участвовавшим в раннем доступе. Сообщения о меньшем числе шагов и токенов полезны как исходные данные для проверки, но не заменяют независимый тест на собственной инфраструктуре.
Экономику одного агентного теста нельзя переносить на другой процесс без проверки. Результат зависит от effort, структуры промпта, размера контекста, работы кэша, набора инструментов, числа повторных попыток, резервного переключения и стоимости ручной проверки. До появления более широких независимых данных решение лучше принимать по собственному набору задач.
Вывод: переходить после проверки на собственной нагрузке
Claude Opus 5.5 — заметное обновление для команд, которые используют Claude в длительных задачах программирования и сценариях с ИИ-агентами. Базовые тарифы на входные и выходные токены снизились на 20%, чтение из кэша — на 60%. Anthropic также сообщает о меньшем расходе токенов и более чем 30-процентном ускорении генерации выходных токенов относительно Opus 5; эти два показателя основаны на тестах производителя и требуют проверки на собственной нагрузке.
Рабочую интеграцию нельзя переводить на 5.5 одной заменой claude-opus-5 на claude-opus-5-5. Всегда включённый thinking, другое значение effort по умолчанию, изменения tool_choice, правила передачи thinking blocks, совместимость computer use, промежуточные обновления, возможный end_turn внутри длительной задачи и ответы refusal могут изменить поведение существующей системы. Поэтому переход требует регрессионных тестов, проверки инструментов, резервного сценария и возможности отката.
Решение стоит принимать по результатам одинаковых реальных задач на Opus 5 и 5.5. Если новая модель снижает стоимость успешной задачи, время выполнения и объём ручной коррекции без новых регрессий, у миграции есть измеримое основание. Если такого эффекта нет, выпуск новой версии сам по себе не требует изменения рабочей системы.
Источники
Технические характеристики и изменения API проверены 23 сентября 2026 года по первичным источникам Anthropic: