Niklaus Harness Leaderboard prueba Kimi Code, Hermes, Pi, Claude Code y Codex más allá de las clasificaciones de marca

Joël Niklaus comparó nueve harnesses de agentes de programación en 28.849 pruebas, cuestionando la idea de que elegir un modelo resuelve por sí solo la cuestión del rendimiento. El leaderboard de harnesses de Niklaus evalúa el software que dirige el trabajo de un modelo mientras controla el modelo subyacente y la configuración de razonamiento. Sus resultados iniciales sitúan varias herramientas reconocibles en un rango de precisión similar, con diferencias de eficiencia y repetibilidad que complican la elección de un ganador.

La comparación incluye Kimi Code, Hermes Agent, Pi, Claude Code, Codex, OpenCode, mini-swe-agent, Qwen Code y OpenClaw. Un harness es el software que gestiona las instrucciones, herramientas y ciclo de ejecución de un modelo de IA. Aquí, ese software circundante se convierte en la variable examinada.

La tensión central se da entre la reputación de un producto y el comportamiento de una configuración específica sometida a pruebas. Estos resultados no establecen que Claude Code o Codex rindan universalmente mejor con su modelo predeterminado. Examinan qué ocurre cuando distintos harnesses operan modelos abiertos seleccionados en condiciones controladas, una cuestión más acotada con consecuencias prácticas para los desarrolladores.

Lo que realmente compara el Niklaus Harness Leaderboard

El experimento aísla el software que rodea al agente en lugar de tratar cada producto de programación como un paquete inseparable.

En la descripción de su lanzamiento, Niklaus afirma que la comparación mantiene fijos el modelo, el proveedor y el esfuerzo de razonamiento mientras cambia el harness. Cada tarea recibe tres intentos. La evaluación inicial cubre GLM-5.3-Flash, DeepSeek-V4.1-Flash y Flint, mediante Terminal-Bench 2.1 y DeepSWE.

Ese diseño importa porque las comparaciones habituales de productos suelen modificar varias variables de forma simultánea. Un desarrollador que cambia de asistente de programación puede cambiar a la vez el modelo, las instrucciones, las herramientas disponibles, los permisos y el comportamiento de ejecución. Entonces, resulta difícil atribuir una diferencia de rendimiento.

La descripción del lanzamiento informa de una tasa media de resolución del 51,4% para mini-swe-agent en los tres modelos, frente al 27,3% de OpenClaw. Niklaus también afirma que otros cuatro harnesses están estadísticamente empatados con el resultado líder. Estas cifras describen el lanzamiento inicial, no una clasificación permanente.

Sus hallazgos específicos por modelo complican ese promedio general. Según Niklaus, mini-swe-agent lidera con GLM-5.3-Flash, Hermes Agent con DeepSeek-V4.1-Flash y Kimi Code con Flint. Por tanto, el orden depende del modelo que un desarrollador pretenda ejecutar.

La implicación inmediata es limitada, pero relevante. Un harness que funciona bien con un modelo no extrae automáticamente el mismo rendimiento relativo de otro. Una puntuación global puede ayudar a identificar candidatos, mientras oculta la combinación relevante para un despliegue real.

Terminal-Bench evalúa agentes que realizan tareas en entornos de terminal, donde el software ejecuta comandos e interactúa con archivos. DeepSWE proporciona una evaluación independiente de ingeniería de software. Usar ambos amplía la comparación, aunque combinar resultados no convierte las colecciones de tareas en representativas de todos los flujos de trabajo de desarrollo.

El experimento también necesita una fecha vinculada a sus conclusiones. Al comprobarlo para este artículo, la aplicación en vivo mostraba la versión v0.1.2. Su descripción actual se refiere a la comprobación de proveedores equivalentes, en lugar de limitarse a repetir la formulación del lanzamiento inicial sobre proveedores fijos.

