Recursive Flint v1.0: un modelo de programación de 40B construido en su mayor parte por su propio bucle de investigación

La frase más interesante del lanzamiento de Recursive Flint v1.0 no es una puntuación de benchmark. Es aquella en la que Recursive dice que un equipo pequeño construyó desde cero un modelo de programación de 40.000 millones de parámetros en menos de cuatro meses, con un sistema automatizado de investigación llamado Eureka Machine que contribuyó a casi todas las etapas. Flint se presenta como un potente modelo de programación local —39.800 millones de parámetros en total, unos 2.500 millones activos por token, Apache 2.0, cómodo en un portátil—. Pero el lanzamiento también es la primera prueba pública de una propuesta distinta: que el proceso de construir un modelo puede automatizarse en gran medida. Ambas lecturas están en el anuncio. Solo una de ellas es reproducible por ti.

Flint se lanzó el 21 de octubre de 2026 bajo la licencia Apache 2.0, con los pesos en Hugging Face como RecursiveSI/flint. Es el primer modelo de Recursive, el laboratorio fundado por el exdirector científico de Salesforce, Richard Socher, y llegó hace cuatro días, lo suficientemente reciente como para que casi nada sobre él se haya puesto a prueba fuera del laboratorio que lo creó.

Lo que Recursive realmente lanzó

Cuatro repositorios, no uno. El repositorio principal de checkpoint contiene pesos BF16, la configuración, el tokenizador, la plantilla de chat y un kit de servicio de SGLang, y se creó el 21 de octubre de 2026 a las 14:20 UTC. A su lado hay tres compilaciones cuantizadas, todas fechadas la misma tarde: una compilación int4 en safetensors, una GGUF int4 y una GGUF NVFP4. Los tamaños que figuran a continuación provienen de los listados de archivos de los propios repositorios, no del anuncio.

• Referencia BF16 — 79,59 GB en 37 archivos. Este es el archivo que usas si tienes una H200 o B300 y quieres el modelo sin diluir.

• NVFP4 GGUF — 22,86 GB. Esta es la compilación que hace literal la afirmación de que "funciona en un portátil", y es la que la mayoría de la gente realmente descargará.

• int4 GGUF — 25.99 GB, que es más grande que el archivo NVFP4 a pesar de un ancho de bits nominalmente similar. Si eliges entre los dos solo por el espacio en disco, gana NVFP4.

• int4 safetensors — 22,58 GB, para stacks de servicio que quieren un checkpoint de safetensors en lugar de un GGUF.

Recursive afirma que su propio entrenamiento de baja precisión y una cabeza de salida de 4 bits, destilados de vuelta hacia el modelo de 16 bits, quedan a menos de 0,7 puntos de la precisión completa. Ese número es de Recursive, medido con la evaluación de Recursive. Los tamaños de archivo no lo son: cualquiera puede leerlos en el repositorio.

Los cuatro números y qué mide cada uno

Recursive publicó un conjunto de puntuaciones junto con el lanzamiento, y lo más importante que hay que entender sobre ellas es que todas se generaron dentro del propio arnés de Recursive. Ningún tercero ha vuelto a ejecutar ninguna de ellas. El índice de Artificial Analysis —el árbitro independiente habitual para un modelo como este— no tiene ninguna entrada de Flint.

• SWE-bench Verified — 74.2 %. El benchmark que la mayoría de los lectores reconocerá, que mide si un modelo puede resolver incidencias reales de GitHub. Recursive lo ejecutó mediante mini-swe-agent sin acceso a internet en absoluto, calculó el promedio de pass@1 sobre al menos cinco intentos, con temperatura 1.0, top-p 0.95, top-k 20.

• SWE-bench Pro v2 — 89,7%. Fíjese en el "v2". No es el mismo benchmark que el SWE-bench Pro que publican otros laboratorios, y las dos cifras no pueden restarse entre sí. Esta distinción importa más de lo que parece, y se repite cada vez que se compara a Flint con un modelo que reporta el SWE-bench Pro a secas.

• Terminal-Bench 2.1 — 54,9 %. Aquí Recursive hizo algo inusualmente honesto e inusualmente incómodo: ejecutó Terminus 2 con internet habilitado y luego contó como fallo cualquier solución obtenida mediante recuperación web. Esa desventaja es deliberada, y también significa que esta puntuación no es directamente comparable con una cifra de Terminal-Bench producida sin esa regla.

• LiveCodeBench v6 — 80,3 %. Un benchmark de programación competitiva más que uno agéntico y, por lo tanto, el menos sensible a la elección de harness de los cuatro.

• IFBench — 89,2%. Seguimiento de instrucciones, que es donde un modelo pequeño suele ceder terreno primero.

La afirmación que Recursive realmente hace es más limitada de lo que sugiere la cobertura: Flint lidera los modelos de mezcla de expertos con menos de 50.000 millones de parámetros totales en SWE-bench Pro v2, Terminal-Bench 2.1 y SWE-bench Verified. Es una afirmación de clase, no absoluta. Los modelos densos de tamaño comparable quedan excluidos de ella por construcción, que es exactamente por lo que Qwen3.8 27B, un modelo denso, aparece en el mismo gráfico con una puntuación superior en el promedio de seis pruebas de la propia Recursive. Recursive lo publicó. Merece reconocimiento por haberlo publicado.

La afirmación de Eureka Machine es la parte que sobrevive al modelo.

