Claude или ChatGPT для кода: 4 модели на одинаковых задачах

Claude или ChatGPT для кода: на восьми одинаковых задачах Claude Opus 5.5, Claude Sonnet 5.5, ChatGPT 6 Astra и ChatGPT 6.1 Sol написали верный код с первой попытки, один ответ пришлось только отформатировать заново. Разница нашлась во времени ответа (от 8 до 28 минут на все задачи), цене за токен (до 5 раз) и устройстве решений.

Короткий ответ: на этих 8 задачах флагман не дал преимущества

Восемь задач: правка бага по жалобе, функция по ТЗ, SQL-отчёт, рефакторинг без изменения поведения, код-ревью и три задачи с ловушками без подсказок в условии. Каждое решение проверялось скрытыми тестами, которых модель не видела. Прогон 19 октября 2026 года, по одному ответу каждой модели на задачу.

Время ориентировочное, замерено во время прогона без секундомера. Разницы в качестве тест не нашёл: все четыре модели сдали все задачи, и развести их по правильности такие задачи не смогли. Поэтому честный ответ на запрос звучит так: на типовых задачах уровня «баг, SQL, рефакторинг» выбирать между Claude и ChatGPT стоит по цене и времени ответа, а младшая модель в каждой линейке справилась не хуже старшей. Sonnet 5.5 и ChatGPT 6.1 Sol стоят одинаково, $2 за миллион входных токенов и $10 за миллион выходных, поэтому в этой паре сравнение честное: цена его не перекашивает. У флагманов иначе: Astra в 2,5 раза дороже Opus за токен, но по данным Artificial Analysis на максимальном усилии обходится дешевле за задачу.

Как я проверял: 8 задач, 119 скрытых тестов и около 75 тысяч случайных проверок

Каждая модель получала каждую задачу в новом чате, а её ответ проверяла страница в браузере со скрытыми тестами. Условия были одинаковыми для всех четырёх:

• прогон в LLM-студии SYNTX.AI, где один и тот же запрос отправляется в разные модели;

• новый чат на каждую пару «задача и модель»: при смене модели в старом чате новая видит всю переписку;

• размышление включено у всех, инструменты (в том числе выполнение кода) тоже;

• промпт вставлялся целиком, без правок, до трёх попыток на задачу. Понадобилась одна.

Скрытых тестов было 119: 16 случаев на правку бага, 22 на разбор строки, 7 строк результата SQL, 20 на рефакторинг, 20 сценариев на утечку скидки, 11 на подсчёт событий и 23 на часовые пояса. Код-ревью сверялось с ключом из четырёх ошибок. Сверху решения прогнали на случайных входах против эталона: 20 тысяч корзин, 30 тысяч строк длительности, 20 тысяч отчётов, 4 тысячи дат в 18 часовых поясах и несколько сотен последовательностей заказов и наборов событий.

Повод для теста - обзор Kinder «The 2026 AI Model Showdown» в X от 13 октября, у него около 209 тысяч просмотров за шесть дней. Вывод обзора: «в коде почти ничья между Opus 5.5, Sonnet 5.5 и Astra, а дешевле всех к уровню флагмана подбирается Sol». Своего прогона у автора нет, все цифры там из чужих таблиц, и этот вывод хотелось проверить руками.

Первый набор задач оказался слишком лёгким

Пять базовых задач ChatGPT 6 Astra и 6.1 Sol прошли без единой ошибки, примерно по минуте на задачу. Причина была в самих задачах: ловушки в них были перечислены прямо в условии. В спецификации разбора длительности стояли все краевые случаи, в SQL-задаче отдельной строкой было правило про возвраты. Модель, которая внимательно читает текст, такую проверку проходит. Поэтому появился тяжёлый раунд из трёх задач. Условие в нём звучит так, как его сформулировал бы коллега. Скрытые тесты проверяют то, что опытный разработчик учёл бы сам: модуль на 190 строк с ошибкой, о которой известен только симптом, миллион событий с лимитом в 2 секунды и напоминания по местному времени в поясах с переводом часов. Забегая вперёд: его тоже сдали все.

Базовые задачи: ловушки названы, а решения всё равно разные

