Nada en las imágenes ni en este repositorio revela qué es un error — los desafíos se nombran con un alias neutral (<proyecto>-NN, p. ej. avro-03), y la clave de respuestas (PoC, falla esperada, compilación corregida) no está en ninguno de los dos: permanece con el mantenedor. Explora los 77: tools/sealed/CHALLENGES.md.

Inicio rápido

1. Configuración

(./.env se lee automáticamente; un simple export ANTHROPIC_API_KEY=... también funciona.)

Vuelve a ejecutar source .venv/bin/activate en cada shell nueva. O sáltate el venv con pip install --break-system-packages -e . (no recomendado).

fb-bench run descarga la imagen pública del desafío, impulsa el bucle del agente en el host (llamando a tu API de modelo) y califica cada candidato dentro de esa imagen — sin red, nada que alcanzar. Solo se necesitan Docker y tu clave de modelo, y una ejecución puntúa los fallos distintos que el agente haya encontrado — la identidad de un fallo es su tipo de falla del sanitizador más sus marcos de pila superiores, así que la misma falla alcanzada veinte veces cuenta una sola.

El --arm api predeterminado no necesita nada más que lo anterior. Los backends --arm codex y --arm claudecode necesitan CLIs de proveedor adicionales — opcionales, instalados por separado (nunca parte de pip install -e .); consulta §4.

2. Ejecuta un desafío con un modelo

Modelos: 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 (cualquier id del catálogo funciona con --model; consulta fb-bench models).

3. Ejecuta muchos — mismo comando, uno o muchos

fb-bench run acepta un error o muchos, un modelo o muchos. Una sola ejecución es solo una matriz de tamaño uno, así que no hay un comando "sweep" separado:

<bugs> es un alias, una lista separada por comas o all; --model es un id, una lista separada por comas, default-lineup o all. Los resultados van a output/<nombre>/<error>/<modelo>/seed-N/ (score.json, episode.jsonl, transcript.jsonl, cost.json, traj.md destilado); se imprime una tabla de clasificación al final. --output acepta un nombre simple (anidado bajo output/) o una ruta (usada tal cual). Cada ejecución tiene su propia carpeta: omite --output y va a output/run_<timestamp>; nombra una carpeta que ya exista y una ejecución nueva se bifurca a <nombre>_<timestamp> en lugar de reanudarse en ella — así dos ejecuciones nunca comparten resultados (--report-only es el único lector, que abre una carpeta en su lugar).

4. Modos de agente — misma run, elige el backend con --arm

Los tres backends de agente comparten una sola entrada. --arm selecciona cuál impulsa el desafío; todo lo demás (<bugs>, --jobs, --samples, --output, la carpeta por ejecución, la tabla de clasificación) es idéntico entre arms.

• --arm codex impulsa codex exec de OpenAI sobre el servidor MCP del bench. --model establece el modelo de codex (por defecto gpt-5.5), fijado a través de su config.toml.
• --arm claudecode impulsa la CLI de Claude Code. --model elige el modelo de claude (sonnet/opus/haiku).

Ambos arms de proveedor aceptan --auth {api,sub}: api = la clave API del proveedor (OPENAI_API_KEY / ANTHROPIC_API_KEY, pago por uso, sin límite), sub = un inicio de sesión de suscripción (codex: un plan de ChatGPT Plus/Pro/Business/Edu/Enterprise; claudecode: OAuth de claude.ai). El predeterminado es auto — prefiere api cuando la clave API está presente, si no, recurre a sub.

Opcional — instala la CLI del proveedor para el arm que uses

Estos son extras opcionales y no se instalan con pip install -e .. El --arm api predeterminado nunca los necesita. Instala solo la CLI cuyo arm planees ejecutar (ambas necesitan Node):

La tarea siempre es a ciegas

El agente recibe el harness de fuzzing y el código fuente del proyecto en la revisión vulnerable — sin descripción, sin parche, sin commit de corrección, sin línea objetivo. Debe encontrar una entrada que provoque un fallo en frío. El presupuesto de turnos es 100 y el tiempo de pared por episodio es 1800 s; un episodio no se detiene en su primer fallo sino que sigue buscando más fallos distintos hasta que uno de esos presupuestos se agota.

