Поэтому я собрал evals из своих прошлых задач, чтобы найти быстрый и дешёвый способ работать с агентами без потери качества. Уже в первом раунде тестов нашёлся сетап вдвое дешевле. Ниже пошаговый гайд, как собрать свои evals.

Сначала я хотел проверить, сможет ли Pi (легковесный CLI-агент с открытым исходным кодом) решить те же задачи, что и Codex, потратив меньше токенов. Меньший расход токенов может помочь сделать больше в пределах лимитов подписки. На моих задачах Pi потратил меньше токенов. На первом графике: сравнение агентов на GPT-6.1 Sol с настройкой medium: оба решили все задачи, но с Pi средняя цена за задачу почти вдвое ниже ($0.070 против $0.138).

А когда у вас есть свои evals, можно проверять и другие гипотезы. Например, действительно ли инструменты вроде RTK (инструмента для сжатия вывода команд) экономят контекст и окупается ли перевод MCP-серверов в скиллы.

Как собрать свои evals: 6 шагов

1. Найти задачи в истории сессий с агентами
2. Превратить сессию в задачу и решить, что объяснить агенту, а что он выяснит сам
3. Собрать задачу в Harbor (инструменте для запуска и оценки агентов) и закрыть агенту пути к читерству
4. Проверить верификатор и отсеять неудачные задачи
5. Запустить прогоны и сравнить сетапы по цене и времени
6. Разобрать траектории и доработать evals; повторять это после новых прогонов

Я собрал скилл evals-from-sessions, чтобы автоматизировать большую часть этого процесса (подробнее в конце). GitHub

Зачем мне свои evals, если я делаю публичный бенчмарк

Я работаю в Nebius и последние полтора года занимаюсь RL-окружениями и evals для coding-агентов, а ещё поддерживаю публичный лидерборд и большой датасет SWE-rebench (подробнее о проектах на ibragim.dev). SWE-rebench показывает, какая модель сильнее на большом наборе реальных задач из разработки. Но задачи в нём взяты из других проектов. Мне также нужно понимать, какой сетап лучше подходит для моих задач.

С большей частью моей работы современные модели уже справляются. Я хотел найти самый быстрый и дешёвый сетап, который стабильно решает мои задачи. Можно ли для части задач заменить фронтирную модель на что-то быстрое и дешёвое вроде DeepSeek? Помогает ли новый скилл или плагин?

Идея не новая. Сатья Наделла в недавнем интервью говорит, что каждой компании стоит строить свои private evals и делать по ним hill climbing:

Недавно Anthropic выпустили для Claude Code команды build-eval и hillclimb (пост): они помогают собрать evals для приложений, которые вызывают Claude API, и подобрать для них сетап подешевле. В этой статье та же идея, только применённая к самим coding-агентам, с которыми вы работаете каждый день.

Лёгкие сетапы решают мои задачи так же, но быстрее и дешевле

Я проверил каждую конфигурацию на 10 задачах, по три прогона на задачу. Несколько конфигураций решили все задачи во всех трёх прогонах, поэтому я сравниваю их в основном по цене и скорости. Эти результаты помогают выбрать сетап для моей работы, но не говорят, какая модель лучше в целом.

Шаг 1 · Найти задачи в истории сессий

Я экспортировал историю работы с агентами за три месяца, около 1270 сессий. Большинство агентов хранят её локально:

Агент / Где искать сессии

• Claude Code: ~/.claude/projects/<project>/<session>.jsonl
• Codex CLI: ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl
• Pi: ~/.pi/agent/sessions/
• Gemini CLI: ~/.gemini/tmp/<hash>/chats/

Некоторые агенты удаляют старые сессии, так что их лучше скопировать заранее. В транскриптах встречаются API-ключи и другие секреты. Перед тем как отдавать экспорт внешним сервисам или коллегам, я прогоняю его через Gitleaks.