Esta distinción merece atención porque un benchmark puede evolucionar después de su primer anuncio. Nuevas versiones de harnesses, pruebas adicionales o controles revisados pueden cambiar el significado de una captura de pantalla. Las cifras de lanzamiento siguen siendo evidencia sobre la configuración de lanzamiento, incluso cuando el tablero actual presenta un orden distinto.

Por ello, para los lectores que encuentren la discusión original en Reddit, la corrección esencial tiene que ver con el alcance. Se trata de una comparación de combinaciones seleccionadas de harness y modelo. No es una prueba exhaustiva de todas las funciones, experiencias de suscripción o configuraciones predeterminadas asociadas a los nombres de producto enumerados.

Los proveedores de agentes de programación afrontan presión para explicar toda la configuración

Los resultados presionan a las afirmaciones que atribuyen por completo el rendimiento de un agente a su modelo subyacente.

Para los desarrolladores de harnesses, la comparación hace más visibles las decisiones de implementación. Las instrucciones, las interfaces de herramientas, el comportamiento de reintento y las decisiones de detención moldean el trabajo que realiza un modelo. Un modelo potente todavía puede encontrar fricción causada por el software encargado de dirigirlo.

Para los proveedores de modelos, el mismo experimento introduce un problema de atribución. Un resultado decepcionante dentro de un agente concreto no identifica al modelo como la única causa. A la inversa, un resultado sólido no establece que todas las aplicaciones que utilicen esos pesos lo reproduzcan.

Para los compradores empresariales, esto cambia lo que debe describir una evaluación significativa. Nombrar un modelo y un asistente es insuficiente cuando las elecciones de configuración influyen en los resultados. Los compradores necesitan información suficiente para comprender la combinación probada y reproducir el comportamiento relevante para su trabajo.

Una tarea hipotética de mantenimiento deja clara la distinción. Un agente podría necesitar inspeccionar un repositorio, identificar una prueba fallida, modificar una función y verificar el cambio. Cada etapa depende de cómo el harness expone la información y gestiona la secuencia de acciones.

Si el agente se detiene tras editar sin ejecutar la prueba pertinente, un parche plausible sigue sin verificarse. Si continúa emitiendo comandos improductivos, la finalización se vuelve más lenta y exige más recursos. Son diferencias operativas, incluso cuando el modelo subyacente no cambia.

Esto no establece qué implementación provocó un resultado concreto del leaderboard. Para ello es necesario inspeccionar los registros de ejecución y probar una intervención. Explica por qué la comparación controlada plantea una pregunta útil que una clasificación de modelos por sí sola no puede responder.

Los hallazgos de lanzamiento también ponen un límite al debate habitual de Claude Code vs Codex. Estos nombres de producto suelen representar experiencias completas construidas alrededor de determinadas familias de modelos. Probar sus harnesses con modelos abiertos seleccionados plantea una cuestión diferente de comparar esas experiencias completas.

Una posición baja en este experimento no establecería que el servicio predeterminado de un producto rinde mal. Una posición alta no establecería superioridad en revisión de código, colaboración interactiva o flujos de trabajo específicos de una organización. Esas afirmaciones necesitan evaluaciones que midan directamente esas actividades.

El resultado del benchmark de Kimi Code conlleva la misma limitación. Su liderazgo informado con Flint justifica investigar esa combinación bajo las condiciones probadas. No establece un liderazgo general entre modelos o repositorios no relacionados.

Para los proveedores, la respuesta constructiva consiste en publicar las configuraciones y explicar los cambios que afectan a los resultados. Así, los compradores pueden distinguir una mejora del modelo de una mejora del harness. Esto facilita evaluar las afirmaciones de rendimiento e investigar los fallos.

La presión es especialmente relevante para los equipos que operan modelos abiertos mediante software de agentes intercambiable. Su decisión de compra incluye la capa de ejecución. Necesitan evidencia sobre lo que aporta esa capa, en lugar de basarse por completo en un nombre de producto reconocible.