Si se dejan de lado los benchmarks, queda una historia más inusual. Recursive afirma que su sistema de investigación automatizada generó ideas, ejecutó experimentos y utilizó los resultados para elegir qué experimentos ejecutar a continuación. La empresa le atribuye contribuciones en preentrenamiento, postentrenamiento, inferencia, cuantización y kernels de hardware. Tres de esas contribuciones son lo bastante específicas como para verificarlas con los artefactos:

• Forma del modelo. El diseño partió de una base 35B-A3B y llegó a 40B totales con 2,5B activos. Se trata de un movimiento deliberado hacia una mayor capacidad total con el mismo coste de activación: más disperso, no más grande en el sentido que importa para la inferencia.

Cuantización. Pasar la cabeza de salida a 4 bits y autodestilarse de vuelta desde el modelo de 16 bits es la receta que hay detrás de la afirmación de 0,7 puntos, y es la razón por la que un modelo de 39,8B tiene una versión distribuible de 22,86 GB.

• Kernels. Recursive escribió un megakernel de Metal dirigido a los chips M4 y M5, que es el elemento menos sorprendente de la lista dadas las afirmaciones sobre el rendimiento y el más concreto.

Lo que Recursive no reveló es cuánto tiempo de investigadores ahorró la Eureka Machine. Esa omisión es todo el argumento. Una afirmación de que un sistema automatizó la mayor parte del desarrollo de modelos solo tiene sentido si se sabe cuál era el coste de la alternativa, y el encuadre de la propia empresa es cuidadoso al respecto: el proceso sigue supervisado por humanos en lugar de ser totalmente autónomo. Hay que leer el comunicado como una demostración pública temprana, no como una prueba de automejora recursiva.

Lo que cuatro días de pruebas prácticas pueden y no pueden decirte

El análisis externo más sustancial sobre Flint hasta ahora es el de Will Knight, de Wired, quien lo ejecutó en una Mac con 48 GB de memoria y creó una aplicación de tareas pendientes, una herramienta de investigación web y un pequeño sitio explicativo. Las tres funcionaron. Ese es un resultado real y no es un benchmark. Son tres tareas, una máquina, una persona.

Una señal más útil para quien tenga previsto utilizar esto de verdad proviene de los reseñadores que midieron el rendimiento de forma prolongada en lugar de al inicio de una sesión. Una prueba independiente informó de unos 110 tokens por segundo con prompts cortos, que caían a aproximadamente 9 tokens por segundo en torno a 115.000 tokens de contexto. Se trata de una degradación de más de cinco veces, y es la cifra con la que hay que planificar si tu agente lee un repositorio grande antes de escribir nada. Las cifras de velocidad destacadas de Recursive —más de 125 tokens por segundo en un M4 Pro, más de 150 en una RTX Spark de 64 GB— están medidas explícitamente con contexto corto y excluyendo el prefill.

También hay un bug conocido en la plantilla de chat dentro de la ruta GGUF de llama.cpp. Si cargas la compilación cuantizada y el modelo se comporta como si hubiera perdido el hilo, revisa la plantilla antes de culpar a los pesos.

Ejecutarlo sin arriesgar en ello una ruta de producción.

Flint es una descarga, no un endpoint. OrcaRouter no lo ofrece, y nada de lo aquí dicho debe interpretarse como que sí lo hacemos.

Lo que eso cambia es cómo deberías probarlo. La forma honesta de evaluar un modelo de pesos abiertos de cuatro días es ejecutarlo junto a algo en lo que ya confías y comparar en tu propio repositorio, no sustituirlo y esperar que funcione. Si ya estás llamando a modelos alojados a través de una sola API, el planteamiento de bajo riesgo es mantener esa vía como respaldo mientras Flint se encarga de las tareas que estés dispuesto a delegarle — y dejar que una cadena de conmutación por error se encargue de las solicitudes en las que el modelo local se atasca, en lugar de descubrir el atasco en producción. Eso es una decisión de enrutamiento, no una decisión de lealtad.

La otra cosa que conviene saber antes de descargarlo: Flint es gratis de ejecutar, pero no gratis de poseer. Una descarga de 22.86 GB es la entrada, y la máquina que lo aloja con comodidad es el coste real. Si estabas comparando esto con un modelo alojado que cobra por token, ponle precio también al hardware.

Qué ver durante el próximo mes

Tres cosas decidirán si Flint será recordado como un buen modelo pequeño de programación o como el primer punto de datos en un argumento más largo.

La primera es una ejecución de benchmark independiente. Hasta que Artificial Analysis o una parte neutral comparable lo evalúe, toda comparación que involucre a Flint será una comparación entre la automedición de un laboratorio y la automedición de otro. La segunda es si el problema de rendimiento con contexto largo resulta ser un artefacto de llama.cpp, un problema del motor o una propiedad del modelo; esas posibilidades tienen soluciones muy distintas. La tercera es si la contribución de Eureka Machine puede evaluarse siquiera. Recursive ha dicho que el proceso cuenta con supervisión humana; la pregunta interesante es cuál fue la proporción entre humanos y agentes, y esa es una pregunta que una publicación de lanzamiento no está diseñada para responder.

Por ahora, el resumen defendible es breve. Flint es un modelo de programación genuinamente pequeño, genuinamente rápido y genuinamente abierto que se ejecuta en hardware que probablemente ya tienes, con una serie de puntuaciones que nadie ha comprobado y una historia de desarrollo que nadie fuera de la empresa ha verificado. Esos dos hechos son la historia.