Что такое SWE-rebench

SWE-rebench — динамический бенчмарк для кодовых агентов, который мы регулярно обновляем. Мы собираем свежие задачи на основе реальных PR из open-source-репозиториев на пяти языках: Go, Java, Python, Rust и TypeScript. Агент получает репозиторий и описание задачи, исследует код, вносит изменения и запускает тесты в рабочей среде.

Что добавили в этот релиз

• Мультиязычный срез (111 задач): Go (21), Java (21), Python (20), Rust (25), TypeScript (24).
• 13 моделей + 4 готовых агента: проверили как отдельные модели в едином окружении (на базе SWE-agent), так и полноценные агентские продукты (Claude Code, Codex, Cursor, Junie).
• 9 435 оценённых прогонов: каждая пара «модель–задача» запускалась по 5 раз для оценки воспроизводимости.
• Контекст 524K токенов: увеличили окно, чтобы длинные сессии не обрывались из-за лимитов.

Как читать результаты

Мы оцениваем модели по трём метрикам:

Pass@1 — средний процент успеха с первой попытки (главный показатель «в среднем»).

Pass@5 — процент задач, решённых хотя бы в 1 из 5 попыток (максимальный потенциал модели).

Pass all 5 — процент задач, решённых во всех 5 из 5 попыток.

Стоимость одного прогона (rollout) рассчитывается с учётом раздельной тарификации кэширования:

cost = (
    input_tokens * price_in
    + output_tokens * price_out
    + cache_read_tokens * price_read
    + cache_create_tokens * price_create
) / 10**6

• Fable 5 занимает первое место по Pass@1 = 64,5%.
• Opus 5 демонстрирует наивысшую стабильность и воспроизводимость: решает во всех пяти попытках 52,3% задач.
• GLM-5.2 имеет самый широкий потенциальный охват: Pass@5 = 81,1%, хотя воспроизводит результат реже лидеров.
• GPT‑5.6 Sol показывает экономичность: качество на уровне лидеров при расходе всего около 0,6 млн токенов на задачу.

Прогоны некоторых моделей в их нативных обёртках показали результат ниже. Анализ траекторий объясняет почему: универсальные агенты оптимизированы под широкий спектр пользовательских сценариев. Наше же окружение (harness), архитектурно близкое к стандартному SWE-agent, заточено строго под цикл решения SWE-задач.

Детальные конфигурации, prompts и лимиты действий доступны в разделе Insights на странице SWE-rebench Leaderboard.

Среднее качество против воспроизводимости: зачем смотреть на Pass all 5

В реальной разработке инженер обычно запускает кодового агента один раз, а не пять раз параллельно в надежде выбрать удачный результат. Вероятность успеха отдельного запуска описывает Pass@1, но она не показывает, насколько результат воспроизводим от попытки к попытке. Для этого нужен Pass all 5 — доля задач, решённых во всех пяти прогонах.

• Высокая стабильность: Opus 5 (52,3%) и Fable 5 (51,4%) демонстрируют лучшую повторяемость в текущем наборе.
• Широкий охват при меньшей стабильности: GLM-5.2 лидирует по потенциальному охвату с Pass@5 = 81,1%, но её Pass all 5 составляет 39,6%. Модель добирается до большего числа задач, однако реже воспроизводит успех во всех попытках.
• Самый заметный разрыв: MiniMax M3 хотя бы раз решает 69,4% задач, но во всех пяти прогонах — только 20,7%.

Именно совместное чтение Pass@1, Pass@5 и Pass all 5 отделяет среднее качество от потенциального охвата и воспроизводимости.

Некоторые модели пытаются «читерить» и как мы такое ловим

В тестовых контейнерах полностью вырезана будущая Git-история, однако у агентов остаётся доступ в интернет для чтения документации и получения внешних зависимостей. Это создаёт риск, что вместо самостоятельного решения агент найдёт оригинальный pull request, commit или готовый patch.

В первых прогонах (1-я волна) системный промпт не содержал явного запрета на поиск исходного решения. Чтобы оценить, насколько модели склонны к поиску решений в интернете, мы анализировали их траектории. Фильтры траекторий находили попытки искать хэши, pull request и patches через `curl`, GitHub API, поисковые запросы и обработку ответов с помощью `grep`. Такие траектории исключались и отправлялись на чистый rerun с обновлённым prompt.

Исторические волны очистки по отдельным моделям:

Примеры читинга:

А вот пример из траектории Grok-4.5, который даже после явного запрета подсматривал решения.

Срез по языкам программирования

> Дисклеймер: любой бенчмарк — это фиксированная выборка задач. В этом релизе на каждый язык приходится от 20 до 25 задач, поэтому высокий результат подсвечивает специализацию на текущем наборе, но не гарантирует абсолютного превосходства на любых проектах этого языка. Лучшие результаты выделены в таблице.

