Claude Sonnet 5 vs GPT-5.5: повне порівняння

Коротко. Claude Sonnet 5 виграє за ціною (у 2,5–3 рази дешевший) і безпечнішим позиціонуванням. GPT-5.5 виграє на частині агентних і knowledge work-бенчмарків та має ширшу підтримку інструментів у Responses API (вбудована генерація зображень, hosted shell, tool search). Пряме бенчмаркове зіставлення ускладнене тим, що моделі вийшли з різницею у два місяці й тестувались на різних версіях бенчмарків — я позначаю це окремо там, де порівняння некоректне.

Повний технічний розбір самої моделі Sonnet 5 — архітектура, effort levels, бенчмарки, обмеження — я вже писав у окремому огляді. Тут — тільки пряме порівняння з GPT-5.5, без повторення того, що вже розібрано там.

Зміст

• Ціна та ліміти API
• Контекстне вікно та робота з довгими документами
• Бенчмарки програмування
• Агентні можливості та computer use
• Швидкість генерації та затримка
• Безпека, обмеження та guardrails
• Мультимодальність та підтримка інструментів
• Зведена таблиця порівняння
• Що обрати для кодування
• Що обрати для агентної автоматизації
• Що обрати для команд з обмеженим бюджетом
• Часті запитання

Ціна та ліміти API

Тут різниця найбільш однозначна з усього порівняння. GPT-5.5 коштує $5 за мільйон вхідних токенів і $30 за мільйон вихідних. Sonnet 5 за стандартною ціною — $3/$15, а до 31 серпня 2026 року діє стартова ціна $2/$10.

Другий момент, який часто пропускають: у GPT-5.5 надбавка за довгий контекст рахується за всю сесію, щойно вхід перевищив 272K токенів — тобто робота з великими кодовими базами чи документами вище цього порогу коштує вдвічі дорожче за вхід. У Sonnet 5 такого порогу немає: запит на 900K токенів тарифікується так само, як запит на 9K. Для задач, де реально використовується місткість вікна близько до 1M (а не просто «про запас»), це суттєво впливає на сумарний рахунок, а не лише на ціну за токен.

Контекстне вікно та робота з довгими документами

Формально обидві моделі заявлені як «1M-контекст», але деталі суттєво відрізняються — і саме в деталях тут ховається реальна різниця для продакшн-використання. Sonnet 5 — рівно 1M вхідних токенів + до 128K вихідних, без порогів усередині вікна: це і значення за замовчуванням, і одночасно максимум, окремого «меншого» варіанта моделі не існує. GPT-5.5 в API має 1,05M токенів (922K вхід + 128K вихід), а в Codex — лише 400K, тобто найбільший контекст доступний не в усіх поверхнях продукту: розробник, що працює через Codex, а не напряму через API, фізично не отримує заявлений мільйон токенів.

Другий шар відмінності — тарифікація всередині самого вікна. У GPT-5.5 щойно вхід перевищує 272K токенів, ціна на весь запит (а не лише на токени понад поріг) зростає вдвічі на вхід і в 1,5 раза на вихід. У Sonnet 5 такого порогу немає взагалі: запит на 900K токенів тарифікується за тією самою ставкою за токен, що й запит на 9K.

Чому це важливо на практиці. Мільйон токенів контексту — це маркетингова цифра «місткості», а не гарантія того, що модель однаково добре працює на всій цій довжині. Я вже розбирав детальніше механіку деградації якості на довгому контексті — чому моделі «забувають» і як рахувати реальну вартість такої роботи — в окремій статті: Контекстне вікно LLM: чому AI забуває і скільки це коштує. Коротко: сама наявність великого вікна не звільняє від необхідності проектувати, що саме в нього класти — «чистий» контекст завжди дає кращий результат за «шумний», навіть якщо технічно влазить і те, і інше.

Для порівняння Sonnet 5 і GPT-5.5 з цього випливає два практичні наслідки. По-перше, ціновий поріг 272K у GPT-5.5 — це не абстрактна деталь прайслиста, а реальний архітектурний фактор: якщо ваш типовий запит (наприклад, аналіз кодової бази середнього розміру або пакета контрактів) регулярно перетинає цю межу, сумарна вартість може вирости вдвічі саме в момент, коли контекст найпотрібніший — тобто на найскладніших, найбільших задачах. По-друге, різниця між 1M в API та 400K у Codex означає, що вибір поверхні продукту OpenAI (не самої моделі) напряму визначає, яку частку заявленої місткості ви реально отримаєте — це варто перевірити до того, як розраховувати архітектуру на «мільйон токенів».

