SlopCodeBench: GPT-6 Astra лидирует с 16,3%, Opus 5.5 на medium обошёл xhigh

15 октября 2026 года Dex Horthy (Дэкс Хорти) при участии Gabe Orlanski опубликовал первую часть осеннего отчёта по бенчмарку SlopCodeBench. Бенчмарк даёт кодинг-агенту задачу по стадиям: агент пишет программу, затем получает новые требования и правит уже написанный код, а поздние контрольные точки (checkpoints) проверяют и новое поведение, и старое. Идея в том, что так ближе к реальной разработке с неясными и меняющимися требованиями.

В мае, когда SlopCodeBench публиковали в прошлый раз, gpt-5.5 показала строгий результат 14,8%. Теперь автор прогнал передовые модели через те же кампании: лучшей стала gpt-6 astra с 16,3%. Главная метрика, строгая доля прохождения (strict pass rate): в скольких контрольных точках модель прошла все тесты, включая регрессионные. У протестированных моделей (Opus 5.5, Fable 5.1, SOL 6 и 6.1, Astra, GLM 5.3) строгий результат лежит в диапазоне 12,2-16,3%. Более мягкая метрика core pass rate («базовое прохождение») у них, 65,8-74,0%.

Новое по сравнению с прошлыми подходами: автор впервые запустил полный набор, 36 задач и 196 контрольных точек на каждую настройку. Раньше он гонял подмножества из трёх, затем шести задач, поэтому с ними нельзя сравнивать прогресс или спад; в частности, прежний результат Fable 5 в 30% нельзя сопоставлять с нынешним, потому что он покрывал лишь 6 из 36 задач. Каждую модель и каждый уровень усилий (effort) он запускал один раз. Строгих проходов по настройкам, от 24 до 32 из 196, базовых (включая строгие), от 129 до 145.

Главная находка по уровням усилий: для некоторых новых моделей режим medium сработал лучше xhigh. XHigh стоил в 2,11-4,22 раза дороже Medium в трёх полных парах, а у Opus 5.5 режим Medium оказался лучше xhigh. Строгих проходов у Astra XHigh больше всех, но отрыв от SOL 6.1 Medium всего две контрольные точки. Opus Medium лидирует по базовому прохождению (145 из 196), но строго проходит лишь 28 из 196. Строгий результат растёт с XHigh только у Astra. Записанные оценки стоимости лежат в диапазоне $178,51, $1 550,07 при строгих результатах 12,24-16,33%: у GPT-6.1 Medium самая низкая стоимость, $178,51, и столько же строгих проходов, сколько у Astra Medium; у Fable оценка примерно в 8,68 раза выше при трёх строгих проходах меньше. Автор оговаривается: это не доказывает, что больше рассуждений вредит кодингу, а показывает лишь, что повышенное усилие не было надёжным способом купить больше строгих проходов в этих запусках; один прогон на настройку не позволяет отделить эффект от случайной вариации.

Отдельно автор оценил качество итогового кода («слоп», slop, шаблонные антипаттерны сопровождаемости). Учитываются только последние контрольные точки задач, и анализ охватывает 28 задач из 36 (сканер не смог полностью измерить часть файлов в восьми задачах, их исключили для всех моделей) во всех десяти завершённых запусках. Считается доля строк кода, где срабатывает хотя бы одно правило: у Opus XHigh она самая низкая, 77,75%, у Opus Medium, 94,25%; при этом строгих проходов у xhigh меньше, 25 против 28. Автор пишет, что код Opus 5.5 XHigh «примерно в 5 раз чище». Мусорные и временные файлы автор сначала хотел исключить из оценок, но Gabe возразил, что бенчмарк должен измерять, сколько мусора модели оставляют в кодовой базе, поэтому в основных результатах учтён весь оставшийся код. Для сравнения посчитан и вариант с фильтром (папки _work, tmp, temp, scratch, generated, build, dist и файлы *_pb2.py, *_pb2_grpc.py): он убрал только 45 файлов и 41 265 строк из итогового кода dynamic_buffer у Opus Medium, их общий объём упал с 216 881 до 175 616 строк, а доля слопа до 92,90%, так что Opus Medium всё равно остаётся первым по частоте слопа; для остальных моделей фильтр ничего не меняет. Средняя сложность кода ниже всего у Fable (3,57), выше всего у GPT-6 SOL Medium (11,70); автор напоминает, что дробление на мелкие функции снижает среднюю сложность, не делая код проще для изменения.