Una precisión similar puede ocultar comportamientos operativos distintos

Un resultado de precisión cercano deja margen para diferencias significativas en uso de recursos, latencia y consistencia.

El tablero actual separa varias mediciones en lugar de presentar la precisión como una respuesta completa. Su método de evaluación describe la medición externa del uso del modelo y distingue el tiempo de procesamiento del modelo del tiempo dedicado a ejecutar el agente. Estas distinciones ayudan a explicar por qué tasas de resolución similares pueden producir experiencias operativas diferentes.

El tablero también representa la precisión frente al coste e identifica una frontera de Pareto, el conjunto de opciones que ningún competidor supera en ambas medidas mostradas. Esto ofrece a los lectores una forma de examinar ventajas en competencia sin asumir que la mayor precisión siempre debe ser preferible.

Este enfoque importa cuando una organización tiene una carga de trabajo fija y recursos limitados. Una pequeña ventaja de precisión puede ser valiosa para una tarea difícil que requiera supervisión mínima. Esa misma ventaja puede resultar menos atractiva si exige un tiempo de ejecución sustancialmente mayor en tareas rutinarias de mantenimiento.

Un resultado de eficiencia también necesita interpretación. Un gasto menor no significa necesariamente que un agente razone con mayor eficacia. Podría reflejar menos intentos, una terminación más temprana, salidas más breves o un patrón de uso de herramientas diferente. El registro de ejecución ayuda a distinguir la contención productiva del fallo prematuro.

Del mismo modo, una ejecución más larga no demuestra despilfarro. Un agente podría dedicar esfuerzo adicional a comprobar un parche o recuperarse de un enfoque fallido. La pregunta relevante es si el trabajo extra mejora un resultado que el equipo realmente valora.

Por eso, informar sobre el uso de recursos por intento y por resultado exitoso responde a preguntas diferentes. Un intento fallido barato sigue siendo un fallo. Un intento exitoso más exigente puede seguir siendo la mejor elección cuando, de otro modo, la recuperación humana dominaría el flujo de trabajo.

Estas son consideraciones de evaluación, no explicaciones establecidas para cada harness del tablero. Un gráfico puede revelar un patrón que merece investigación. No puede, por sí solo, identificar la instrucción o el comportamiento de herramientas responsable de ese patrón.

El mecanismo es sencillo en principio. Un agente recibe información, elige una acción, observa el resultado y decide qué hacer después. El harness controla partes importantes de ese ciclo, incluidas las herramientas disponibles y la forma en que sus respuestas llegan al modelo.

Consideremos un repositorio hipotético con una compilación fallida causada por un problema de entorno. Un agente que edita repetidamente código de aplicación puede consumir recursos sin abordar la causa. Otra configuración podría reconocer el problema de entorno y redirigir su investigación.

La diferencia afectaría a la ejecución de la tarea, no al conocimiento bruto del modelo. Establecer esa explicación requeriría vincular el comportamiento observado con el resultado. Sin esa inspección, afirmar que un harness concreto es «más inteligente» va más allá de la evidencia.

Por tanto, el Niklaus harness leaderboard respalda una comparación más específica de lo que sugiere una única etiqueta de ganador. Los desarrolladores pueden preguntar qué combinaciones alcanzan una precisión aceptable mientras usan recursos de una forma que su carga de trabajo puede sostener. La respuesta puede diferir entre el desarrollo interactivo y la operación sin supervisión.

También cambia la forma de interpretar un titular sobre el benchmark de Kimi Code. Un liderazgo específico por modelo es una señal útil para una evaluación adicional. Sigue siendo incompleto sin información sobre los intentos fallidos, la duración de la ejecución y el comportamiento que produjo la puntuación.

Por la misma razón, las comparaciones de Claude Code vs Codex deben preservar el contexto probado. Los nombres proporcionan orientación, pero la configuración determina lo que el resultado describe realmente.