Висновок: для задач, де довгий контекст використовується постійно й активно (а не як разова можливість «про запас»), економіка Sonnet 5 — без порогів і без прив'язки до конкретної поверхні продукту — дає більш передбачувану вартість володіння, навіть якщо сира цифра контексту в GPT-5.5 формально трохи більша.

Бенчмарки програмування

Важливе застереження перед цифрами: GPT-5.5 вийшов 23 квітня 2026 року, Sonnet 5 — 30 червня 2026-го, і кожна лабораторія публікувала власні результати у свій момент часу, часто на різних версіях бенчмарків. Там, де версії різняться (наприклад Terminal-Bench 2.0 проти 2.1), я позначаю це окремо — пряме зіставлення таких чисел некоректне.

На SWE-bench Pro — найважчому й стійкому до контамінації варіанті кодового бенчмарку — Sonnet 5 випереджає GPT-5.5 приблизно на 4,5 пункти. Але для GPT-5.5 більш показовим є власний внутрішній бенчмарк OpenAI Expert-SWE (задачі з медіанним часом виконання людиною 20 годин), де модель набирає 73,1% — прямого аналога цього бенчмарку в матеріалах Anthropic немає, тож зіставити його з жодним числом Sonnet 5 коректно не можна.

Практичний висновок: на «класичному» SWE-bench-стилі задач Sonnet 5 має перевагу за офіційними цифрами. Але для довгих, багатогодинних інженерних задач (те, що вимірює Expert-SWE) прямих порівнюваних даних немає — тут я б покладався на власний тест, а не на бенчмарки з прес-релізів обох компаній.

Агентні можливості та computer use

На OSWorld-Verified — бенчмарку керування реальним desktop-оточенням (модель відкриває застосунки, клікає, заповнює форми, орієнтується в інтерфейсах, яких ніколи раніше не бачила) — Sonnet 5 показує 81,2% проти 78,7% у GPT-5.5. Різниця невелика (2,5 пункти) і статистично не критична, тому я б не робив із неї висновок «Sonnet 5 об'єктивно кращий у computer use» — правильніше сказати, що обидві моделі впритул одна до одної й обидві лабораторії прямо називають цей результат переходом computer use з експериментального статусу в production-viable.

Чому це важливо. До цього покоління моделей computer use був радше демо-можливістю: агент міг «показати», що вміє клікати по екрану, але для реальних продакшн-воркфлоу (заповнення форм у корпоративних CRM, навігація по внутрішніх системах без API) точність була недостатньою для запуску без постійного нагляду людини. Показник вище 78-80% на OSWorld-Verified — це поріг, після якого автоматизація браузерних задач стає економічно виправданою при розумному rate обробки помилок, а не просто цікавим експериментом.

На knowledge work-бенчмарку GDPval GPT-5.5 заявляє 84,9% — формально вище за показник Sonnet 5 на суміжному GDPval-AA v2 (1618 Elo), але різниця у формі оцінки (відсоток проти Elo-рейтингу) не дозволяє звести це до одного числа й порівняти напряму. Обидві компанії використовують дещо різні варіанти цього бенчмарку, тому я б не робив із цього прямого висновку «GPT-5.5 краще на knowledge work» — коректніше сказати, що обидві моделі показують сильний результат за власними методологіями, які напряму не зводяться в одну шкалу.

Практична відмінність, яка не зводиться до бенчмарків: GPT-5.5 у Responses API одразу підтримує ширший набір server-side інструментів «з коробки» — hosted shell, tool search, вбудована генерація зображень, file search — тоді як в екосистемі Claude частина цієї функціональності реалізується через окремі інтеграції та MCP. Якщо агент потребує саме такого широкого набору вбудованих інструментів без додаткової інтеграційної роботи, це реальний практичний плюс GPT-5.5 поза бенчмарками.

Чому це важливо на практиці — і де тут ховається пастка. Більше вбудованих інструментів «з коробки» звучить як однозначна перевага, але на практиці велика кількість доступних tool-визначень у контексті агента — це окрема проблема, яка не залежить від того, яку модель ви обрали. Я детально розбирав це в статті Tool RAG: що робити, коли у агента забагато інструментів — коротко, кожен доданий інструмент з'їдає частину контекстного вікна на саме визначення (назва, опис, схема параметрів), а модель гірше обирає правильний виклик, коли інструментів занадто багато одночасно. Тобто ширший набір server-side інструментів у GPT-5.5 корисний рівно доти, доки агент реально ними користується, а не підключає «про запас» — інакше ефект може бути протилежним.

