Більшість релізів моделей супроводжує таблиця бенчмарків і допис у блозі. 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 описує результати раннього чи проміжного знімка моделі, а не випущеної версії, це зазначено в тексті.