GLM-5.3 не победила GPT-5.6 Sol в привычном смысле: на первой попытке флагман всё ещё точнее. Но измерения Together AI показывают более полезную для бизнеса вещь. Если сначала запускать дешёвую модель, а после провала тестов передавать задачу дорогой, качество растёт, а средняя стоимость падает.
Это аргумент не за смену поставщика, а против закупки одной универсальной кодинг-модели. Средний балл скрывает главное: модели ошибаются на разных задачах, поэтому их расхождение можно превратить в экономию.
Что показал прогон
Together AI сравнила GLM-5.3 в максимальном режиме с GPT-5.6 Sol на всех 113 задачах DeepSWE. Каждая задача получила по четыре попытки от каждой модели, всего исследователи разобрали 904 запуска.
На первой попытке Sol впереди: 72,7% pass@1 против 69,0% у GLM-5.3. Разница составляет 3,7 процентного пункта. Но уже на двух попытках модели практически равны: 81,0% у Sol и 81,1% у GLM-5.3. На четырёх попытках более дешёвая модель выходит вперёд с 87,6% против 85,8%.
Экономика различается сильнее, чем качество. Один запуск GLM-5.3 стоил $3,99, Sol обошёлся в $8,37. На каждые $100 первая модель решала 17 задач, вторая 9.
Together AI предлагает простой каскад: сначала GLM-5.3, затем Sol, если тесты отклонили патч. Такая схема решила 85,9% задач при средней цене $6,61. Sol в одиночном запуске дала 72,7% за $8,37. Каскад оказался на 13 процентных пунктов результативнее и на 21% дешевле.
Премия Sol покупает скорость и предсказуемость
Было бы удобно объявить GLM-5.3 новым выбором по умолчанию и закрыть таблицу. Данные этого не позволяют.
Средний запуск Sol занял 19 минут и 61 шаг. GLM-5.3 потребовались 35 минут и 124 шага. Sol также решила 61 задачу во всех четырёх попытках, GLM-5.3 только 48. Иными словами, Sol чаще сразу попадает в цель и быстрее возвращает результат. Когда разработчик ждёт патч прямо сейчас, эта премия может быть оправдана.
GLM-5.3 выгоднее там, где допустимы повторные попытки, а очередь или бюджет важнее задержки. Она покрыла больше задач хотя бы в одной из четырёх попыток и реже ломала уже проходившие тесты среди своих неудач: 11% против 20% у Sol. Это не повод отключать регрессионные проверки. Скорее напоминание, что дорогой ответ тоже нельзя принимать на веру.
Различается и профиль задач. В измерениях Together AI GLM-5.3 была сильнее на JavaScript и Rust, Sol лидировала на Python, Go и TypeScript. Sol лучше справилась с protocol conformance, data modeling and serialization, build and ops tooling. GLM-5.3 выиграла в query and config languages, language and runtime internals и stateful reactivity.
Переносить эту карту на любой репозиторий буквально было бы ошибкой. Но она объясняет, почему единая модель проигрывает маршрутизации: корреляция результатов по задачам составила лишь 0,43. Обе модели решили по 90 задач, однако GLM-5.3 закрыла 9 задач, которые не дались Sol, а Sol закрыла 7 задач, не решённых GLM-5.3. Вместе они покрыли 106 из 113 задач.
Что менять в стеке
Выбирать победителя по среднему pass@1 теперь недостаточно. Практический тест для команды выглядит иначе: взять собственные задачи и репозитории, запустить обе модели, а затем посчитать не токены и не попытки, а стоимость патча, который прошёл тесты и был принят.
После этого задачи можно разделить хотя бы на два потока. Интерактивные и чувствительные к задержке отправлять в Sol. Пакетные и допускающие повторный прогон начинать с GLM-5.3, поднимая их в Sol только после отказа тестов. Если тесты слабые, каскад превращается в дорогую рулетку, потому что ему нечем надёжно определить момент эскалации.
Главный маркер на ближайших прогонах конкретен: доля задач, где GLM-5.3 не прошла тесты, а Sol после эскалации дала принятый патч. Если таких случаев достаточно, чтобы перекрыть стоимость второго запуска, роутер окупается. Если модели ошибаются одинаково или проверка занимает больше сэкономленного времени, проще оставить одну. Решение теперь лежит не в рейтинге моделей, а в логах вашего CI.