El éxito repetible es un resultado distinto del éxito ocasional

Un agente que resuelve una tarea de forma intermitente plantea una propuesta de despliegue distinta a la de uno que la resuelve de manera consistente.

Posteriormente, Niklaus destacó la fiabilidad en intentos repetidos. Según su desglose de fiabilidad, mini-swe-agent resolvió en promedio el 51,4 % de las tareas por intento. Resolvió el 68,6 % al menos una vez en tres intentos, pero el 33,0 % en todos los intentos.

Esas mediciones describen preguntas operativas diferentes. El promedio captura el rendimiento entre intentos. El éxito al menos una vez refleja si las oportunidades repetidas acaban produciendo una solución. El éxito en todas las ocasiones captura la consistencia dentro de los intentos medidos.

La distinción cobra importancia cuando alguien observa al agente trabajar. Un desarrollador puede inspeccionar un intento fallido, cambiar una instrucción o decidir que merece la pena realizar otra ejecución. La supervisión humana puede hacer útil el éxito intermitente, aunque el tiempo dedicado a supervisar sigue formando parte del flujo de trabajo.

Un proceso sin supervisión se enfrenta a una restricción distinta. No puede asumir que existe un intento alternativo exitoso salvo que el sistema circundante ejecute realmente alternativas y reconozca su calidad. Los intentos repetidos necesitan un método de selección, un presupuesto de ejecución y una forma de gestionar los fallos no resueltos.

Esto hace que una puntuación de éxito ocasional sea un sustituto deficiente de una medición de consistencia. Puede mostrar que una configuración tiene acceso a una solución en determinadas condiciones. No demuestra que la configuración vaya a proporcionar esa solución de forma fiable bajo demanda.

Niklaus informa de que cinco harnesses resolvieron entre el 32,0 % y el 33,3 % de las tareas en todos los intentos de la comparación citada. Describe esos resultados como demasiado parejos para determinar un ganador. Esto respalda evitar afirmaciones precisas sobre ganadores dentro del grupo líder.

Las cifras de fiabilidad también necesitan límites claros. Tres intentos aportan evidencia sobre la repetibilidad dentro de ese experimento. No establecen una tasa de fallos en producción ante repositorios, dependencias, permisos e instrucciones de usuarios cambiantes.

Tampoco un fallo en un benchmark se traduce automáticamente en una acción perjudicial en producción. El evaluador mide si la tarea cumple sus criterios de éxito. Las consecuencias operativas dependen de a qué puede acceder el agente y de qué aprobación o verificación rodea su trabajo.

Para los responsables de ingeniería, la implicación es separar la capacidad de la entrega fiable. Una configuración puede ser lo bastante capaz para producir a veces un parche correcto y, aun así, no resultar adecuada para un flujo de trabajo sin supervisión. Esa brecha exige verificación adicional, no una etiqueta de marketing más contundente.

Una actualización hipotética de dependencias ilustra la diferencia. Un agente podría actualizar correctamente el paquete y superar las pruebas durante una ejecución, pero pasar por alto un cambio de configuración relacionado en otra. El éxito ocasional demuestra menos sobre la preparación para operar sin supervisión de lo que podría sugerir el porcentaje destacado.

Un equipo que evalúe ese flujo de trabajo se preocuparía por una finalización reproducible y una gestión clara de los fallos. También le importaría si el cambio resultante resulta comprensible para quien lo revisa. Esas dimensiones siguen siendo distintas de que el verificador del benchmark acepte el estado final.

La visión de intentos repetidos de la clasificación lleva esa distinción a la comparación pública. Anima a los lectores a preguntar qué sucede cuando el agente debe trabajar de nuevo, en lugar de tratar una trayectoria exitosa como una descripción completa del producto.

Las versiones de los benchmarks y los registros públicos limitan las afirmaciones sobre ganadores

