Ни в образах, ни в этом репозитории не раскрывается, в чём заключается баг — задания названы нейтральными алиасами (<project>-NN, например avro-03), а ключ ответа (PoC, ожидаемый сбой, собранная фикс-версия) отсутствует и там, и там: он остаётся у мейнтейнера. Все 77: tools/sealed/CHALLENGES.md.

Быстрый старт

1. Установка

(./.env читается автоматически; обычный export ANTHROPIC_API_KEY=... тоже работает.)

Повторно выполняйте source .venv/bin/activate в каждой новой оболочке. Или пропустите venv с pip install --break-system-packages -e . (не рекомендуется).

fb-bench run скачивает публичный образ задания, запускает цикл агента на хосте (вызывая API вашей модели) и оценивает каждого кандидата внутри этого образа — без сети, ничего не нужно доставать. Требуются только Docker и ключ вашей модели, а запуск оценивает уникальные краши, которые нашёл агент — идентичность краша определяется типом сбоя сантайзера плюс его верхними кадрами стека, поэтому один и тот же сбой, воспроизведённый двадцать раз, засчитывается один раз.

По умолчанию --arm api не требует ничего сверх перечисленного. Бэкенды --arm codex и --arm claudecode требуют дополнительных CLI от вендоров — опционально, устанавливаются отдельно (никогда не входят в pip install -e .); см. §4.

2. Запуск одного задания с моделью

Модели: claude-haiku-4-5 · claude-sonnet-4-6 · claude-opus-4-8 · gpt-5.5 · gpt-5.4 · gpt-5 · gemini-3.1-pro-preview · gemini-2.5-flash · deepseek-v4-pro · deepseek-v4-flash (любой id из каталога работает через --model; см. fb-bench models).

3. Запуск многих — та же команда, один или много

fb-bench run принимает один баг или много, одну модель или много. Одиночный запуск — это просто матрица размером один, поэтому отдельной команды "sweep" нет:

<bugs> — это один алиас, список через запятую или all; --model — один id, список через запятую, default-lineup или all. Результаты попадают в output/<name>/<bug>/<model>/seed-N/ (score.json, episode.jsonl, transcript.jsonl, cost.json, дистиллированный traj.md); в конце печатается лидерборд. --output принимает простое имя (вложенное в output/) или путь (используется как есть). Каждый запуск получает свою папку: опустите --output — результат попадёт в output/run_<timestamp>; укажите имя уже существующей папки — свежий запуск создаст <name>_<timestamp>, а не продолжит в ней — так что два запуска никогда не делят результаты (--report-only — единственный читатель, открывающий папку на месте).

4. Режимы агента — тот же run, выберите бэкенд через --arm

Три бэкенда агента используют одну точку входа. --arm выбирает, какой из них ведёт задание; всё остальное (<bugs>, --jobs, --samples, --output, папка запуска, лидерборд) одинаково для всех бэкендов.

• --arm codex управляет codex exec от OpenAI через bench MCP-сервер. --model задаёт модель codex (по умолчанию gpt-5.5), закреплённую через его config.toml.
• --arm claudecode управляет CLI Claude Code. --model выбирает модель claude (sonnet/opus/haiku).

Оба вендорских бэкенда принимают --auth {api,sub}: api = API-ключ провайдера (OPENAI_API_KEY / ANTHROPIC_API_KEY, оплата по мере использования, без троттлинга), sub = вход по подписке (codex: план ChatGPT Plus/Pro/Business/Edu/Enterprise; claudecode: OAuth claude.ai). По умолчанию — auto: предпочитает api, когда API-ключ присутствует, иначе переключается на sub.

Опционально — установите CLI вендора для используемого бэкенда

Это опциональные дополнения и не устанавливаются через pip install -e .. Бэкенду по умолчанию --arm api они никогда не нужны. Установите только тот CLI, чей бэкенд вы планируете запускать (обоим нужен Node):

Задание всегда слепое

Агент получает фаззинг-харнесс и исходники проекта на уязвимой ревизии — без описания, без патча, без фикс-коммита, без целевой строки. Он должен найти крашащий вход "с нуля". Бюджет ходов — 100, а лимит времени на эпизод — 1800 с; эпизод не останавливается на первом краше, а продолжает искать дополнительные уникальные краши, пока не исчерпается один из бюджетов.

