Ricursive lanza Ripple-65B: el modelo alcanza un 80,5 % en Terminal-Bench 2.1

Cuando un agente corrige un error, el dinero y el tiempo se van en todo el recorrido: leer archivos, encontrar la causa, hacer el cambio, ejecutar pruebas y lidiar con un nuevo fallo. Ricursive propone Ripple-65B Preview para este tipo de trabajo. El interés práctico es claro: comprobar si el modelo es capaz de manejar su repositorio con una latencia y un coste aceptables. Por ejemplo, si puede arreglar por sí solo un controlador de API roto y confirmar el resultado con una prueba.

Se trata de un modelo de pesos abiertos con 65.000 millones de parámetros. En la evaluación publicada por los desarrolladores, obtuvo un 80,52 % en Terminal-Bench 2.1. Reflection Beam tiene un 80,1 % en la misma tabla. La diferencia es pequeña, así que un titular sobre una victoria rotunda estaría fuera de lugar. Más interesante es la posibilidad de contar con un candidato más para un agente de programación. Fuente: Ricursive.

Qué se ha lanzado exactamente

Ripple usa una arquitectura densa: a diferencia de los modelos de mezcla de expertos, emplea todos sus parámetros al procesar cada token. Por eso, comparar solo por el tamaño total puede inducir a error. En un modelo de mezcla de expertos más grande solo funciona a la vez una parte de los parámetros; una cifra menor en el nombre no garantiza por sí sola una respuesta más barata.

Los desarrolladores declaran un contexto de hasta 1.048.576 tokens. Los pesos se han publicado con licencia Apache 2.0 y hay variantes BF16 y NVFP4. Para los equipos con requisitos sobre dónde se aloja el código, esto amplía las opciones: se puede considerar un despliegue propio. Pero el tamaño del contexto todavía no demuestra con qué fiabilidad encontrará el agente la dependencia adecuada entre cientos de archivos. Fuente: ficha del modelo.

Conviene separar aquí dos tareas. La primera es alojar el modelo y lograr una velocidad de respuesta aceptable. La segunda es construir un agente que use correctamente la búsqueda, el terminal y las pruebas. Un buen resultado en la primera no garantiza el éxito en la segunda. Un contexto largo tampoco elimina la necesidad de elegir qué archivos se pasan al modelo.

Por qué el resultado de la prueba no se puede trasladar directamente al repositorio

Los propios autores describen la sensibilidad de las evaluaciones agénticas a las condiciones de ejecución. En la ficha se indica que cambiar el programa de control y los ajustes de contexto modificaba los resultados de Terminal-Bench. Su tabla comparativa combina cifras oficiales de otros laboratorios con mediciones propias allí donde faltaban datos publicados. Esto limita la precisión de la comparación directa. Metodología de evaluación.

Imaginemos un error corriente: tras actualizar una dependencia, el inicio de sesión de los usuarios dejó de funcionar. El agente debe leer el mensaje de error, encontrar la llamada que cambió, corregir el controlador y ejecutar una prueba adecuada. Una explicación bien redactada de la causa no basta aquí. Hace falta una corrección que funcione y que conserve el comportamiento previo del resto de los escenarios.

Ahora añadamos condiciones reales: la base de datos de pruebas no está disponible, la documentación está desactualizada y el error solo se reproduce con una configuración determinada. Aquí es donde se manifiestan las diferencias entre modelos y configuraciones de agente. Uno necesitará una pista de una persona, otro empezará a modificar archivos innecesarios y un tercero señalará correctamente qué datos le faltan. La puntuación general de un benchmark no sustituye esa comprobación.

Cómo comprobar la utilidad para el equipo

Yo empezaría con una pequeña selección de tareas ya resueltas: corregir un error, añadir una prueba, cambiar una API y trabajar con un módulo desconocido. Cada una necesita el estado inicial del proyecto y un criterio de éxito claro. Después conviene dar a Ripple y al modelo actual las mismas herramientas, límites de tiempo y acceso al entorno.

Lo mejor es contar el coste de una corrección aceptada. Incluye los reintentos, el tiempo de ejecución de los comandos y la revisión humana. Los tokens baratos ayudan poco si luego el desarrollador pasa media hora eliminando cambios innecesarios. Por separado, conviene registrar los casos en que el agente declaró resuelta la tarea aunque no se hubiera verificado el resultado.

Para un producto, es una forma de tomar una decisión concreta: si Ripple sirve para la clase de tareas elegida, si hace falta una verificación adicional y cuándo pasar el trabajo a una persona. Los pesos abiertos hacen que este experimento sea más accesible en términos de control del despliegue. La base para el cambio deben ser los resultados con su propio código, junto con el tiempo, los costes y la calidad de las correcciones.