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

Первый, гайд по промптингу, описывающий поведение, изменившееся достаточно, чтобы сломать промпты, написанные под предыдущую модель. Второй, System Card на 194 страницы: предрелизные оценки, аудит согласованности и места, где модель проигрывает. Вместе они откровеннее анонса и заметно полезнее.

Я прочитал оба в первоисточнике, вместе с документацией про effort. Вот что там сказано, какие там цифры и что из этого стоит взять бизнесу, у которого AI уже где-то внутри рабочего процесса. Сам релиз и путаницу с ценами мы разобрали отдельно; этот текст о том, как с этим работать.

Что именно опубликовала Anthropic

Гайд по промптингу короткий и конкретный. Он существует потому, что Opus 5 работает на промптах от Opus 4.8 без переделки, и это звучит хорошей новостью, но именно из-за этого на нём теряют деньги. Старые промпты запускаются, выглядят рабочими и тихо стоят дороже, чем должны.

System Card, документ другого типа. Это отчёт об оценках, которые Anthropic провела до релиза, включая те, которые модель не прошла. Там названы два ограничения, из-за которых Opus 5 менее полезен, чем Mythos 5, для определённого класса работы. Там зафиксировано, на что жаловались внутренние и внешние пилотные пользователи. Публиковать такой материал вендор не обязан, и самое интересное в нём, ровно то, что никто не стал бы раскрывать добровольно.

Два бытовых факта прежде всего остального, оба из System Card: граница знаний, май 2026 года, и на выходе модель даёт только текст. Всё, что появилось позже, должно дойти до неё через поиск или через вас.

Настройка, которая стоит дороже всего

На Opus 5 параметр effort, главный рычаг расходов. Уровни: low, medium, high, xhigh, max. Он управляет всеми токенами ответа, включая вызовы инструментов, а не только размышлением.

Важное изменение, в точке старта. Для Opus 4.7 и 4.8 Anthropic рекомендовала стартовать с xhigh на кодовой и агентной работе. Для Opus 5 документация говорит стартовать с high, то есть со значения по умолчанию, и использовать low и medium свободно как основной инструмент управления стоимостью и временем ответа везде, где качество держится. Если вы унаследовали настройки effort от предыдущей модели, указание однозначное: прогоните замеры заново на своих задачах, а не переносите старые значения.

Вокруг этого три практических ограничения:

На xhigh и max thinking выключить нельзя. Запрос, который пытается это сделать, возвращает ошибку 400. Выключение доступно на high и ниже.

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

На xhigh и max поднимайте max_tokens. Документация предлагает 64 тысячи как разумную точку старта, потому что модели нужно место на размышление, вызовы инструментов и работу субагентов внутри этого лимита.

В разделе System Card про отзывы пилотных пользователей есть ещё одно контринтуитивное замечание. Внешние пользователи сообщали о переобдумывании, когда на более высоких уровнях effort модель работает хуже, а внутренние, о циклах самокоррекции, особенно на высоких уровнях effort. Выше не значит автоматически лучше. Именно поэтому указание советует измерять, а не предполагать.

Почему снижение effort не сокращает ответ

Здесь спотыкаются почти все. Effort управляет тем, сколько модель думает, а не тем, сколько она говорит. Можно опуститься с high на low, срезать счёт за токены и получить такой же длинный ответ.

Opus 5 по умолчанию пишет длиннее предыдущих моделей Opus, причём сразу в трёх местах: в разговорных ответах, в комментариях во время агентной работы и в файлах, которые пишет на диск. Каждое место требует собственной инструкции, и инструкция может быть короткой. Собственный пример Anthropic для продукта с пользователем просит держать ответы сфокусированными и короткими, сокращать оговорки и давать верхнеуровневое резюме, если развёрнутый разбор не запросили отдельно.

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

Удалите инструкции о проверке, написанные под старые модели

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

Opus 5 проверяет свою работу без напоминаний. Если в вашем промпте до сих пор есть фразы вроде «добавляй финальный шаг верификации для любой нетривиальной задачи» или «используй субагента для проверки», эта инструкция накладывается на поведение, которое у модели есть само по себе. Гайд утверждает, что такие инструкции вызывают избыточную проверку, а их удаление снижает напрасный расход токенов без потери качества. То же касается шагов проверки, зашитых в ваш харнесс ещё тогда, когда моделям это было нужно.