Los resultados publicados son evidencia examinable, pero siguen estando limitados por las versiones de los benchmarks, las configuraciones y la exhaustividad de la verificación.

Terminal-Bench ofrece un ejemplo claro de por qué importan las etiquetas de versión. Su revisión 2.1 corrigió problemas en 28 de las 89 tareas de la edición anterior. Los mantenedores informaron de cambios en las puntuaciones de modelos-agentes representativos tras esas correcciones.

Ese historial convierte la versión del benchmark en parte de la afirmación. Una puntuación de Terminal-Bench 2.0 no puede tratarse simplemente como intercambiable con una de 2.1. Las tareas y las condiciones de evaluación han cambiado, incluso cuando la métrica mostrada conserva el mismo nombre.

El mismo principio se aplica al harness. Un resultado pertenece a la versión de software y a la configuración sometidas a prueba. Si una actualización cambia las instrucciones, la ejecución de herramientas o el comportamiento de finalización, la puntuación anterior describe la implementación anterior.

Esto plantea un desafío para los debates públicos que evolucionan rápidamente. Un gráfico puede circular después de que cambie la clasificación, mientras los comentarios siguen tratándolo como actual. Los lectores necesitan la configuración original y la fecha de medición para determinar qué sigue demostrando la imagen.

Los registros públicos de ejecuciones del proyecto ofrecen una vía para comprobar esos detalles. La disponibilidad de registros es una ventaja de transparencia. Su publicación no significa que todos los resultados ya hayan recibido reproducción independiente o una revisión manual completa.

La reproducción independiente requeriría ejecutar las configuraciones especificadas y comprobar si persisten los patrones relevantes. Leer los registros puede respaldar una auditoría de los cálculos comunicados o de comportamientos individuales. Esas actividades aportan tipos de evidencia diferentes.

La cuestión causal sigue siendo especialmente exigente. Una diferencia de puntuación puede identificar una asociación entre configuración y resultado en condiciones controladas. Explicar la diferencia exige examinar los fallos y comprobar si un cambio propuesto los modifica.

Por ejemplo, un posible problema de tiempo de espera debería probarse cambiando el tiempo de espera mientras se preservan las demás condiciones relevantes. Un posible problema de pérdida de información exige inspeccionar qué información desapareció y si conservarla mejora los resultados. Ninguna de las dos explicaciones se deriva automáticamente de una posición baja.

La familiaridad con el benchmark introduce otra preocupación que merece investigación sin asumir conducta indebida. Un sistema optimizado frente a tareas públicas puede mejorar en esa distribución de tareas sin mejorar en igual medida en otros contextos. La evidencia procedente de tareas desconocidas ayudaría a establecer hasta qué punto se transfiere la mejora.

La cobertura de tareas presenta una limitación aparte. El mantenimiento de repositorios incluye convenciones organizativas, solicitudes ambiguas y expectativas de revisión humana que un benchmark fijo no puede captar por completo. Un benchmark puede seguir siendo útil mientras deja sin resolver esas cuestiones de despliegue.

La respuesta práctica es mantener la evidencia en proporción con la decisión. Un resultado público puede justificar una lista corta o una prueba específica. Sustituir el flujo de trabajo de desarrollo de un equipo requiere evidencia adicional de trabajo que se parezca a las responsabilidades reales de ese equipo.

Mantener juntas las configuraciones, los ejemplos de fallos y las decisiones de revisión facilita volver a examinar esas comparaciones. Una base de conocimiento consultable puede ayudar a preservar ese historial de evaluación junto con los documentos técnicos utilizados durante las pruebas.

La brecha de verificación no elimina el valor del experimento. Define lo que los resultados respaldan actualmente y qué trabajo adicional los reforzaría. Esta es una interpretación más útil que aceptar cada posición literalmente o descartar por completo la comparación.

Las próximas pruebas deberían seguir las actualizaciones, la reproducción y el trabajo sin supervisión