Итог автора: полный бенчмарк сложен тем, что агенты гораздо чаще правильно реализуют основное поведение, чем сохраняют работоспособность всего протестированного поведения при меняющихся требованиях. Модели лучше сопровождают кодовую базу (14,8% → 16,3% с мая по сентябрь), но не так быстро, как кто-то утверждает. Качественный разбор паттернов слопа Gabe и команда SlopCodeBench обещают во второй части.

Ключевые факты

• Полный прогон SlopCodeBench: 36 задач и 196 контрольных точек на настройку; лучший строгий результат у gpt-6 astra, 16,3% (в мае у gpt-5.5 было 14,8%); у всех протестированных моделей строгий результат 12,2-16,3%.
• XHigh стоит в 2,11-4,22 раза дороже Medium в трёх полных парах, но строгих проходов прибавляет только у Astra; у Opus 5.5 Medium лучше xhigh (28 против 25 строгих проходов).
• Opus XHigh оставил код с долей слопа 77,75% против 94,25% у Opus Medium; автор называет его код примерно в 5 раз чище.
• Оценки стоимости, от $178,51 (GPT-6.1 Medium) до $1 550,07; оценка Fable примерно в 8,68 раза выше GPT-6.1 Medium при трёх строгих проходах меньше.
• Каждая настройка запущена один раз, автор прямо пишет, что это не доказывает вред рассуждений и не отделяет эффект от случайной вариации.

Почему это важно

Большинство бенчмарков проверяют, решает ли агент задачу один раз. SlopCodeBench измеряет другое: как агент правит собственный код, когда требования меняются, и сколько мусора оставляет. Результат в духе «основное поведение агенты реализуют гораздо чаще, чем сохраняют всё протестированное при смене требований» и скромный рост строгого результата с 14,8% до 16,3% за май, сентябрь говорят, что поддержка кодовой базы остаётся слабым местом даже у передовых моделей. Заметка также даёт практичный сигнал о цене: более дорогой режим xhigh не гарантировал больше строгих проходов.

Кому это важно

Командам, которые выбирают модель и уровень усилий (effort) для кодинг-агентов и считают бюджет; разработчикам, чьи агенты живут в долгих проектах с меняющимися требованиями; тем, кто строит собственные оценки качества кода и хочет понять, как учитывать временные и сгенерированные файлы.

Как это применить

Результат стоит учитывать при выборе уровня усилий: по этим запускам medium в ряде случаев не уступал xhigh при цене в 2,11-4,22 раза ниже, но выводить из одного прогона общее правило нельзя. Прежде чем менять настройки в продакшене, стоит проверить это на своих задачах. Для воспроизведения автор указал параметры: зафиксированный каталог v1.0, стандартный промпт just-solve, seed 42, политика прохождения any-case, Docker с Python 3.12 и uv. Качественный разбор паттернов слопа обещан во второй части, которой пока нет.

Можно ли доверять

Это блог одного автора, а не релиз лаборатории или рецензируемая работа. Достоинство в том, что автор сам перечисляет ограничения: каждая модель и настройка запущены один раз, так что вклад случайной вариации неизвестен; метрики качества кода посчитаны по 28 задачам из 36; строгий результат лежит в узкой полосе, а отрыв Astra XHigh от SOL 6.1 Medium, две контрольные точки. Полной таблицы по моделям в тексте нет, а как получена оценка «примерно в 5 раз чище», не объяснено: приведённые доли слопа (77,75% и 94,25%) сами по себе пятикратной разницы не показывают. Слово «вредный» из заголовка записи, не вывод автора: в тексте он прямо пишет, что это не доказывает вред рассуждений.

Риски и подводные камни

Один прогон на настройку: разницу в два, три строгих прохода легко списать на шум. Строгий результат считается по контрольным точкам, и задачи с большим числом точек весят больше. Раньше процент слопа усредняли по задачам, теперь суммируют строки по всем 28 задачам, поэтому крупные программы весят больше. Автор допускает, что высокий слоп у новых моделей может объясняться новыми антипаттернами, которых нет в существующих линтерах, то есть метрика может быть неполной. Почему Astra выигрывает от XHigh, а остальные нет, в тексте не объяснено. Успех контрольной точки к тому же не равен итоговой работающей программе.

«Это не доказывает, что больше рассуждений вредит кодингу. Это говорит лишь о том, что повышенное усилие не было надёжным способом купить больше строгих проходов в этих запусках.»

— Dex Horthy, SlopCodeBench update 10/2026