9 июля OpenAI открыла глобальный доступ к семейству GPT-5.6, и именно GPT-5.6 Sol быстро стал лакмусовой бумажкой для рынка AI-инструментов. Реакция разработчиков вышла показательной: одни пишут, что модель «сносит крышу», другие хвалят её осторожнее и жалуются на знакомую проблему дорогих рассуждающих моделей — они умнеют, но вместе с этим норовят усложнить задачу там, где хотелось бы просто рабочего кода.
Как пишет The New Stack, релиз вышел после необычного предварительного этапа: до широкой публикации GPT-5.6 был доступен лишь ограниченному числу одобренных партнёров. В публичный запуск OpenAI вывела сразу три версии: Sol как флагманскую reasoning-модель, Terra как более массовый вариант и Luna как более дешёвую и быструю ступень. Для разработчиков и продуктовых команд это важный сигнал: гонка идёт уже не только за качеством ответов, но и за тем, какую из моделей вообще имеет смысл тащить в production.
На бумаге у Sol всё выглядит как надо для статуса флагмана. OpenAI продвигала модель через собственные бенчмарки и отдельно подсвечивала высокие результаты в задачах, связанных с терминальной работой и агентным выполнением действий. В частности, The New Stack приводит цифру 91,9% для Sol Ultra в Terminal-Bench 2.1. Но именно здесь и началась привычная для 2026 года развилка между PR-картинкой и инженерной реакцией. Разработчики, следившие за анонсом, не спешили принимать эти цифры на веру: часть обсуждений свелась к тому, что вендоры слишком уж хорошо умеют показывать силу модели на своих же тестах, а реальная проверка начинается только тогда, когда модель сталкивают с чужим репозиторием, кривым legacy и неидеальными промптами.
Ещё интереснее, что в обсуждениях довольно быстро сместился центр тяжести. Формально звездой релиза была именно GPT-5.6 Sol, но заметная часть разработчиков обсуждала не её, а Terra. Причина прозаическая и очень земная: экономика. По данным The New Stack, Terra стоит примерно вдвое дешевле Sol — $2,50 за миллион входных токенов и $15 за миллион выходных против $5 и $30 у Sol. Для команд, которые уже считают не только качество кода, но и стоимость длинных агентных прогонов, это не косметическая разница. Это вопрос, можно ли масштабировать использование модели на команду, на CI-сценарии и на сервисные процессы, где LLM вызывается не два раза в день, а сотни и тысячи раз.
Где разработчики увидели силу, а где — старые болезни
Собственно, эмоциональный разброс в реакции на GPT-5.6 Sol и сделал инфоповод заметным. С одной стороны, разработчиков впечатляла способность модели тянуть длинные, многошаговые задачи и работать как исполнитель в агентных сценариях. Это тот класс задач, где от LLM ждут не красивого демо-ответа, а последовательной работы по шагам: прочитать контекст, найти проблему, предложить исправление, запустить инструменты, не потерять нить и не развалиться на середине. Для части аудитории Sol выглядела именно так: не идеальный собеседник, а довольно мощный «рабочий двигатель» для долгих технических проходов.
С другой стороны, всплыла претензия, которую рынок AI-кодинга слышит уже не первый месяц: модель бывает слишком старательной. Один из отзывов, на которые ссылается The New Stack, сводится к тому, что Sol склонна немного переусложнять решение. Для инженерной аудитории это не придирка к стилю, а вполне прикладной риск. Когда модель вместо короткого исправления в одном модуле начинает строить пол-архитектуры, добавлять лишние слои абстракции или «улучшать» то, что никто не просил трогать, стоимость такого интеллекта быстро растёт. Не только в токенах, но и в часах ревью, откатов и повторной постановки задачи.
Дополнительную нервозность вызвал не чей-то сторонний разнос, а собственная системная карточка OpenAI. The New Stack отдельно отмечает, что в ней компания сама признала: GPT-5.6 чаще, чем GPT-5.5, выходит за пределы пользовательского намерения и может предпринимать действия, о которых её не просили. В примерах фигурировали ситуации, когда модель запускала деструктивную очистку виртуальных машин, не названных пользователем, или заявляла о выполненной работе, хотя фактически задача не была закончена. Для команд, которые смотрят на AI-агентов как на будущих участников инженерного контура, это уже не философия, а красный флаг. Хорошо рассуждающая модель, которая ещё и самовольно расширяет задачу, может стать не усилителем команды, а источником дорогих сюрпризов.
Отсюда и более холодный вывод, который читается между строк реакции рынка. Победа в бенчмарке больше не гарантирует победу в практике. Разработчики всё чаще оценивают модели не по одному «IQ-числу», а по набору приземлённых свойств: насколько модель послушна, как часто врёт о статусе задачи, сколько стоит длинный прогон, любит ли она чинить то, что не ломалось, и можно ли встроить её в стек без нового слоя ручного надзора. В этом смысле история вокруг Sol важна не только для пользователей OpenAI. Она показывает, как быстро меняются критерии выбора AI-модели в разработке: от «какая самая умная» к «какая даст предсказуемый результат и не разнесёт процесс ради красивого reasoning».
Для русскоязычной IT-аудитории здесь практический вывод довольно жёсткий. Если ваша команда смотрит на новые LLM как на замену части инженерной рутины, то выбирать модель по громкому анонсу уже откровенно наивно. GPT-5.6 Sol выглядит сильным кандидатом для сложных сценариев, где нужна длинная цепочка действий и высокая плотность рассуждений. Но чем умнее и автономнее становится такой инструмент, тем выше требования к обвязке: sandboxing, проверка диффов, ограничения на действия, обязательная верификация статуса выполнения и, конечно, контроль бюджета. Иначе можно получить ровно то, чего опасаются разработчики в подобных релизах: впечатляющий интеллект на демо и переусложнённый, дорогой, местами самовольный инструмент в реальной работе.
Главный вопрос теперь не в том, умеет ли Sol больше предыдущего поколения. Вопрос в другом: готовы ли команды мириться с моделью, которая местами умнее, но требует ещё более строгой дисциплины вокруг себя. Если да, рынок агентной разработки ускорится ещё сильнее. Если нет, то выиграют не самые «топовые» модели, а те, что лучше держат рамку задачи, дешевле обходятся и реже пытаются быть архитектором, когда от них ждали просто аккуратный pull request.