La evidencia de seguimiento más sólida conectará los cambios de versión con mejoras reproducibles en trabajos que vayan más allá de la comparación inicial.

La primera señal que conviene observar es el rendimiento actualizado del harness con un historial de versiones claro. Cuando un desarrollador modifica el software de ejecución, una repetición comparable puede mostrar si cambian la precisión, la eficiencia o la consistencia. Conservar la configuración anterior hace que esa comparación tenga sentido.

Una mejora en mediciones repetidas reforzaría la tesis de que la ingeniería del harness afecta materialmente a los resultados. Un resultado que desaparece en repeticiones comparables debilitaría la confianza en la mejora afirmada. Cualquiera de los dos resultados aporta más información que una insignia de ganador actualizada.

Esto también ofrece a los proveedores una forma constructiva de responder. Pueden identificar un patrón de fallo, explicar el cambio de implementación relevante y publicar evidencia sobre el resultado. Los lectores podrán entonces evaluar una afirmación de ingeniería concreta, en lugar de inferir calidad a partir de la reputación de un producto.

La segunda señal es la reproducción independiente con controles coincidentes. Un evaluador distinto debería documentar el modelo, las condiciones del proveedor, los ajustes de razonamiento, la versión de la tarea y la versión del harness. Las diferencias deben seguir siendo visibles, en lugar de integrarse en una puntuación aparentemente idéntica.

Si los resultados independientes preservan el orden general o los patrones específicos de cada modelo, aumenta la confianza en la comparación. Si los resultados divergen, eso apunta a condiciones que requieren un examen más detenido. El comportamiento del proveedor, los ajustes de ejecución y los detalles de medición se convierten en cuestiones de investigación, en lugar de explicaciones convenientes.

La reproducción no exige que cada cifra coincida exactamente. La cuestión relevante es si la conclusión resiste mediciones repetidas razonables. Los resultados cercanos deberían seguir siendo cercanos, salvo que evidencia adicional justifique diferenciarlos.

La tercera señal es el rendimiento en trabajo desconocido con criterios explícitos de éxito sin supervisión. Esto significa comprobar si el agente completa la tarea solicitada, verifica el resultado y gestiona adecuadamente los fallos. La intervención humana debería registrarse porque modifica lo que significa la «finalización autónoma».

Las mejoras consistentes en ese trabajo reforzarían la importancia práctica de los hallazgos de la clasificación. Las ganancias limitadas a tareas conocidas del benchmark reducirían su relevancia. La distinción importa más para el despliegue que otro pequeño movimiento en un promedio general.

Para los equipos que eligen software ahora, la evidencia respalda la comparación al nivel del emparejamiento real. Kimi Code, Hermes Agent, Pi, Claude Code, Codex y mini-swe-agent merecen evaluarse en las configuraciones que un equipo pretende utilizar. Sus nombres por sí solos no pueden resolver el resultado.

La clasificación de harnesses de Niklaus ofrece un punto de partida público para esa evaluación, con resultados de lanzamiento, intentos repetidos y registros accesibles. Su contribución duradera dependerá de si esas mediciones ayudan a explicar y mejorar el comportamiento de los agentes.

Antes de cambiar su flujo de trabajo de programación, compare una combinación preseleccionada con la configuración en la que ya confía usando trabajo de mantenimiento representativo. Registre la configuración exacta, la evidencia de finalización, el esfuerzo de revisión y los fallos que requieren intervención. Incluya tareas en las que un parche plausible no sea suficiente sin un paso de verificación exitoso. Vuelva a examinar la comparación después de una actualización significativa del harness, conservando los resultados anteriores para que los cambios sigan siendo comprensibles. Trate la clasificación pública como evidencia para esa decisión, pero deje que su propio flujo de trabajo tenga la última palabra. La pregunta que merece responderse es concreta: ¿qué combinación probada entrega trabajo que su equipo puede verificar, repetir y aceptar con la supervisión que realmente puede proporcionar?