Парсер я не писал. Агент читал историю сессий и собирал в candidates.md таблицу потенциальных задач. Для каждой он записывал:

• что я хотел сделать;
• какие файлы и компоненты затрагивались;
• где агент ошибся и что пришлось исправлять;
• чем всё закончилось;
• можно ли проверить результат автоматически.

Дальше я отбирал кандидатов вручную. Когда контекста не хватало, просил агента показать кусок транскрипта или предложить способ проверки.

Самыми полезными оказались сессии, где агент сначала ошибся, а потом исправлялся по моим замечаниям. Мои замечания часто дают тест-кейсы для верификатора, то есть проверки, которая решает, справился ли агент с задачей.

Критериев отбора три:

1. Задача похожа на мою обычную работу.
2. Можно однозначно проверить, правильно ли она решена.
3. Её можно перенести в изолированное окружение с инструментами и данными, которые нужны агенту для решения.

Шаг 2 · Превратить сессию в задачу

Пример: задача compute-provider-cost-with-retry-fallback. На входе записи прогонов агента с повторными попытками, переключениями на другие модели и кэшированием токенов. Нужно посчитать итоговую стоимость нескольких прогонов. Ошибиться можно в нескольких местах: например, неправильно посчитать кэшированные токены или взять цену не той попытки или не той модели.

Часть — Что получилось

• Вход: Записи прогонов с повторными попытками, переключениями на другие модели и данными о токенах
• Цель: Правильно посчитать стоимость и вернуть структурированный результат
• Возможная ошибка 1: Посчитать кэшированные токены дважды: и по цене чтения из кэша, и ещё раз как обычные входные
• Возможная ошибка 2: Посчитать стоимость не по той попытке: взять неудачный retry или цену исходной модели вместо той, на которую сработал fallback
• Проверка: Запустить программу на тестовых событиях и сравнить результат. Обе ошибки должен ловить верификатор

Перед сборкой я решаю, что включить в инструкцию, а что агент должен выяснить сам. Спецификацию делю на три части:

1. Requirements: какие свойства должно иметь правильное решение.
2. Failure modes: какие типичные ошибки должны ловить тесты.
3. Must be discovered: что агент должен выяснить самостоятельно по коду или данным.

Здесь в инструкции явно описаны входной формат, правила расчёта, обработка fallback и формат ответа. Готовой реализации и подсказок, где менять код, в ней нет.

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

Шаг 3 · Собрать задачу в Harbor

Задачи я запускаю в Harbor – инструменте для запуска и оценки coding-агентов в изолированных окружениях. Он задаёт общий формат задач для evals и RL-окружений. Каждая задача лежит в своей папке:

my-task/
  instruction.md     # задание для агента
  task.toml          # метаданные и настройки запуска
  environment/
    Dockerfile       # начальное состояние окружения
  tests/
    test.sh          # верификатор: проверяет результат
  solution/
    solve.sh         # эталонное решение

Шаблон создаётся командой harbor task init.

Реальную работу можно перенести двумя способами.

Взять собственный коммит: состояние репозитория до изменения становится окружением, дифф становится эталонным решением. Так сохраняется настоящая структура проекта. Это подходит для приватных evals.

Или написать самостоятельную задачу: оставить требования и ошибки из исходного эпизода, а код, названия и данные заменить. Я использую этот подход, когда код закрытый или я хочу поделиться задачей. Задачу про расчёт стоимости я собрал именно так.

Как закрыть лазейки для reward hacking

Модели умеют читерить, и это нужно пресекать. Если задача из открытого репозитория, агент может найти исправление в интернете или просто в истории Git. Поэтому я заранее закрываю типичные лазейки: например, убираю из sandbox будущие коммиты и эталонный дифф. И, как бы глупо это ни звучало, прошу агента в инструкции не читерить и решать задачу. После прогонов проверяю траектории другим агентом, подробнее об этом в шаге 6.

Шаг 4 · Проверить верификатор и доработать набор