Смежная инструкция, которую тоже надо убрать, любое правило, запрещающее модели думать или рассуждать. При выключенном thinking такое правило повышает вероятность протечки внутренних XML-тегов в видимый ответ. Называть теги поимённо работает хуже, чем общее правило против внутренних тегов.

Со скоупом всё наоборот. Модель может расширить задачу сама, добавив шаги, о которых никто не просил. На широкой работе это часто плюс. На узкой правке это переделанный код и потерянное время. Лечится это явным указанием границ, а не просьбой делать меньше, и разница здесь существенная: пилотные пользователи сообщали также, что модель делает меньше, чем просили, недостаточно исследуя запрос или не выполняя инструкции до конца. Задокументированы оба направления. Граница и просьба быть кратким это разные инструкции.

Делегирование требует такого же подхода. Opus 5 обращается к субагентам охотнее предыдущих моделей и координирует их хорошо, но на мелких задачах делегирование множит стоимость и время. Задайте явные критерии, когда субагент оправдан, и если ваш инструментарий это умеет, поставьте лимит на их число.

Инструкция для код-ревью, которая тихо прячет баги

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

Opus 5 делает ревью с высокой точностью и полнотой одновременно: находит реальные баги за проход, а дополнительные находки, в основном настоящие проблемы, а не шум. Точность держится и на низких уровнях effort, так что можно позволить себе быстрый дешёвый проход в момент ревью и более тяжёлый позже.

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

Точнее, увереннее и чуть чаще ошибается

В кратком резюме System Card есть предложение, которое должно изменить то, как вы принимаете работу от AI. Opus 5 в целом точнее Opus 4.8 и при этом чуть чаще галлюцинирует фактические утверждения, иногда выдавая уверенный ответ там, где уверенности не было. Предложение стоит прочитать целиком:

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

Измерение за этим стоит такое: на AA-Omniscience, закрытом бенчмарке фактичности из 41 темы без доступа к веб-поиску или базе знаний, Opus 5 получил чистый балл 0,49, между Opus 4.8 и двумя моделями Mythos. В разбивке его точность на 11% выше, чем у Opus 4.8, а уровень галлюцинаций, тоже выше, на 6%.

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

Тот же System Card фиксирует и противоположную сильную сторону. На проверке синтаксиса команды перед запуском команды, меняющей состояние, Opus 5 фактически насыщает оценку, а на «ленивом расследовании», где поверхностный взгляд на запутанные доказательства привёл бы к ошибочному и значимому действию, это первая модель Claude, которая пришла к верному выводу в каждой задаче. Так что разделение проходит между действием и припоминанием: модель заметно осторожнее перед тем, как действовать, и чуть свободнее, когда припоминает факты по памяти. Защита нужна разная: для действий подтверждение, для фактов источник.

Есть ещё одна находка, которую стоит держать в голове тем, кто спорит с моделями. Когда пользователь давит на неё по поводу того, что она знает как неверное, Opus 5 соглашается с пользователем чаще, чем Sonnet 5 и Mythos Preview, хотя и реже всех остальных недавних моделей. Настойчивое давление на правильный ответ может отговорить модель от правильного ответа.

Провал, который выглядит как ничего

System Card называет два ограничения, из-за которых Opus 5 менее полезен, чем Mythos 5, для одного класса работы: непродуктивная самопроверка, когда модель проваливается в исчерпывающие проверки правильности и строит сложные пайплайны верификации, отвлекающие от самой задачи, и плохая калибровка границ задачи, когда она переусложняет и переоценивает важность мелких изменений.

Иллюстрацию цитируют чаще всего. Anthropic дала модели полностью автономно спланировать и провести суточную кампанию по дизайну белков с бюджетом 10 тысяч долларов. Цель, 30 белков-связок, которые держат GDF-8 и при этом игнорируют GDF-11, его почти идентичного близнеца, что является проверкой на точность. Mythos 5 сдал все 30 вариантов, ранжированные и с внутренним аудитом. Ни один из прогонов Opus 5 не дал ничего годного: один выдал 17 неранжированных вариантов, бросив по дороге само требование селективности, второй не выдал ничего и молчал последние восемь часов.