Правка бага по жалобе. Покупатель видит в чеке 5996.999999999999 копеек вместо 5997, а по спецификации в функции ещё три расхождения: скидка округляется вниз, порог промокода не проверяется, нет исключения на процент вне диапазона. Все четыре расхождения нашли все четыре модели. Различается объём: у Sonnet решение на 23 строки, у Opus на 34, у Sol на 47, у Astra на 57. Astra и Sol написали точный разбор десятичной записи через BigInt, который понимает даже запись вида 1e-7. Это верно, но тяжеловато для правки трёх строк. Обе модели Claude обошлись Math.round(priceRub * 100) и целочисленным округлением, для цен с двумя знаками после запятой этого хватает.

Разбор длительности вида «1h 30m» модели написали через регулярное выражение или разбор по компонентам, а сумму все четыре считали точно в BigInt. Единственное расхождение нашли случайные проверки: Sonnet понял «между компонентами могут быть пробелы» буквально и отклоняет табуляцию, остальные принимают любой пробельный символ. Это вопрос толкования условия, а не ошибка.

Сложнее всего из базовых оказался SQL-отчёт по выручке городов. В нём три ловушки сразу. Заказ от 30 сентября 23:59:59 теряется, если фильтровать BETWEEN по дате без времени. Заказ с двумя позициями и двумя возвратами задваивается, если соединить всё в одном запросе. А возврат 5 сентября по заказу от 31 августа по условию вычитается. Обошли все. Claude Sonnet 5.5 и Opus 5.5 посчитали продажи и возвраты в отдельных подзапросах, ChatGPT собрал «движения денег» через UNION ALL. Самый короткий вариант у ChatGPT 6.1 Sol, 27 строк: города без продаж он добавил нулевыми строками в тот же UNION ALL и обошёлся без LEFT JOIN.

В рефакторинге модели получили функцию отчёта со странностями, на вывод которой завязан чужой парсер: нумерация с дырками после пропущенных строк, "12abc" превращается в 12, opts = null работает как пустой объект. Поведение на 20 тестах и 20 тысячах случайных входов сохранили все. А вот глубина правки разная:

Списки сохранённых странностей у всех подробные. У Claude они глубже: Opus заметил, что null и true в сумме печатаются как 0.00 и 1.00, Sonnet - что нестроковое имя роняет функцию так же, как оригинал.

Код-ревью дало меньше всего различий. В асинхронном коде на 21 строку были заложены четыре ошибки: forEach с async возвращает пустой массив, ответ 404 ложится в кэш как профиль, параллельные вызовы с одним id дублируют запросы, slice теряет последний элемент страницы. Нашли все четыре все модели, ложных находок не было ни одной. Sonnet добавил пятый пункт: кэш растёт без ограничений. А Astra в исправлении дублей удаляет промис из кэша при ошибке, только если там лежит тот же самый промис; остальные удаляют без такой проверки.

Тяжёлый раунд: ловушки без подсказок

Модуль расчёта заказа для доставки кофе, 190 строк, и сообщение поддержки: клиенты иногда видят скидку по промокоду, который не вводили, а на тестовом стенде по одному заказу всё считается правильно. Причина: функция промокода дописывает скидку в контекст статуса клиента, а этот контекст берётся из общего кэша. После первого заказа с промокодом скидка достаётся всем следующим клиентам того же статуса, пока процесс не перезапустят. Ловушка для торопливых: копия { ...ctx } выглядит как исправление, но массив скидок остаётся общим, и пять сценариев утечки из 20 продолжают падать.

На неё не попался никто. Способов исправления получилось три:

• Astra и Sol: копия массива скидок внутри функции промокода, три строки.

• Opus: новая функция, которая выдаёт каждому заказу собственную копию контекста; кэш строится, как раньше, один раз.

• Sonnet: функция промокода больше ничего не меняет, а возвращает промокод, который попадает только в локальный список правил заказа. Это единственный вариант, после которого кэш только читается, хотя он затрагивает и основную функцию.

Astra и Opus ещё и напомнили, что после выката сервис надо перезапустить. В живом процессе кэш уже испорчен прошлыми заказами, и исправленный код старые промокоды оттуда не уберёт.