Ключевые наблюдения:

• Rust: GPT‑5.6 Sol показывает лучший результат — 68,0%.
• Go: лидирует Fable 5 с 74,3%.
• TypeScript: лучший результат у Opus 5 — 78,3%. При этом MiniMax M3, заметно уступающая в общем зачёте, достигает 61,7%.
• Python: лучший точечный результат у GLM-5.2 — 57,0%.
• Java: среди моделей общего scaffold лидирует Grok 4.5 с 60,0%. В объединённом зачёте Junie на базе Grok 4.5 достигает 62,9%, но это уже результат всей агентной системы.

Эффективность траекторий и поведение моделей

Количество шагов и расходуемых токенов кардинально различаются даже у моделей одного уровня точности.

Замечание по времени: wall time сильно зависит от инфраструктурной загрузки, пропускной способности API и сетевых задержек. Он даёт полезную опорную точку, но не изолирует скорость самой модели. Например, Grok 4.5 завершает медианную траекторию за 8,9 минуты при среднем расходе 2,4 млн токенов — быстрее нескольких моделей с сопоставимым или меньшим объёмом контекста.

В чём секрет GPT‑5.6 Sol?

GPT‑5.6 Sol делает в среднем всего 18,4 действия на задачу! Для сравнения: GLM-5.2 совершает 94 действия, а Sonnet 5 — 74.

У Sol короткий и плотный цикл: минимум поиска → точечное чтение → правка → запуск тестов.

Каждое 5-е действие Sol (19,9%) — это запуск тестов (у Grok — 10,6%, у Fable — 16,1%).

Почему Codex (на базе Sol) тратит больше токенов, чем чистый Sol в нашем агенте? Codex делает больше шагов и вынужден многократно перечитывать разросшуюся историю контекста.

При этом почти все дополнительные токены — дешёвые cache-read, а не новый ввод модели.

Как выглядит пайплайн подготовки данных:

1. Воронка отбора: из пула в 5 000+ реальных PR за июнь 2026 года мы отобрали более 450 кандидатов и собрали для них Docker-образы. После прогона через модели и повторного QA в финальный срез выбрали 111 задач. Мы отсеяли тривиальные задачи, задачи с плохим описанием или те, что требуют недоступного внешнего контекста.
2. Доработка тестов: чтобы исключить неоднозначности, мы привлекали агентов к расширению и переписыванию автотестов, а затем прогоняли их на моделях разного уровня (от слабых до сильных). Это гарантирует, что тесты проверяют именно суть проблемы, а не падают из-за случайных мелочей.

Как мы предотвращаем читинг и подглядывание решений

Чтобы оценки были честными, а агенты не «списывали» решения из интернета или истории Git, мы защищаем бенчмарк на нескольких уровнях:

1. Оценка в чистом контейнере: извлекается только созданный агентом patch и прогоняется в свежем Docker-контейнере с эталонными (скрытыми) тестами. Агент не может пройти проверку, просто отредактировав тесты под себя.
2. Очистка Git-истории: из репозитория удаляются все будущие коммиты и упоминания оригинального PR.
3. Промпт-ограничения: системный промпт явно запрещает искать оригинальные PR и патчи во внешних источниках.
4. Аудит логов (траекторий): все прогоны проверяются на аномалии: поиск хэшей коммитов, обращения к GitHub API или скачивание .patch-файлов.

Выводы

1. Каждый бенчмарк подсвечивает разные свойства моделей, но не является универсальным мерилом. Для собственных проектов проверяйте, что ваши задачи похожи на задачи бенчмарка, либо соберите свой небольшой эвал.

2. Делайте несколько запусков и смотрите на разные метрики, а не только pass@1. Один rollout даёт слишком шумную картину. Стоимость задачи, pass all 5 и другие метрики важны, если вы масштабируете использование модели.

3. Аудит траекторий — критическая часть evals. Чем умнее становятся модели, тем сложнее ловить их на читинге, и аудит траекторий будет требовать всё больше ресурсов.

Что дальше?

Следующий релиз SWE-rebench планируется через 3–4 недели.

В планах:

• Локальные модели: расширить пул моделей для локальной разработки. Laguna-S-2.1, MiMo V2.5 и другие. Пожалуйста, напишите, какие модели вы хотите здесь увидеть.
• Новые флагманы: прогнать свежие версии Gemini и Kimi, которые не вошли в этот релиз.
• Reasoning budgets для моделей gpt и opus.

Детальные результаты, задачи и исходные pull request доступны на странице SWE-rebench Leaderboard.

Присоединяйтесь к сообществу

Следите за анонсами и обсуждайте задачи в нашем Discord — там мы публикуем свежие задачи немного раньше официальных релизов.

Подписывайтесь на канал @c0mmit — там я публикую свежие апдейты. Буду рад обсудить результаты и ответить на ваши вопросы в комментариях!