DeepSeek, el agente de programación open source, está siendo penalizado en uno de los principales benchmarks por una conducta que normalmente se considera una buena práctica entre desarrolladores: limpiar y cerrar por completo los procesos que utiliza tras finalizar una tarea.
El problema salió a la luz cuando Joël Niklaus, investigador de optimización de entornos en Hugging Face, incorporó el DeepSeek Harness a su ranking de agentes de programación, que compara diez sistemas que ejecutan los mismos modelos subyacentes. Aunque DeepSeek está empatado estadísticamente en primer lugar en cinco evaluaciones, en la prueba concretamente de Terminal-Bench su rendimiento cae hasta la sexta posición debido a esa conducta automatizada que interfiere negativamente en ciertas tareas.
DeepSeek Harness, que está empatado en lo alto en varias pruebas, cae al sexto puesto en Terminal-Bench por fallar tareas que sí superan otros agentes.
Un hábito ordenado que perjudica
El principal escollo radica en que DeepSeek cierra los procesos en segundo plano justo al concluir una tarea, lo cual resulta problemático en tres pruebas de Terminal-Bench que requieren que esos procesos sigan activos para completarse satisfactoriamente.
En concreto, Niklaus observó que DeepSeek sólo superó 2 de las 36 pruebas realizadas con los modelos DeepSeek-V4.1-Flash y GLM-5.3-Flash. Frente a esto, agentes como OpenCode, Pi y Hermes Agent de Nous Research superaron todas las pruebas en igualdad de condiciones.
DeepSeek sólo logró superar 2 de 36 pruebas, frente al pleno éxito de OpenCode, Pi y Hermes Agent en las mismas condiciones.
Este comportamiento le restó entre 1,5 y 1,7 puntos porcentuales en sus puntuaciones. En escenarios con alta exigencia de razonamiento y empleando DeepSeek-V4.1-Flash, dicha penalización sobrepasó incluso la diferencia total de 1,3 puntos con respecto al líder del ranking.
El historial de cambios del ranking confirma que esta conducta de apagar procesos se atribuye directamente a DeepSeek y que los resultados no fueron modificados posteriormente.
La documentación técnica de DeepSeek explica que su registro local de trabajos es un componente diseñado para apagarse a corto plazo: “Debe seleccionarse cuando los trabajos deben vivir dentro del proceso del harness y morir con él”. Para trabajos que deban mantenerse activos tras reinicios o distribuirse entre procesos, se recomienda usar otros sistemas backend.
Mismo modelo, resultados muy diferentes
Niklaus lanzó su listado “Harness Leaderboard” el 5 de noviembre tras realizar más de 28.800 pruebas entre nueve agentes diferentes utilizando los modelos DeepSeek-V4.1-Flash, GLM-5.3-Flash y Flint. Manteniendo constantes el modelo, proveedor y esfuerzo de razonamiento, sólo cambiando el agente, comprobó que las diferencias eran notables.
Por ejemplo, Mini-swe-agent, un agente sencillo basado en bash, completó el 51,4% de las tareas, mientras que OpenClaw alcanzó tan sólo el 27,3%. Sin embargo, varios agentes permanecían estadísticamente empatados en la cabeza del ranking.
Los costes también mostraron variaciones considerables: Pi logró un 49,4% de éxito a un coste de 0,29 dólares por tarea resuelta, mientras que OpenCode requirió 3,35 dólares en la evaluación inicial. Thomas Wolf, cofundador de Hugging Face, resumió estas conclusiones con la frase: “mismo modelo abierto, diferente agente/harness => resultados muy distintos”.
The New Stack intentó recabar comentarios de DeepSeek sobre estos hallazgos, pero no obtuvo respuesta antes de la publicación.
La orquestación no garantiza el éxito
Garry Tan, presidente y CEO de Y Combinator, también ha llevado a cabo evaluaciones independientes con modelos Claude Opus 5.5 y GPT-6.1 Sol. Sus investigaciones revelan que, aunque las diferencias en la frecuencia de resolución de tareas entre agentes no fueron tan marcadas, sí lo fueron en los costes asociados.
Por ejemplo, en tareas multiusuario, OpenClaw con Opus 5.5 costaba aproximadamente el doble por tarea resuelta que otros agentes con el mismo modelo, debido principalmente a que enviaba repetidamente el contexto completo en cada solicitud.
También se analizaron las capacidades del flujo de trabajo gstack de Tan: en 46 intentos Opus 5.5 leyó las instrucciones pero nunca ejecutó cada paso según lo indicado, lo que generó costes prácticamente duplicados.
Los investigadores destacaron que las tareas eran relativamente sencillas, por lo que no está claro si seguir estrictamente las instrucciones habría mejorado los resultados. No obstante, estas pruebas refuerzan la importancia de validar con rigor no sólo los modelos, sino también los agentes/harness que los utilizan.
Estos resultados subrayan la necesidad de evaluar con el mismo cuidado el agente que el propio modelo.