Для своих задач я использую детерминированные проверки: запускаю программу, смотрю содержимое файлов, JSON-вывод и состояние Git. LLM-as-judge не использую. Готовый верификатор проверяю четырьмя способами:

Проверка / Ожидание

• Oracle: эталонное решение, 5 запусков: Все проходят
• Nop: ничего не делать: Не проходит
• Near-miss: почти правильное решение с одной ошибкой: Не проходит
• Alternative correct: другая корректная реализация: Проходит

Начинал я с 15 задач и сделал 3–5 итераций по всему набору: часть задач доработал, часть выкинул, осталось 10.

Я проверяю верификатор на два типа ошибок:

• Правильное решение не засчитано (false negative). Например, тест ищет конкретную подстроку в сообщении об ошибке, и если модель сформулировала его иначе, решение не засчитывается, хотя оно верное.
• Неправильное решение засчитано (false positive). Обычно потому, что тесты покрывают не каждое требование или проверяют решение не целиком.

Из-за false negatives модели могут упираться в искусственный потолок: например, в 80%, если остальные 20% задач невозможно пройти из-за ошибок проверки. Из-за false positives модели получают баллы за неверные решения. Такие результаты ненадёжны, когда выбираешь сетап подешевле.

Тупик: задача на полтора часа, которая решилась за минуту

Пару месяцев назад я потратил часа полтора, чтобы привести в порядок несколько веток и старых неразрешённых конфликтов в Git. Работая с агентом, я сильно перестраховывался, чтобы ничего не сломать. В sandbox оказалось, что последовательные git merge --ff-only по веткам дают тот же результат. Уже после первых прогонов было видно, что задача слишком лёгкая, и я её выкинул. Теперь я оцениваю сложность задачи по тестовым прогонам.

Шаг 5 · Запустить прогоны

Harbor сам запускает агентов, повторяет попытки и собирает логи. У Harbor есть и свои скиллы для агентов. Пример команды:

harbor run -p tasks/ -a pi -m <model> \
  --ak thinking=medium -k 3 -n 5

Для каждой конфигурации я смотрю результат каждой попытки, долю задач, решённых во всех трёх попытках, цену, время, число шагов и токенов.

Я проверяю логи на инфраструктурные ошибки, таймауты и проблемы с сетью и учитываю такие сбои отдельно от ошибок модели.

Шаг 6 · Разобрать траектории и доработать evals

После прогонов агент читает траектории (пошаговые записи того, что делали модели) и помогает найти лазейки и ошибки верификатора: где он отклонил правильное решение или засчитал неверное. Я проверяю его выводы, обновляю задачи и чиню верификатор.
После каждой новой серии прогонов я повторяю проверки из шага 4 и исправляю найденные проблемы, прежде чем сравнивать сетапы.

Скилл для сборки своих evals

Я сделал скилл evals-from-sessions, который автоматизирует эти шаги: извлекает задачи из сессий, готовит спецификации, собирает окружения Harbor и пишет верификатор. Сам я подключаюсь дважды: утверждаю задачу и требования до сборки и проверяю готовую задачу перед включением в набор. Можно также просто дать эту статью своему агенту как инструкцию.

Скилл на GitHub: github.com/ibragim-bad/evals-from-sessions

Установка:

npx skills add ibragim-bad/evals-from-sessions

Также можно установить как плагин Claude Code / Codex или через Pi:

pi install git:github.com/ibragim-bad/evals-from-sessions

Теперь я использую эти evals, чтобы сравнивать модели, агентов и инструменты на своих задачах. Самый дорогой сетап оказался не лучшим выбором для моей работы.

Подписывайтесь @c0mmit, чтобы не пропустить следующие тексты, и пишите вопросы в комментариях или в личку: как собрать свои evals, с чего начать, как устроены RL-окружения.

Что такое 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 — там я публикую свежие апдейты. Буду рад обсудить результаты и ответить на ваши вопросы в комментариях!