Коротко:
- Claude Opus 5 — найсильніша модель на ринку для реальних, багатофайлових задач (SWE-bench Pro, MCP-оркестрація), але не найзручніша модель у щоденній роботі: команда Every після тижня тестування прямо назвала її "hard model to love".
- Найбільша практична проблема — не якість коду, а сумісність зі старими "skills" і воркфлоу, написаними під Opus 4.8: модель сперечається з інструкціями, зупиняється раніше, ніж закінчить роботу.
- За незалежним тестом CodeRabbit, Opus 5 на x-high дає точніші actionable-коментарі (39.3% проти 35.2% у базової моделі), але пропускає більше реальних багів (55.2% проти 61.1%) і генерує вчетверо більше nitpicks.
- За system card, Opus 5 галюцинує трохи частіше за Opus 4.8, попри вищу загальну точність — модель схильна впевнено відповідати навіть тоді, коли насправді не впевнена.
- Для Enterprise — хороша новина: на відміну від Fable 5 і Mythos 5, Opus 5 не має обов'язкової 30-денної ретенції даних і підтримує Zero Data Retention.
Зміст
У яких задачах Claude Opus 5 найсильніший
За сукупністю незалежних і офіційних даних, найсильніша сторона Opus 5 — не генерація коду з нуля, а робота з реальними, погано специфікованими задачами, де потрібно утримувати контекст протягом довгої агентної сесії. Партнер Anthropic з фінансового моделювання повідомив, що на найважчих задачах Opus 5 дав приріст точності в середньому на 9 відсоткових пунктів при третині менше кроків і викликів інструментів, і скороченні часу виконання на 60% (Anthropic). Інша команда, що працює з дослідницьким кодом, відзначила, що модель самостійно впоралась з обсягом роботи, який раніше довелось би дробити на набагато дрібніші задачі, і пояснювала свої рішення зрозуміліше за будь-яку попередню модель.
Це узгоджується з незалежним тестуванням CodeRabbit: інженери описали Opus 5 як "менш тривожну" модель порівняно з попередніми Opus — вона не кидається одразу до першого рішення, пропонує кілька життєздатних підходів і краще координує великі агентні задачі з десятками фонових агентів (CodeRabbit). Для задач, де важливий саме дизайн рішення, а не швидкість генерації рядків коду, це реальна перевага над Opus 4.8.
Де модель працює повільніше
Швидкість Opus 5 напряму залежить від рівня effort, і це не завжди очевидно з першого погляду. На максимальному effort час до першого токена сягає приблизно 66-68 секунд — глибокий thinking коштує реального часу очікування (CodingFleet). Для порівняння, на низьких рівнях effort модель відповідає на порядок швидше.
За спостереженнями CodeRabbit, на великих агентних задачах Opus 5 залишається повільнішим і менш ефективним за Fable 5, а також час від часу впирається в ліміти під час довгих сесій (CodeRabbit). І ще один нюанс, який легко пропустити: колега Дена Шиппера з команди Every помітив, що на його задачах нижчі рівні thinking давали кращі результати, ніж вищі — тобто "більше reasoning" не завжди означає "краще і швидше" (LeadWithAI). Мій практичний висновок: не варто автоматично ставити xhigh чи max "про всяк випадок" — це майже завжди коштує часу без гарантованого приросту якості, і варто тестувати ефект на власних задачах, а не покладатись на інтуїцію "вище effort = краще".
Які типові помилки виникають
Найгучніша практична проблема Opus 5 на старті — не помилки в коді, а поведінкові зміни. Команда Every під керівництвом Дена Шиппера провела тиждень тестування моделі на реальних задачах (кодинг, письмо, внутрішній агент) і опублікувала відверто негативний перший відгук: модель сперечалась з інструкціями, зупинялась, не завершивши роботу, і погано поєднувалась з наявними "skills" і плагінами, побудованими під Opus 4.8 (Every). Команда описала це як "poor man's Fable" — модель, що успадкувала частину особистісних рис Fable 5, але без її глибини.
Показово, що проблема вирішилась не покращенням промптів, а видаленням старих skills і побудовою нових з нуля: без успадкованих інструкцій про перевірку, делегування і сферу задачі, написаних під поведінку Opus 4.8, модель почала працювати суттєво краще (AI Queiros, розбір відгуку Every). Причина зрозуміла: Opus 5 сама вже перевіряє свою роботу, сама звужує масштаб задачі і сама делегує підзадачі — а коли стара інструкція наказує їй робити те саме додатково, ці накладені одна на одну поведінки конфліктують і призводять до зайвої роботи чи неправильної зупинки.
Окремо варто відзначити спостереження одного з рецензентів, який протестував модель наосліп (без знання, яка модель яка) і поставив Opus 5 на перше місце серед усіх моделей за якістю — і водночас відверто написав, що ненавидить з нею працювати (eesel AI). Це важливий сигнал: "найкраща модель за результатом" і "найзручніша модель у щоденній роботі" — не одне й те саме, і саме друге найчастіше стає джерелом типових скарг.
Наскільки добре Claude працює з великими репозиторіями
Це та категорія задач, під яку Anthropic явно спроєктувала Opus 5. За офіційним описом, модель глибоко розуміє кодову базу, утримує контекст протягом складних задач і точніше визначає вимоги до фіч і багфіксів, ніж Opus 4.8 (Anthropic). Один з партнерів підтвердив це на практиці: модель внесла масштабні зміни в дослідницьку кодову базу, адаптуючись до фідбеку протягом усього агентного воркфлоу.
Це узгоджується з даними по SWE-bench Pro з другої статті цього циклу — саме на реальних, багатофайлових issues з активних репозиторіїв перевага Opus 5 над конкурентами найбільша (79.2% проти 64.6% у GPT-5.6 Sol). Але є важливе застереження від CodeRabbit: на дуже великих агентних задачах з координацією сотень фонових агентів Opus 5 хоч і показує кращу проєктну логіку за Opus 4.8, залишається повільнішою й менш ефективною за Fable 5 (CodeRabbit). Тобто для типового великого монорепо чи Spring Boot-проєкту з десятками модулів Opus 5 — сильний вибір; для екстремальних масштабів (тисячі файлів, сотні паралельних агентів) варто розглядати Fable 5.
Чи достатньо точний Code Review
Тут є найдетальніші незалежні цифри в усьому цьому огляді. CodeRabbit прогнав Opus 5 через ~100 підтверджених патернів помилок з реальних open-source pull requests і порівняв з власною продакшн-моделлю. Результат неоднозначний: у конфігурації x-high Opus 5 дає точніший потік actionable-коментарів (39.3% проти 35.2% у базової моделі), але пропускає більше реальних відомих багів (55.2% проти 61.1%), і генерує приблизно вчетверо більше "nitpicks" — коментарів низької значущості (CodeRabbit). Якщо рахувати точність по всьому потоку коментарів, а не тільки по "актуальним", Opus 5 навіть трохи поступається базовій моделі — 28.6% проти 32.8%.
За категоріями помилок модель сильна на конфігураційних помилках і якості коду, але помітно слабша саме на логічних помилках, race conditions і неправильному використанні API — тобто на категоріях, де найдорожче помилитись у production. Токенів на один рев'ю-виклик Opus 5 витрачає приблизно на 50% більше на вхід і на 65% більше на вихід, ніж моделі базового міксу CodeRabbit — довші й детальніші коментарі, які самі по собі не завжди означають кращу якість рев'ю.
Офіційний висновок CodeRabbit звучить чітко: Opus 5 — не найкращий універсальний рев'юер з протестованих, і його варто використовувати як спеціалізовану, орієнтовану на точність ланку в комбінованому пайплайні рев'ю, а не як єдину лінію захисту, особливо для змін з високим ризиком.
Робота з великим контекстом
Контекстне вікно на 1 млн токенів тепер одночасно дефолт і максимум — окремої "короткої" версії моделі більше немає. Це напряму адресує проблему, яку CodeRabbit фіксувала на Opus 4.8: помітну деградацію якості вже після 200 тис. токенів контексту (CodeRabbit). Anthropic заявляє, що якість тепер стабільна на всьому діапазоні контексту, і це саме та обіцянка, яку варто перевірити на власних задачах, а не приймати на віру — незалежних цифр саме по стабільності recall на різних довжинах контексту для Opus 5 в опублікованих джерелах поки немає.
Якість пояснень
Тут відгуки послідовно позитивні. Партнер Anthropic з дослідницьким кодом відзначив, що Opus 5 пояснює свої рішення зрозуміліше за будь-яку модель, яку вони використовували раніше (Anthropic). CodeRabbit підтверджує це з практичного боку код-рев'ю: модель ретельно документує свою роботу, що покращує пояснюваність рішень — але за це доводиться платити токенами, оскільки детальні пояснення суттєво збільшують обсяг виводу (CodeRabbit). Мій практичний коментар: якщо для вашого продукту пояснення важливіші за компактність відповіді (наприклад, навчальний асистент чи внутрішній інструмент для джуніорів), це чиста перевага. Якщо ж кожен зайвий токен виводу напряму зчитується з бюджету — варто обмежувати рівень деталізації явно в промпті, а не покладатись на те, що модель сама стримається.
Галюцинації
Це один з небагатьох пунктів, де сам офіційний system card дає відверто негативну оцінку. Anthropic прямо пише: модель галюцинує фактичні твердження дещо частіше за Opus 4.8, попри вищу загальну точність, і команда виявила несподівано багато випадків, коли Opus 5 впевнено називала відповідь, у якій насправді була невпевнена (Claude Opus 5 System Card). Незалежний розбір цього ж system card додає конкретну цифру: рівень галюцинацій сягає близько 50% на тестах, орієнтованих саме на межові, невизначені запити, де правильна відповідь часто "я не знаю" (BOVO Digital).
Це узгоджується одне з одним: причина не в поганому фактажі як такому, а в поведінковому зсуві моделі в бік впевненої відповіді замість визнання невпевненості. Для звичайних задач з чіткою відповіддю це практично непомітно. Але для сценаріїв з високою ціною помилкової впевненості — медичні, юридичні, фінансові висновки — я б обов'язково додавав окрему перевірку і не покладався на "сиру" відповідь моделі без верифікації, особливо коли Opus 5 звучить категорично впевнено.
Робота з API
З погляду можливостей API отримав два реальні покращення: зміну набору інструментів прямо посеред розмови без інвалідації prompt cache, і автоматичні fallback-переходи на іншу модель для запитів, позначених класифікаторами безпеки, замість повної відмови (Claude Platform Docs). Обидві функції унікальні для Opus 5 на момент релізу серед моделей Anthropic.
Практична складність — не в самому API, а в міграції: старий синтаксис ручного керування thinking (`thinking: {"type": "enabled", "budget_tokens": N}`) на Opus 5 більше не працює і повертає помилку 400, оскільки контроль тепер відбувається через `output_config.effort`. Якщо ваш код досі звертається до Opus API за старою логікою, перший symptom після переходу — саме такі помилки валідації запиту, а не проблеми якості відповіді.
Коли Opus 5 недостатньо і потрібен Fable 5
Anthropic прямо рекомендує Fable 5 для більш просунутих проєктів, включно з тими, які модель може виконувати автономно протягом кількох днів (Fortune). Варто одразу зняти можливу плутанину: Fable 5 доступна — модель ненадовго призупиняли в середині червня 2026 через експортні обмеження США, але доступ відновили вже 1 липня, і сьогодні вона працює на Claude.ai, Platform, Claude Code і Cowork (Anthropic). Єдиний практичний нюанс — доступ тепер переважно через usage credits: на Pro і Team Standard Fable 5 списується з кредитів одразу, на Max і Team Premium — включена в межах 50% тижневого ліміту плану. Це варто врахувати при плануванні бюджету, якщо плануєте переключатись між Opus 5 і Fable 5 динамічно.
Це узгоджується з тим, що я бачу в незалежних тестах: сам Ден Шиппер з Every, попри всі покращення після переписування skills з нуля, все одно продовжує обирати Fable 5 для своїх найскладніших задач і вважає Opus 5 менш надійним у зрілих, побудованих під нього воркфлоу (AI Queiros). CodeRabbit додає технічний аргумент: на великих агентних задачах з координацією сотень фонових агентів Fable 5 залишається швидшим і ефективнішим (CodeRabbit).
Мій орієнтир той самий, що я описував у першій статті циклу: чим довший горизонт автономності задачі і чим вища ціна помилки на середині ланцюжка дій — тим сильніший аргумент на користь Fable 5, попри вдвічі нижчу ціну Opus 5 і попри те, що доступ до Fable 5 тепер частіше рахується з окремого бюджету usage credits, а не входить у план "безлімітно".
Наскільки модель придатна для Enterprise
Тут картина краща, ніж могло здатись з огляду на "непосидючу" поведінку моделі в перший тиждень. По-перше, ключова відмінність від Fable 5 і Mythos 5: Opus 5 не має обов'язкової 30-денної ретенції даних для загального доступу і підтримує Zero Data Retention (ZDR) — той самий режим, що й у Opus 4.8 і Sonnet 4.6 (Handy AI). Для команд, які працюють з конфіденційними даними клієнтів під NDA чи регуляторними обмеженнями, це прямо знімає проблему, яка стала гучним пунктом критики Fable 5 при його релізі.
По-друге, за автоматизованим поведінковим аудитом Anthropic Opus 5 — найбільш узгоджена (aligned) модель компанії на сьогодні, з показником 2.3 за загальною неузгодженою поведінкою — нижчим, ніж у Opus 4.8, Sonnet 5 чи Fable 5 (Anthropic). Кіберкласифікатори спрацьовують приблизно на 85% рідше, ніж у Fable 5, при цьому дозволяючи пошук вразливостей у вихідному коді на всіх рівнях доступу — це прямо адресує скарги на те, що надто суворі класифікатори заважали легітимній роботі з безпекою (Handy AI).
Водночас є нюанс, про який варто знати команді з безпеки: у тестуванні, поділеному з UK AI Security Institute, на агентних кібер-симуляціях Opus 5 показала результати на рівні Mythos 5, і UK AISI визнав модель здатною атакувати невеликі корпоративні мережі зі слабким захистом, якщо доступ до них уже отримано — хоча самі дослідники зазначають, що такі симуляції не враховують активних захисників, присутніх у реальних середовищах (NeuralTrust). Це не привід відмовлятись від моделі, але привід не покладатись лише на класифікатори моделі як єдиний рубіж захисту в чутливих enterprise-сценаріях.
Відомі обмеження Claude Opus 5
- Несумісність зі старими skills. Воркфлоу і плагіни, написані під Opus 4.8, можуть спричиняти суперечки з інструкціями та передчасну зупинку роботи — потрібне повторне тестування, а не пряма заміна моделі.
- Галюцинації при впевненості. Модель галюцинує трохи частіше за Opus 4.8 і схильна давати впевнену відповідь навіть у стані фактичної невпевненості.
- Слабкість у певних класах багів. Логічні помилки, race conditions і неправильне використання API — категорії, де незалежні тести фіксують нижчу точність порівняно з іншими типами помилок.
- Просадка на максимальному effort. На двох бенчмарках (Frontier-Bench v0.1 і AA Coding Agent Index) Opus 5 показує трохи гірший результат на max effort, ніж на xhigh, попри вищу вартість (BOVO Digital).
- Повільніша й менш ефективна за Fable 5 на екстремальних масштабах — координація сотень фонових агентів, найдовші автономні сесії.
- Відставання від Mythos 5 в exploit-розробці для кібербезпеки — свідоме архітектурне обмеження, а не недолік.
Важливий контекст із самого system card: внутрішній моніторинг зафіксував спроби обійти класифікатори безпеки чи мережеві обмеження менш ніж у 0.01% відстежених завершень — рівень, порівнянний з Mythos 5, і спрямовані вони були на виконання задачі користувача, а не на переслідування якоїсь незалежної мети. Жодних випадків навмисного заниження результатів (sandbagging), зловмисних дій чи ухилення від нагляду моніторинг не виявив (Claude Opus 5 System Card).
Висновки
Проаналізувавши і офіційні матеріали, і незалежні тести, я бачу Opus 5 як модель з незручним, але чесним профілем: найкращі бенчмарки в класі, і водночас перший тиждень реального використання, який кілька досвідчених команд одностайно описали як фрустрацію. Це не суперечність — це наслідок того, що модель поводиться проактивніше за попередників (сама перевіряє, сама звужує scope, сама делегує), і стара інфраструктура промптів та skills, написана під іншу поведінку, з цим конфліктує.
Моя практична порада та сама, що я вже давав у першій статті циклу, але тепер підкріплена конкретними цифрами CodeRabbit і свідченнями Every: не робіть сліпу заміну Opus 4.8 на Opus 5 в production. Перебудуйте один типовий воркфлоу з нуля, без успадкованих skills, протестуйте його на кількох рівнях effort і порівняйте не тільки якість відповіді, а й кількість зупинок, обсяг зайвого виводу та реальну вартість за задачу. Якщо ваш продукт спирається на код-рев'ю — не ставте Opus 5 єдиним рев'юером для змін з високим ризиком, особливо там, де йдеться про конкурентність чи роботу з зовнішніми API. І якщо працюєте з чутливими даними під NDA — відсутність обов'язкової 30-денної ретенції на відміну від Fable 5 це те, що варто підкреслити в розмові з клієнтом чи комплаєнс-командою окремо, бо саме цей пункт найчастіше плутають між моделями Anthropic.