Миллион событий за 2 секунды. Нужно посчитать для каждого события, сколько событий того же пользователя было за предыдущие 10 минут. В данных есть пользователь с 300 тысячами событий, у которого в окне до 20 тысяч соседей: решение перебором верно на маленьком примере, но на таком объёме не укладывается и за 10 секунд. Здесь модели сошлись на одной схеме: сгруппировать индексы по пользователю, отсортировать по времени, пройти двумя указателями. На миллионе событий все уложились в 187-259 мс при лимите 2000 мс, это быстрее эталонного решения в том же браузере (290-307 мс). События с одинаковой миллисекундой, на которых ломается обычное скользящее окно, тоже учли все. Astra и Sol добавили оговорку, что 2 секунды без замера на целевом устройстве гарантировать нельзя.

Напоминание в 09:00 по времени пользователя только на Date и Intl, без Temporal и библиотек. Простой путь «прибавить N суток и выставить часы» в тестах этой задачи проходит 18 случаев из 23. Ошибается он на ночи перевода часов, на времени, которого нет (02:30 при переходе на летнее время), и на острове Лорд-Хау, где часы переводят на 30 минут.

Ни одна модель по простому пути не пошла. У всех четырёх одинаковый длинный путь: местная дата через Intl.DateTimeFormat, прибавление календарных дней, перебор смещений вокруг нужного дня с проверкой, что такое время существует. Результат совпал с эталоном на всех 23 тестах и на 4 тысячах случайных дат, включая Касабланку, Дублин и Апиа, где 30 декабря 2011 года выпало из календаря целиком. По объёму разброс большой: от 34 строк у Sonnet до 134 у Sol, который ещё и ищет точную секунду перехода двоичным поиском.

Sonnet 5.5 сам проверял свой код: до 14 минут на задачу

На восемь задач у Sonnet ушло около 28 минут, у Opus около 13, у Astra и Sol меньше десяти. Больше всего времени Sonnet тратил там, где в ответе отчитывался о собственных прогонах: «проверено на 426 прогонах против оригинала» в рефакторинге, «на 400 случайных заказах» в задаче с утечкой, «замер на Node около 400 мс» в задаче про миллион событий. Задача с часовыми поясами заняла 14 минут. Инструменты в LLM-студии были включены у всех, но выполнять код, судя по ответам, решил только Sonnet. Самих его прогонов я не видел, поэтому это слова модели; скрытые тесты результат подтверждают.

Следы самопроверки остались и в тексте ответа. Задача с часовыми поясами начиналась со служебных реплик модели о своей работе: «перезапущу проверки последовательно в новой папке», «мои ручные ожидания для двух кейсов были неверны». Сам код пришёл прямо в чате LLM-студии без оформления блоком, слитым в несколько длинных строк, и однострочные комментарии в нём съели часть кода. Скопировать и запустить его как есть было нельзя. После того как переносы строк и кавычки вернули на место, ничего не меняя в логике, решение прошло все 23 теста. Это единственный из 32 ответов, который пришлось чинить руками.

Перед тестом у меня была гипотеза: флагман может проиграть не качеством, а выдержкой, если исчерпает лимит на рассуждение и не дойдёт до ответа. Она не подтвердилась. Opus 5.5 сдал все восемь ответов целиком с первой попытки, а дольше всех думал Sonnet, и, судя по ответам, из-за собственных проверок, а не от нехватки бюджета.

Что обещали бенчмарки и что вышло

Самая громкая цифра в спорах о коде - 70,6% у Sonnet 5.5 на Terminal-Bench 4.0 - взята из таблицы самой Anthropic. У независимого трекера Artificial Analysis соседние модели на том же тесте получают 59-60%: Opus 5.5 на максимальном усилии 59,6%, Astra 59,1%. Модель для кода я бы не выбирал по цифре, которую опубликовал её производитель.