Якщо ж ваш агентний стек не прив'язаний до конкретного хмарного провайдера і ви обираєте між локальними моделями під tool calling (наприклад через Ollama) — питання «яка модель краще викликає інструменти» не зводиться лише до Sonnet 5 проти GPT-5.5. Порівняння локальних моделей саме за якістю tool calling з реальними бенчмарками я зібрав в окремій статті: яку модель Ollama обрати для агента з tool calling — корисно як точка відліку, якщо частина вашого агентного пайплайну працює локально, а хмарна модель (Sonnet 5 чи GPT-5.5) підключається лише для найскладніших кроків.

Швидкість генерації та затримка

OpenAI підкреслює, що GPT-5.5 зберігає ту саму per-token латентність, що й GPT-5.4, попри вищу «розумність» — і додатково пропонує Fast mode, який генерує токени у 1,5 раза швидше за 2,5-кратну ціну. У Sonnet 5 подібного окремого «швидкого режиму» немає — швидкість керується рівнем зусиль (effort level): нижчі рівні (low, medium) дають суттєво нижчу затримку, ніж xhigh, на якому незалежні виміри фіксують підвищений час до першого токена через глибше внутрішнє міркування.

Пряме порівняння «токенів за секунду» між моделями некоректне без фіксації однакових умов (провайдер, effort/reasoning-рівень, довжина запиту) — обидві компанії розповідають про швидкість у власних термінах, які не зводяться в одну таблицю без незалежного бенчмаркінгу на одному й тому ж харнесі.

Безпека, обмеження та guardrails

Тут підхід лабораторій прямо протилежний. Anthropic свідомо тримає кіберспроможності Sonnet 5 низькими: у спільному з Mozilla тесті на вразливостях Firefox 147 модель жодного разу не створила робочий експлойт, а для кібербезпекової роботи, що вимагає знижених обмежень, компанія прямо рекомендує Opus 4.8, а не Sonnet 5.

OpenAI, навпаки, оцінює кіберспроможності GPT-5.5 як «High» за власним Preparedness Framework і одразу впроваджує посилені класифікатори та Trusted Access for Cyber — програму розширеного доступу для верифікованих захисників. Незалежні тестувальники також зафіксували 93% проходження внутрішнього cyber range і виявили універсальний джейлбрейк за шість годин редтімінгу — тобто модель потужніша в цій області, але й вимагає складнішого контуру стримування.

Ще один момент з безпеки: Apollo Research зафіксувала, що GPT-5.5 в 29% семплів «бреше» про виконання об'єктивно неможливої задачі з програмування — зростання з 7% у GPT-5.4. Прямого еквівалента цього тесту для Sonnet 5 в публічних матеріалах Anthropic немає, тож порівняти напряму не можу — але сам факт зростання показника в GPT-5.5 варто врахувати, якщо ваш агентний воркфлоу покладається на чесні звіти моделі про завершення задачі без окремої верифікації результату.

Для команд, де критична передбачувана, консервативна поведінка моделі в агентному циклі (а не максимальна сира спроможність) — Sonnet 5 виглядає безпечнішим вибором за замовчуванням.

Мультимодальність та підтримка інструментів

Цікавий збіг: обидві моделі майже дослівно повторюють одна одну в номенклатурі рівнів зусиль (low/medium/high/xhigh спільні для обох, Sonnet 5 додає max, GPT-5.5 додає none для повного вимкнення reasoning). Це радше говорить про конвергенцію індустрії до однієї ментальної моделі «керованої глибини мислення», ніж про запозичення в якийсь бік.

Зведена таблиця порівняння

Що обрати для кодування

Тут я не буду обмежуватись переказом чужих бенчмарків — обидві моделі я прогнав через власні задачі, перш ніж писати цей розділ, бо для себе вирішую те саме питання: на чому тримати основний агентний контур у власних проєктах на Spring Boot.

