RealtimeBench: cuando la respuesta correcta del agente llega tarde

Con el juego en pausa, GPT-6.1-sol supera a Jev, un modelo más rápido. Con el juego en marcha, el orden se invierte. Ese resultado resume el argumento de The World Won't Wait, un artículo enviado a arXiv el 14 de octubre por Ningxin Pan, Hanyu Li, Yeqing Shen, Ning Ding, Yehui Tang y Wentao Zhang: en un entorno que cambia sin parar, una acción correcta que llega tarde vale lo mismo que una acción equivocada.

Casi todos los benchmarks de agentes dan por hecho que el mundo espera mientras el modelo piensa. Un razonamiento largo o una cadena de llamadas a herramientas solo penalizan en coste. Los autores proponen medir justo lo contrario.

Qué es RealtimeBench

RealtimeBench reúne 180 tareas repartidas en seis tipos de juego. Lo que lo distingue de otras evaluaciones es que el juego sigue corriendo durante la inferencia: si el agente tarda en decidir, el estado del entorno ya no es el que analizó. Las evaluaciones son pareadas, con el mismo modelo en modo pausado y en modo en vivo, lo que permite aislar cuánto rendimiento se pierde solo por latencia.

El caso de GPT-6.1-sol frente a Jev es el ejemplo central. El modelo más capaz en condiciones ideales no tiene por qué ser el mejor cuando el tiempo cuenta. El abstract no detalla las cifras de esa comparación, pero el patrón basta para poner en duda las clasificaciones que solo miden la calidad de la respuesta.

TORSI: pensar despacio fuera, actuar rápido dentro

La segunda aportación es un método de mejora que no toca los pesos del modelo, llamado Two-Timescale Offline Recursive Self-Improvement (TORSI). Funciona con dos papeles:

Un profesor lento estudia los fallos entre intentos, prueba correcciones en partidas pausadas y redacta instrucciones reutilizables.
Un alumno rápido juega en tiempo real sin consultar al profesor; solo lleva consigo esas instrucciones.

Las actualizaciones no se aceptan por defecto: solo se adoptan si mejoran la puntuación en validación. Tras dos rondas, la nota media de Jev en test sube de 13,51 a 24,19 en una escala de progreso de 0 a 100, con mejoras en los seis tipos de juego. Además, las mismas instrucciones elevan la media de otros tres modelos sin necesidad de reajustarlas.

Ese último dato es quizá el más práctico. Si las instrucciones que escribe el profesor funcionan con otros modelos, se parecen menos a un truco de ajuste y más a conocimiento destilado que se puede versionar y reutilizar.

Por qué importa fuera de los videojuegos

Los juegos son un banco de pruebas cómodo, pero el problema aparece en cualquier agente que opere sobre algo vivo: monitorización de infraestructura, soporte en directo, robótica o un pipeline de CI que no se detiene mientras el agente decide. En todos esos casos, la latencia forma parte de la calidad.

La arquitectura de TORSI se parece mucho a cómo ya trabajan bastantes equipos con Claude Code. Un modelo grande como Opus 4.8 analiza las sesiones fallidas y escribe una skill o un fichero de instrucciones; después, un subagente sobre un modelo más rápido como Haiku 4.5 ejecuta la tarea con ese contexto, sin escalar en cada paso. El paper no evalúa modelos de Anthropic, pero formaliza ese patrón y añade una pieza que suele faltar: un criterio de validación explícito antes de aceptar cada cambio en las instrucciones.

Para quién es útil

A quien diseña agentes para producción, el estudio le da un argumento cuantitativo para no elegir siempre el modelo más potente. A quien evalúa, RealtimeBench le ofrece una métrica que los benchmarks estáticos no capturan. Y a los equipos que mantienen bibliotecas de prompts o skills, TORSI les sugiere un ciclo de mejora reproducible: recoger fallos, proponer cambios offline y quedarse solo con los que superan la validación.

Conviene no perder de vista las limitaciones. Es un preprint sin revisión por pares, y una puntuación de 24,19 sobre 100 deja claro que el problema está lejos de resolverse.

En ElephantPink aplicamos una idea parecida en los agentes que construimos a medida: separar el momento de pensar del de actuar suele rendir más que buscar un único modelo que haga ambas cosas. Nos gustaría ver más benchmarks que midan con el reloj en marcha.