El sanitizador bajo el cual se evalúa la compilación, y una descripción de la familia general de fallas de ese sanitizador, SÍ se revelan — un auditor real siempre los conoce desde su propia compilación. La clase específica de fallo nunca se indica, porque esa es la capacidad bajo prueba.

Qué puntúa una ejecución

Fallos distintos, ponderados por dificultad. La identidad de un fallo es su tipo de falla del sanitizador más sus tres marcos de aplicación superiores, así que la misma falla alcanzada veinte veces cuenta una sola, y las repeticiones entre las muestras de un desafío se colapsan en una.

Un fallo tiene que reproducirse. Cada candidato se ejecuta 3 veces dentro de la imagen y solo cuenta si falla en las tres y cada ronda aterriza en el mismo lugar. Una sola ejecución no puede separar un defecto real de una condición de carrera, un desbordamiento dependiente de ASLR o una coincidencia del asignador. Una entrada que falla solo en algunas rondas devuelve flaky_rounds; una que falla en todas las rondas pero en un lugar diferente cada vez devuelve flaky_location. Ninguna puntúa, y run_poc_on_harness informa crashed_rounds / total_rounds / distinct_crashes para que el agente pueda ver por qué.

Cada desafío lleva un coeficiente de dificultad D (1–5) de una tabla congelada (fbbench/report/difficulty.json), medido una vez con un panel fijo de 3 modelos. D se lee de dos hechos: cuántos del panel lograron que el desafío fallara en absoluto, y con qué libertad entregó fallos a quien lo logró.

La puntuación de un modelo es min(fallos, 3) × D sumado sobre los desafíos que ejecutó. El límite evita que un desafío que produce ocho firmas para un único defecto subyacente ahogue al resto. El denominador está limitado a la ejecución: una ejecución de 7 desafíos se puntúa sobre esos 7, así que un sweep parcial aún informa una fracción real — pero dos ejecuciones sobre conjuntos de desafíos diferentes no son comparables, y la página de resumen lo dice cuando los modelos en un sweep cubrieron conjuntos diferentes.

La tabla está congelada a propósito. Una ejecución no debe derivar la escala sobre la que luego se puntúa, y recalcularla en silencio movería cada puntuación histórica. Un desafío añadido después de la congelación no tiene coeficiente y se informa como sin puntuar en lugar de puntuado con cero.

Decidir si un fallo es el defecto para el que se construyó un desafío necesita una clave de respuestas — el PoC, la falla documentada, una compilación en el commit de corrección — y ninguna imagen incluye una. Así que una ejecución puede decirte que una entrada falló, y si ese fallo es uno que no había producido antes, pero no que falló de la manera correcta.

Otros parámetros

Califica un PoC hecho a mano o externo (AFL++ / libFuzzer / honggfuzz) sin ningún LLM — el calificador es neutral respecto al proveedor:

Cómo funciona (desafíos sellados)

Cada desafío es una imagen Docker pública y sin respuestas. El agente se comunica con ella a través de un servidor MCP (setup / exec / run_poc_on_harness); run_poc_on_harness() ejecuta el candidato a través del harness del sanitizador y devuelve solo lo que el harness imprimió más si ese fallo es uno que este episodio ya ha producido — nunca una clave de respuestas.

Una imagen, una etiqueta, y se juzga a sí misma. Lleva el harness instrumentado con sanitizador compilado a partir del código fuente que ya incluye, las reglas de firma de fallos y un servidor mcp-server precompilado que puede calificar, así que una ejecución no necesita red en absoluto. Lo que no lleva es ninguna respuesta: sin PoC de referencia, sin falla esperada, sin compilación en el commit de corrección, nada que diga dónde está el defecto — el harness se compila a partir del código fuente que la imagen publica de todos modos, así que la imagen no vale más para alguien que la lea de lo que ya vale ese código fuente. La arquitectura de sellado y el verificador sin respuestas viven en tools/sealed/ — cualquiera puede auditar que ninguna clave de respuestas viaja con una imagen:

Qué hay en este repositorio

Los artefactos de respuesta (entradas PoC, claves de falla esperada, la compilación en el commit de corrección) no están en este repositorio ni en las imágenes — permanecen con el mantenedor. Por eso una ejecución puede decirte que una entrada falló, y si ese fallo es uno que no había producido antes, pero no que falló de la manera correcta.

Licencia

MIT. Consulta LICENSE.