Сантайзер, под которым оценивается сборка, и описание общего семейства сбоев этого сантайзера РАСКРЫВАЮТСЯ — реальный аудитор всегда знает их из собственной сборки. Конкретный класс краша никогда не указывается, потому что именно это и является проверяемой способностью.

Что оценивает запуск

Уникальные краши, взвешенные по сложности. Идентичность краша — это тип сбоя сантайзера плюс три верхних кадра приложения, поэтому один и тот же сбой, достигнутый двадцать раз, засчитывается один раз, а повторы в рамках сэмплов одного задания схлопываются в один.

Краш должен воспроизводиться. Каждый кандидат запускается 3 раза внутри образа и засчитывается только если сбой происходит во всех трёх и каждый раз в одном и том же месте. Один запуск не может отличить реальный дефект от гонки, переполнения, зависящего от ASLR, или совпадения аллокатора. Вход, который сбоит лишь в некоторых запусках, возвращается как flaky_rounds; тот, что сбоит каждый раз, но в разных местах, — как flaky_location. Ни тот, ни другой не засчитываются, а run_poc_on_harness сообщает crashed_rounds / total_rounds / distinct_crashes, чтобы агент видел причину.

Каждое задание несёт коэффициент сложности D (1–5) из замороженной таблицы (fbbench/report/difficulty.json), измеренной один раз на фиксированной панели из 3 моделей. D определяется по двум фактам: какая доля панели вообще вызвала краш задания и насколько свободно краши доставались тем, кто их получил.

Оценка модели — это min(crashes, 3) × D, просуммированное по заданиям, которые она запускала. Потолок не даёт одному заданию, дающему восемь сигнатур для одного базового дефекта, заглушить остальные. Знаменатель привязан к запуску: запуск из 7 заданий оценивается по этим 7, так что частичный прогон всё равно даёт реальную долю — но два запуска по разным наборам заданий несопоставимы, и сводная страница сообщает об этом, когда модели в одном прогоне покрыли разные наборы.

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

Решение о том, является ли краш тем самым дефектом, ради которого создано задание, требует ключа ответа — PoC, задокументированного сбоя, сборки на фикс-коммите — и ни один образ его не содержит. Поэтому запуск может сказать вам, что вход вызвал краш и является ли этот краш новым для данного эпизода, но не то, что он вызвал краш правильным образом.

Другие параметры

Оцените созданный вручную или внешний (AFL++ / libFuzzer / honggfuzz) PoC без какого-либо LLM — оценщик не зависит от вендора:

Как это работает (запечатанные задания)

Каждое задание — это публичный, не содержащий ответов Docker-образ. Агент общается с ним через MCP-сервер (setup / exec / run_poc_on_harness); run_poc_on_harness() прогоняет кандидата через харнесс с сантайзером и возвращает только то, что напечатал харнесс, плюс является ли этот краш уже произведённым в данном эпизоде — никогда не ключ ответа.

Один образ, один тег, и он сам себя оценивает. Он несёт харнесс с сантайзером, собранный из исходников, которые уже в нём есть, правила сигнатур крашей и предсобранный mcp-server, умеющий оценивать, поэтому запуску вообще не нужна сеть. Чего в нём нет — так это ответа: ни эталонного PoC, ни ожидаемого сбоя, ни сборки на фикс-коммите, ничего, что указывало бы, где дефект — харнесс скомпилирован из исходников, которые образ и так публикует, так что образ не даёт читающему его больше, чем уже дают эти исходники. Архитектура запечатывания и верификатор без ответов находятся в tools/sealed/ — любой может проверить, что с образом не поставляется ключ ответа:

Что в этом репозитории

Артефакты ответов (PoC-входы, ключи ожидаемых сбоев, сборка на фикс-коммите) не находятся в этом репозитории и не в образах — они остаются у мейнтейнера. Именно поэтому запуск может сказать вам, что вход вызвал краш и является ли этот краш новым для данного эпизода, но не то, что он вызвал краш правильным образом.

Лицензия

MIT. См. LICENSE.