Los modelos locales pierden ante Opus y Codex: 0,21 puntos en un MacBook frente a 1,00 de Codex

¿Es posible tener un «sistema agéntico del juicio final» que funcione sin suscripción y sin reglas ajenas? El autor del estudio en Habr, desarrollador del proyecto open-daimon, lo probó en la práctica. Dio la misma tarea a modelos en la nube, a un MacBook Pro con Apple M5, a un portátil gaming con RTX 5080 y a un NVIDIA DGX Spark. La nube quedó muy por delante: Codex obtuvo 1,00, Opus 5.5, 0,96, y el mejor resultado en el MacBook fue 0,21. Una salvedad importante: en la parte publicada del material, el texto se interrumpe en la descripción de la última ejecución del modelo denso en el Spark, así que no conocemos las conclusiones finales del autor.

Por qué hicieron falta modelos locales y cómo está diseñada la tarea

El autor expone sus motivos sin rodeos. Anthropic prohíbe, en sus condiciones para consumidores residentes en el EEE y Suiza, el uso comercial de Claude.ai, Pro y Max, de modo que trabajar en Claude Code con la suscripción Max infringe formalmente las normas. Menciona además casos en los que Claude se negó a ayudar con el acceso root en un televisor LG propio, y el de un investigador al que bloquearon la cuenta tras analizar un firmware con ChatGPT (esto último son solo sus palabras; OpenAI no lo ha comentado). A ello suma la desaparición de pesos «sin censura» en Hugging Face y la verificación del pasaporte a través de Persona desde abril.

La prueba se basó en el repositorio minibank: unas 700 líneas de Python, un libro mayor (ledger) multidivisa y un archivo DECISIONS.md con las decisiones del equipo. La petición estaba redactada como la de un jefe: el extracto no cuadra con el saldo, averigua por qué, arréglalo, comprueba el resultado y revisa si ocurre lo mismo en algún otro sitio. Las trampas son siete: un conversor señuelo con un docstring que dice «úsese en todas partes», una tasa de cambio corregida con carácter retroactivo, el límite de mes en UTC, la comisión en una línea aparte, una exportación CSV con hora ISO, un conversor antiguo que no se debe tocar y un test que consolida cifras erróneas.

La puntuación se calculó sin que el agente lo supiera: 20 tests ocultos aportan la mitad, siete condiciones «sutiles», el 15%, nueve correcciones erróneas que los propios tests del agente deberían detectar, una cuarta parte, y las reglas, el 10%. La escala está reajustada de modo que 0 significa «no cambió nada» y un valor negativo, «rompió más de lo que arregló». El límite es de 20 minutos.

Qué mostraron la nube, los portátiles y el DGX Spark

Referencia en la nube: Codex (GPT-6.1 Sol, medium) terminó en 101 segundos y ≈$0,14 por ejecución, Opus 5.5 en 91 segundos y $0,30, y Claude Fable 5.1 en 288 segundos y $1,79. Los tres leyeron DECISIONS.md, esquivaron el señuelo y actualizaron el test traidor. La diferencia está solo en los tests propios: Codex detectó 9 correcciones erróneas de 9; Opus y Fable, 8 cada uno. Las ejecuciones repetidas mostraron que se trata de ruido: Opus y Fable también llegaron a obtener 0,92.

MacBook Pro M5 con 32 GB: Qwen3 Coder 30B A3B (MoE, 4 bits) genera 52 tokens/s con un prefill de 743 tokens/s, pero sustituyó el conversor y siguió recalculando la transferencia: puntuación 0. Qwen3.8 27B (5,4 tokens/s) leyó DECISIONS.md, pero en 20 minutos no hizo ni una sola corrección. La mejor fue Gemma 4 12B: 0,21 en 575 segundos; tomó el importe contabilizado en lugar de recalcularlo, pero se saltó el UTC, la hora ISO y la comisión. Ese resultado se dio solo en tres de diez ejecuciones; en otra, fue −0,17. Los ajustes de sampling no redujeron la dispersión.

Portátil gaming con RTX 5080 (16 GB de VRAM) y Qwen3.6-35B-A3B: con un contexto de 42 mil tokens, la velocidad subió de 9,5 a 94 tokens/s tras una distribución manual de capas en LM Studio. Las 40 capas están en la GPU, los pesos de los expertos en la CPU en el 40% de las capas y la KV-cache en q8_0.

El autor atribuye la caída anterior a que LM Studio sacaba a la CPU capas enteras, atención incluida. Sin embargo, la velocidad no mejoró la calidad: el harness ligero pi logró 0,31 en 285 segundos y OpenCode, 0,14, sin cumplir el límite de tiempo. OpenCode envía unos 15 mil tokens en el primer paso, frente a 2 200 de pi, y su modelo generó 55 mil tokens de razonamiento, frente a 11 mil.

En el DGX Spark (chip GB10, 128 GB de memoria unificada, vLLM, NVFP4, un formato de 4 bits con soporte por hardware en el chip), Qwen3.6-35B-A3B, destilada sobre Opus, obtuvo 0,25: 12 de los 20 tests ocultos y 3 de las 7 condiciones sutiles. Este modelo falló los meses UTC, la hora ISO y la comisión en las cinco ejecuciones, repartidas entre dos máquinas, dos servidores y dos harness. ThinkingCap-Qwen3.8-27B, un modelo denso, con un límite de 10 minutos dejó el diff vacío, aunque en su razonamiento identificó correctamente el error principal; sin límite empleó 987 segundos y obtuvo 0,92.

Conclusión práctica

El autor advierte de que la tarea es una sola, en Python, y de que normalmente hay una o dos ejecuciones, por lo que esta prueba no permite distinguir entre modelos locales similares. Pero la brecha entre la nube y los modelos locales rápidos no se explica por el ruido. En la práctica se ven dos cosas. Un harness ligero y el ajuste manual del offload aceleran varias veces un agente local, pero la calidad la determina el tamaño del modelo. Y el único resultado local al nivel de la nube, el modelo denso de 27B en el Spark, requirió casi 16,5 minutos en lugar de minuto y medio.