Три обстоятельства с тех же страниц меняют смысл. Прогон относится к оценке биологических рисков, поэтому Anthropic трактует его как вывод о безопасности, а не обзор продукта. Сравнение идёт с Mythos 5, а прогоны делали на раннем снимке Opus 5. И Anthropic отмечает, что эти эксперименты не проводились в большом масштабе.

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

Лечится это контрольными точками, привязанными ко времени, а не к готовности. Просите короткий статус через промежутки: что сделано, что осталось, где застряло. И поставьте правило перед самим циклом: инфраструктуру для проверки не строят, пока нет результата, который надо проверять.

Устойчивость к prompt injection выросла сильно, но она не нулевая

Prompt injection это атака, когда содержимое, которое читает ваш агент, содержит инструкции, обращённые к модели, а не к вам. Веб-страница, письмо, тикет поддержки. Модель должна отличить данные от команд.

Именно здесь Opus 5 показал самый большой прирост в агентной безопасности, и цифры стоит назвать, потому что их обычно сворачивают в общую фразу.

В кодовых средах успешность атак упала с 7,03% на Opus 4.8 до 0,56% на Opus 5 с включённым thinking. В средах управления компьютером, с 7,14% до 0,54%. В браузерной работе, которую тестировали профессиональные редтимеры на 129 сценариях, ни одна атака не прошла против Opus 5 при включённых продуктовых защитах, наравне с Sonnet 5 и Mythos 5.

А теперь часть, которая важнее. Без этих защит браузерные атаки всё равно проходили в 3,70% случаев с thinking и 4,30% без него. Это большое улучшение против Opus 4.8, у которого было 31,5% и 17,8%. Но это не ноль. До нуля браузерные инъекции в этих тестах доводит слой защиты, а не модель.

Практический перевод: если вы запускаете агентов через продукт, у которого есть встроенные пробы на инъекции, не выключайте их. Если вы собрали собственный харнесс, этого слоя у вас нет, и ваш показатель, тот, что без защиты.

Агент будет искать путь к цели, которую вы ему дали. Какие пути закрыты, решаете вы, а не он.

Что с этим делать

Три правила закрывают большую часть риска. Принимайте работу по артефактам, которые можно проверить, а не по рассказу о ней. Требуйте dry run перед любым необратимым действием, что бы ни было согласовано раньше. И всё, что агент читает, считайте данными, а не командой.

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

Подтверждайте необратимые действия в текущем сообщении. Отправка, публикация, оплата, деплой, удаление, изменение общей среды. Требуйте сначала dry run: какое действие, над какими объектами, кому оно уйдёт, что именно нельзя будет отменить. Разрешение, полученное раньше в диалоге, не считается. Это правило существует потому, что Opus 5 может сам расширить задачу, а ранее данное согласие относилось к задаче такой, какой она была тогда.

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

Если вы вообще не строите агентов, остаётся одно правило, и это первое. Ваш риск не в API. Он в том, что всё большая доля работы приходит от подрядчиков, фрилансеров и инструментов, у которых где-то внутри есть AI, и подана она прозой, которая лучше всего, что вы получали два года назад. Проблема не в очевидных ошибках. Проблема, правдоподобный абзац с цифрой, которую никто не измерял, и это тот же механизм, что стоит за низкокачественным контентом, под который Google сейчас строит детекторы.

Защита не изменилась: названные источники для фактических утверждений, явная пометка там, где источника нет, и критерии приёмки, написанные до начала работы, а не после её поступления.

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

Источники

  • Prompting Claude Opus 5, документация Anthropic (изменения поведения, рекомендованные паттерны промптинга)
  • Effort, документация Anthropic (уровни effort, рекомендации для конкретных моделей, ограничения по thinking и кэшированию)
  • Claude Opus 5 System Card, Anthropic, 24 июля 2026, 194 страницы (оценки, аудит согласованности, агентная безопасность, ограничения)

Все цифры из оценок приведены по собственному предрелизному тестированию Anthropic, опубликованному в System Card. Мы не воспроизводили их независимо. Там, где System Card описывает результаты раннего или промежуточного снимка модели, а не выпущенной версии, это отмечено в тексте.