«Почти ничья» у Kinder получается по бенчмаркам, где разрыв между моделями меньше разброса между стендами. Мой тест эту ничью не подтверждает и не опровергает: восемь задач не смогли развести модели, все сдали всё. Зато он показывает, что решают не два-три пункта в таблице, а то, как модель ведёт себя на вашем коде: ждать минуту или четырнадцать, читать 23 строки или 57, получить ли напоминание о перезапуске после выката.

У Kinder есть верная формула: цена пригодного результата равна цене токена, умноженной на токены на задачу и на число попыток, плюс время человека на правку. Сам обзор считает только первый множитель. В моём тесте попытка везде одна, правок не понадобилось, поэтому из формулы остаются цена и время. Сколько стоит задача в долларах, я не мерил: в LLM-студии текстовые модели расходуют лимит запросов по тарифу, а не токены. По данным Artificial Analysis, Opus 5.5 на максимальном усилии стоит около $5,98 за задачу их набора против $3,26 у Astra, а на среднем усилии наоборот, $1,34 против $1,54.

Один тезис обзора тест не подтвердил: что Astra сильнее в глубоком рефакторинге (Kinder ссылается на CodingFleet). На моей задаче Astra изменила структуру меньше всех. Это одна задача с жёстким требованием сохранить поведение, так что вывод осторожный: осторожность здесь могла быть ответом на условие.

Что выбрать для кода: Claude или ChatGPT

Для бага, SQL-отчёта или рефакторинга одной функции подойдёт любая из четырёх, и разумнее начать с младшей: Claude Sonnet 5.5 или ChatGPT 6.1 Sol за $2 / $10. Дальше выбор зависит от того, что вам важнее.

• Ответ за минуту: ChatGPT 6.1 Sol, а если бюджет не важен, ChatGPT 6 Astra.

• Глубже переписанный код при том же поведении: Sonnet 5.5, в рефакторинге он вынес три функции, Astra почти ничего не тронула.

• Модель, которая сама прогоняет свой код: Sonnet 5.5 с включёнными инструментами. В сумме это в 2-3,5 раза дольше остальных, на одной задаче вышло 14 минут против 1-4 у других, и именно этот ответ пришёл без блока кода.

• Напоминание о последствиях правки вроде перезапуска сервиса: в этом тесте его дали Astra и Opus.

По правильности флагманы за $10 / $50 и $4 / $20 на этих задачах ничего сверх младших моделей не дали. Где они могли бы пригодиться, тест не проверял: долгие агентные сессии и правки сразу в нескольких файлах.

А на каких задачах у вас младшая модель не справилась, а флагман справился?

Где мои выводы могут не сработать

Восемь задач и по одному ответу каждой модели на задачу: стабильность от прогона к прогону я не мерил. Языки - JavaScript и SQL, оценщик один, время ответа ориентировочное. Инструменты были включены у всех, а пользовался ими только Sonnet, поэтому его время отражает самопроверку, а не скорость модели. Агентных обвязок вроде Claude Code и Codex не было: модель получала задачу в чате и отвечала кодом. И главное ограничение: задачи не развели модели по качеству, так что тест говорит о равенстве на таком уровне сложности, а не о равенстве вообще.

Попробовать

Проверить выводы проще всего на своей задаче: взять баг или запрос из текущего проекта и отправить его в те же четыре модели. В SYNTX.AI это делается в LLM-студии, где один запрос уходит в разные модели, а ответы удобно сравнивать в соседних чатах. Промокод CTRLAI: скидка 20% на любой тариф для читателей Хабра.

Источники

• Kinder: The 2026 AI Model Showdown: Who Actually Wins at What, X, 13 октября 2026.

• Artificial Analysis: сравнение GPT-6 Astra и Claude Opus 5.5, Intelligence Index v4.3.2, данные на 14 октября 2026: цены токенов Opus 5.5 и Astra, цена за задачу, Terminal-Bench 4.0.

• Цены Claude Opus 5.5 и Sonnet 5.5: Anthropic, Pricing, на 19 октября 2026.

• Цены GPT-6 Astra и GPT-6.1 Sol: OpenAI, API Pricing, на 19 октября 2026, для запросов до 272 тыс. токенов.

• Terminal-Bench 4.0 по таблицам вендоров: Vellum, Claude Opus 5.5 vs GPT-6 Astra.