Anthropic випустила Claude Sonnet 5 — майже як Opus 4.8, але дешевше
Anthropic представила Claude Sonnet 5 — нову модель середнього класу, яку компанія називає найбільш агентною серед усього Sonnet-сімейства. Sonnet 5 ближча до Opus 4.8 за можливостями, але дешевша для щоденної роботи. Це не флагман, та досить потужний інструмент для рутинних сценаріїв.
Версія краще за попередню справляється з міркуванням, використанням інструментів, кодингом та роботою зі знаннями. Може будувати плани, працювати з браузером та терміналом та автономно виконувати задачі на рівні, який ще кілька місяців тому компанія пов’язувала з більшими та дорожчими моделями.

Ранні користувачі відзначали, що Sonnet 5 краще доводить складні багатокрокові задачі до завершення. Також модель краще відмовляється від шкідливих запитів та менше галюцинує та підлаштовується під користувача.
Водночас Opus 4.8 залишається сильнішим для задач, де потрібна вища точність. Тож Anthropic фактично пропонує розділення: Sonnet 5 — для масових агентних сценаріїв та щоденної автоматизації, Opus 4.8 — для дорожчих та складніших випадків.
Claude Sonnet 5 уже є у всіх планах — за замовчуванням для Free та Pro, а також доступна користувачам Max, Team та Enterprise. Модель також з’явилася в Claude Code та Claude Platform. В API її можна викликати як claude-sonnet-5.
Коштує $2 за мільйон вхідних токенів та $10 за мільйон вихідних токенів до 31 серпня 2026 року. Це у 2,5 раза дешевше за Opus 4.8 та в 5 разів дешевше за Fable 5. Втім, у вересні ціна має зрости до $3 за мільйон вхідних токенів та $15 за мільйон вихідних.
Тут використовується оновлений токенізатор, через що той самий текст може перетворюватися на більшу кількість токенів — приблизно у
Окремо у компанії зазначають, що Sonnet 5 не тренували на кіберзавданнях. Модель може виконувати рутинні безпечні задачі, але у небезпечніших сценаріях, наприклад створенні експлойтів, суттєво поступається Opus 4.8 та Mythos 5. Втім, через загальне посилення можливостей версію все одно запускають із кіберзахистом, увімкненим за замовчуванням.
Будете переходити на Claude Sonnet 5 заради економії чи залишитесь на Opus 4.8?
11 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівТЕХНІЧНЕ ЗАВДАННЯ
Проєкт: Pattern-Based Ontology Builder (PB-OB)
1. Мета системи
Створити систему, яка:
1. Будує онтологію як граф патернів.
2. Автоматично розширює знання через:
— запити до користувача;
— (опційно) пошук у зовнішніх джерелах.
3. Перетворює будь-який вхідний текст у структуровані патерни.
4. Підтримує «brainstorm mode» — генерацію невідомих елементів онтології.
2. Основна ідея моделі даних
Уся система базується на 4 типах сутностей.
2.1 Entity
{ "id": "string", "name": "string", "type": "string" }2.2 Relation (патерн)
{ "subject": "Entity.id", "predicate": "string", "object": "Entity.id", "context": "string (optional)" }2.3 Attribute
{ "entity": "Entity.id", "key": "string", "value": "string | number | boolean" }2.4 Event
{ "id": "string", "type": "string", "participants": ["Entity.id"], "context": "string" }3. Основні модулі системи
3.1 Pattern Extractor
Функція: перетворює текст у структури (entities, relations, attributes, events).
Вхід:
«UFO часто спостерігають вночі»
Вихід:
{ "entities": ["UFO"], "relations": [ { "subject": "UFO", "predicate": "observed_in", "object": "night" } ] }3.2 Ontology Graph Storage
Вимоги:
— зберігання у вигляді графа (nodes + edges);
— підтримка запитів: знайти всі зв’язки Entity, знайти невідомі поля (NULL slots).
3.3 Pattern Query Engine
Підтримує запити виду: «What is UFO?», «How is X represented?», «What does X have?».
Перетворює запит у:
3.4 Brainstorm Engine (ключовий модуль)
Функція: генерує «дірки» в онтології.
Алгоритм для кожного Entity:
2. Якщо відсутні — створити запит:1. Перевірити відсутні типові зв’язки:
3. Додати ці питання у queue.
3.5 Knowledge Ingestion Engine
Вхід: user input, (optional) web text.
Процес:
1. NLP → entity extraction.
2. mapping → relation fitting.
3. validation.
4. storage.
3.6 Abstraction Engine
Функція: об’єднує повторювані патерни:
4. Основні операції системи
4.1 Add Knowledge
4.2 Query
query("How is UFO represented?")4.3 Brainstorm
4.4 Expand Ontology
5. Критично важливий принцип
Все є патерном:
— факт = relation;
— питання = incomplete relation;
— знання = заповнений граф;
— контекст = підграф.
6. Мінімальні технології (рекомендовано)
Backend: Java / Python / Node.js.
Storage: Graph DB (Neo4j) або PostgreSQL (JSON + relations).
Optional: vector search (для similarity).
7. MVP (мінімальна версія)
Програміст має реалізувати:
5. CLI або REST API.1. CRUD для Entity та Relation.
2. Graph storage.
3. Text → relation parser (простий).
4. Brainstorm generator зі списком шаблонів:
8. Результат системи
Система повинна дозволяти:
— створити онтологію з нуля;
— поступово її «донавчати»;
— автоматично генерувати питання до себе;
— будувати граф знань.
9. Ключова ідея для пояснення програмісту
Скажи йому так:
«Ми не будуємо базу даних. Ми будуємо систему, яка перетворює будь-який текст у граф патернів і постійно запитує, яких патернів не вистачає.»
Якщо хочеш, я можу далі зробити ще більш практичну річ:
— SQL schema (готову);
— або Neo4j graph model;
— або Java архітектуру класів під це ТЗ.
P.S. Розмова з ChatGPT що зробила можливим це ТЗ:
chatgpt.com/...d4-83ed-bb9c-b4cca51d9b0c
До речі, ця версія ТЗ по словам Сонет 5 є досить поверхневою. І він швиденько накидав мені version 2.0 З уточненнями і доповненнями і оцінкою деяких ризиків.
Та кого ці бенчмарки хвилюють. Через місяць все одно отуплять її. Це ж антропік, дасть вам першу дозу — якісні ШІшки, а потім буде непомітно підсовувати бадяжені.
Звісно це з розряду «я знаю але не можу довести». Але й як пояснити чому їх моделі настільки нестабільні по якості, я не знаю.
Чому б не створити wayback machine але для моделей, чим ще можна довести?
А чому б не створити
але для людського життя)?
Тому що інференс або робота моделі це рантайм процес, який вимагає багато потужного заліза прямо зараз. Це не згадуючи всієї software інфраструктури навколо «голої» ЛЛМ.
Тримати це увімкненим для зберігання попередніх версій моделей це щось на грані фантастики і навряд є фізично можливим.
Хіба контора повністю відмовляється від подальшого розвитку і перейде в перманентний мейтененс.
Я мабуть не дуже гарно пояснив свою думку. Мав на увазі якусь апку яка буде кожну неділю робити однаковий реквест до всіх доступних на цей час моделей і зберігати результат. Так можна буде наглядно показати чи найобує нас Даріо, точніше наскільки саме.
Ідея сама по собі цікава, але майже не реалізуєма через те, як працюють сучасні LLM.
LLM по своїй суті це стохастична система, тобто така, поведінка якої містить елемент випадковості, через що вона може видавати різні результати для одного й того самого запиту, навіть якщо ставити температуру 0, це лише частково допомагає.
Тобто, навіть відправка одного й того ж самого тестового промту до однієї і тієї ж версії буде видавати різні результати. Так, вони, скоріше за все, будуть логічно однаковими (або дуже схожими), але не ідентичними.
Але це якщо міряти лише «голу» LLM.
Сервіси, такі як ChatGPT та інші це ще додаткові програмні монструозні надбудови над LLM, які можуть включають бази даних, різні балансири, черги, політики, системні промти приховані від користувача, використання агентів, тулзи та багато чого іншого, що приховано за одним простим рядком, який ви бачите при заході на веб-весрію чату чи клоду.
І це як в задачі трьох тіл: навіть мінімальне відхилення дуже сильно може спотворити кінцевий результат.
А ці системи щодня змінюються, навіть якщо сама ЛЛМ лишається стабільною.
Тому вимірювати можна, але я не впевнений, що саме ми отримаємо в результаті цих вимірювань, точніше впевнений, що там окрім власне ЛЛМ буде намішано ще купа всього, що може як погіршити так і покращити результат мовної моделі.
Тобто результат тут завжди буде спектром, від якогось і до якогось значення.
Ключове тут правильно визначити метрики і допустиме відхилення для цих метрик, ось це дійсно є сенс міряти.
Але треба тоді ще дати відповідь «Навіщо»)?
P.S. Я буквально зараз дописую чергову наукову статтю де досліджую методи забезпечення відтворюваності результатів у системах на основі LLM.
Підписуйтесь на мій Linkedin, я там періодично публікую результати досліджень.
Indeed, щоб це спрацювало знадобиться експертиза @Dmytra щоб
Так, хоч і не зовсім в тему, але мені здається, що QA, які вміють працювати з АІ та вирифікувати його роботу, скоро отримають друге дихання і будуть дуже затребувані.
Мені здається ця навичка скоро буде дефолтна на стільки ж як «впевнений користувач пк»
Ще більше моделей, штучних, але «красівих і прєкрасних» :)))