Коротко. Я прочитав реакцію на Sonnet 5 за перші два тижні після релізу — від Reddit-тредів до розборів незалежних тестувальників — і картина виявилась не такою простою, як "модель погана" чи "модель хороша". Найбільше задокументована проблема — не якість, а прихована вартість: агентна модель, що "думає" субагентами, з'їдає в рази більше токенів, ніж здається з прайслиста. Є й поведінкові збої — впертість, зациклення на субагентах, надмірні відмови. Але значна частина launch-week обурення тижнем пізніше сама себе спростувала в хендс-он тестах.
Загальний огляд можливостей Sonnet 5 і офіційно заявлені обмеження я вже розбирав у pillar-статті. Тут — тільки те, що не потрапляє в прес-релізи: реальні скарги, задокументовані тести й моя спроба відділити системну проблему від шуму перших днів.
Зміст
- Прихована вартість: чому дешевша модель може коштувати дорожче
- Надмірна фрагментація задач на субагентів
- Надмірна відмова виконувати легітимні задачі
- Впертість, суперечки й ігнорування інструкцій
- Втрата контексту на початку розмови
- Галюцинації там, де їх важко помітити
- Що каже сама Anthropic
- Launch-week паніка проти тижневого досвіду
- Часті запитання
Прихована вартість: чому дешевша модель може коштувати дорожче
Це найкраще задокументована й, на мою думку, найважливіша проблема з усіх, що я знайшов. На папері Sonnet 5 виглядає дешевшою угодою за Opus 4.8. Але незалежний трекер Artificial Analysis виміряв реальну вартість виконання типової задачі зі свого Intelligence Index — і отримав $2,29 за задачу на Sonnet 5 за стандартною ціною, тоді як Opus 4.8 обійшовся в $1,97, а попередник Sonnet 4.6 — приблизно в $1,20.
Причина подвійна. Перша — новий токенізатор, який перетворює той самий текст на приблизно на 30% більше токенів — сам Anthropic визнає це в документації й прямо каже, що стартова ціна підібрана так, щоб компенсувати цей ефект, а це вже само по собі визнання, що номінальна ціна за токен не відображає реальну вартість. Друга, і за оцінкою Artificial Analysis більша причина — агентна поведінка моделі: на максимальному рівні зусиль Sonnet 5 спалює приблизно на 40% більше вихідних токенів на задачу, ніж Sonnet 4.6, а на агентних бенчмарках виконує приблизно втричі більше циклів "агент-дія" за задачу.
Чому це важливо. Якщо ви плануєте бюджет виключно за цінником $2/$10 чи навіть $3/$15 за мільйон токенів, ви рахуєте не той показник. Правильна одиниця виміру — вартість за завершену задачу, а не за токен, і саме тут "дешевша" модель на практиці виявилась дорожчою за флагманський Opus 4.8. Перед переходом варто прогнати невеликий набір реальних задач і порахувати фактичний рахунок, а не покладатись на прайслист.
Надмірна фрагментація задач на субагентів
Це конкретний, добре задокументований патерн збою, а не загальна скарга. Розробник Theo Browne опублікував розбір, у якому Sonnet 5 спожила $6 000 у витратах на бенчмаркінг — більше, ніж будь-яка інша протестована модель, — набравши лише 37% на приватних кодових тестах. За його спостереженнями, модель отримала нову для рівня Sonnet здатність автономно породжувати субагентів для паралельної роботи над задачею — раніше це вміла лише модель Fable 5. Але проблема саме в тому, що модель не завжди розуміє, коли ця здатність доречна: вона розбиває задачі, які не варто розбивати, і відправляє субагентів досліджувати питання, на які могла б відповісти сама.
Найпоказовіший приклад з того самого розбору: в одній задачі модель загубилась у циклах делегування й витратила 69 000 токенів там, де GPT-5.5 впорався за 5 000. В окремому тесті на відтворення браузерної гри Opus 4.8 виконав задачу одним проходом приблизно за 27 хвилин, тоді як Sonnet 5 із субагентною оркестрацією показав гірший результат.
Чому це важливо. Субагентна оркестрація — реальна нова здатність, а не маркетинговий трюк, і саме тому проблему варто розуміти правильно: це не "модель тупа", а "модель ще не навчилась добре оцінювати, коли делегування виправдане". Практичний висновок з цього розбору — не вважати Sonnet 5 моделлю "для розумного розв'язання задачі одним проходом", а розглядати її радше як делегованого субагента, викликаного розумнішим оркестратором, а не як основний робочий інструмент на столі розробника.
Надмірна відмова виконувати легітимні задачі
За тим самим розбором Theo Browne з посиланням на системну картку Anthropic, Sonnet 5 відмовляє в 92,3% явно шкідливих запитів — трохи краще, ніж попередні моделі, і це очікувано. Але показовіша цифра — на легітимних, проте на вигляд підозрілих запитах успішність виконання впала нижче 92%, тоді як у Sonnet 4.6 вона становила 97%. Тобто модель почала частіше відмовляти саме там, де відмовляти не варто.
Чому це важливо. Для продакшн-агента, що працює з реальними, іноді неоднозначно сформульованими запитами користувачів (наприклад запит на аналіз "підозрілого" фінансового документа, який насправді легітимний), кожна хибна відмова — це втрачена продуктивність, яку доведеться компенсувати або переформулюванням промпту, або фолбеком на іншу модель. Це варто протестувати саме на межових, а не очевидно "чистих" запитах з вашого домену, перш ніж покладатись на модель у продакшні.
Впертість, суперечки й ігнорування інструкцій
Тут я спирався на реальний Reddit-тред, задокументований оглядом Neowin. Найпоширеніша скарга — модель відмовляється виконувати прямі команди й замість цього входить у цикл заперечень і "сфабрикованих" незгод із користувачем. Автор огляду також описує власний досвід: модель вголос "згадує" зміст системного промпту в чаті — наприклад, замість того щоб просто не ставити уточнюючі питання (як було прописано в інструкції), вона починає відповідь фразою на кшталт "мені потрібно пам'ятати не ставити уточнюючих питань" — тобто озвучує інструкцію замість того, щоб мовчки її виконати.
У тому ж треді користувачі описують схожі проблеми в Opus 4.8, тобто це, можливо, не суто проблема Sonnet 5, а ширший поведінковий патерн останніх релізів Anthropic.
Чому це важливо. Для чат-інтерфейсів, де користувач очікує прямого виконання інструкції, а не "роздумів вголос", це погіршує сприйнятий досвід навіть якщо кінцевий результат технічно правильний. Якщо ваш продукт передає системний промпт із чіткими поведінковими правилами, варто протестувати саме дотримання цих правил на кількох реальних сесіях, а не покладатись на те, що модель "просто виконає інструкцію" без побічних коментарів.