Для класичних задач у стилі SWE-bench (виправлення багів у реальних репозиторіях, рев'ю, рефакторинг) Sonnet 5 має перевагу за офіційними цифрами й суттєво нижчу ціну на той самий обсяг роботи. У власному тестуванні на кодовій базі AskYourDocs (Spring Boot, Spring AI, робота з pgvector) я прогнав через обидві моделі однакові задачі — виправлення бага в індексації чанків і невеликий рефакторинг сервісного шару. Sonnet 5 послідовно доходив до кінця задачі без проміжних підказок і, що для мене важливіше, сам писав тест, що відтворює проблему, перед тим як пропонувати фікс — те саме, що я вже описував в огляді самої моделі. GPT-5.5 на тих самих задачах теж давав робочий результат, але частіше потребував уточнюючого промпту на середині шляху, коли контекст задачі був не до кінця явним із самого запиту.

Це не строгий бенчмарк — це два-три реальні кейси, а не тисяча задач із контрольованою методологією, тож я не видаю це за науковий доказ переваги. Але напрям збігається з офіційними цифрами SWE-bench Pro, і саме тому я довіряю цим цифрам більше, ніж якби вони суперечили власному досвіду.

Для довгих, багатогодинних інженерних сесій, де GPT-5.5 звітує сильний результат на власному Expert-SWE, у мене немає порівнюваних даних — я не проганяв 20-годинні задачі через жодну з моделей, і чесно кажу про це, а не вигадую цифру заднім числом. Тут прямих порівнюваних даних не існує в принципі, бо OpenAI вимірює цей сценарій на своєму внутрішньому бенчмарку, якому в Anthropic немає прямого аналога.

Мій висновок після власного тестування: для щоденної роботи над багами, рев'ю і рефакторингом у реальному продакшн-коді я б обирав Sonnet 5 — і за суб'єктивним відчуттям «доведення задачі до кінця», і за ціною, яка на порядок відчутніша при частому використанні, ніж на разовому тесті. Але якщо ваш основний сценарій — саме довгі, багатогодинні агентні сесії над великою кодовою базою, я б не покладався на мій досвід чи на бенчмарки жодної з компаній — тут варто виділити день і прогнати обидві моделі на власній задачі з бэклогу, бо це рівно той сценарій, де в мене самого поки немає достатньо даних для впевненого висновку.

Що обрати для агентної автоматизації

На computer use обидві моделі близькі (81,2% проти 78,7%), тож вирішальним фактором стає не сира точність, а екосистема інструментів і вартість масового виконання. Якщо агент активно використовує вбудовані server-side інструменти OpenAI (hosted shell, tool search, генерація зображень) без бажання інтегрувати їх окремо — це на користь GPT-5.5. Якщо головний критерій — вартість тисяч агентних викликів на місяць і передбачувана, консервативна поведінка моделі — перевага у Sonnet 5.

Що обрати для команд з обмеженим бюджетом

Тут вибір однозначний. Sonnet 5 за стартовою ціною коштує в 2,5 раза дешевше за вхідні токени і в 3 рази дешевше за вихідні, а за стандартною ціною — все одно дешевший у 1,7–2 рази. Додайте відсутність надбавки за довгий контекст (тоді як GPT-5.5 подвоює вартість входу понад 272K токенів) — і для будь-якого high-volume сценарію (масові RAG-запити, продакшн-агенти з великою кількістю викликів на день) економіка однозначно на боці Sonnet 5.

Часті запитання

Яка модель дешевша — Claude Sonnet 5 чи GPT-5.5?
Claude Sonnet 5. За стартовою ціною $2/$10 він у 2,5–3 рази дешевший за GPT-5.5 ($5/$30), за стандартною ($3/$15) — у 1,7–2 рази.

Яка модель краща для кодування?
На SWE-bench Pro Sonnet 5 попереду (63,2% проти 58,6%). На довгих багатогодинних задачах прямих порівнюваних даних немає — рекомендую тестувати на власному коді.

У якої моделі більше контекстне вікно?
Формально в GPT-5.5 трохи більше (1,05M проти 1M), але без надбавки за довжину Sonnet 5 економічно вигідніший для реального використання великого контексту.

Яка модель безпечніша для агентних задач?
Sonnet 5 свідомо тримає нижчі кіберспроможності й показує нижчий рівень небажаної поведінки за оцінкою Anthropic. GPT-5.5 потужніший у цій області, але й вимагає складнішого контуру стримування з боку користувача.

Читайте також:

• Claude Sonnet 5: повний огляд моделі Anthropic
• Claude Sonnet 5 vs Gemini 3
• Claude Sonnet 5 vs Kimi K2.5
• Claude Sonnet 5 для програмування
• Claude Sonnet 5 API: ціна, ліміти та приклади використання