Metodología de Argusic

Cómo comprueba Argusic si el software real funciona y cómo puntúa a los AI coding agents. Todas las reglas de esta página son públicas a propósito: la idea es que cualquiera pueda revisar nuestro trabajo. Cualquier cambio en estas reglas se anota en el registro de cambios al final, entra en vigor a partir del siguiente ciclo de pruebas y nunca se aplica con carácter retroactivo.

1. En resumen

• Tomamos proyectos reales de código abierto y hacemos que AI agents intenten

instalarlos, iniciarlos y depurarlos sin ayuda humana, exactamente como lo haría un ingeniero nuevo en su primer día.

• Cada prueba se graba de principio a fin. Cada cifra publicada enlaza a su log

y a su grabación de terminal.

• Cada proyecto recibe un veredicto claro: funciona, funciona con servicios

simulados (mocks) o no pudimos verificarlo.

• Los agents se comparan en condiciones idénticas; tres ejecuciones cada uno,

cuenta el resultado intermedio, y los resultados muy inconsistentes se marcan y se apartan.

• No vendemos ningún agent ni aceptamos dinero para cambiar un resultado.

Argusic es el árbitro.

• La medición está automatizada. La redacción no: ningún modelo escribe una

frase de este sitio, cada cifra de una página es una plantilla rellenada a partir de una ejecución registrada, y una persona da su aprobación antes de que se publique nada. Consulta cómo se redacta.

2. La pregunta que responde

Dado un proyecto real de código abierto, ¿puede un AI coding agent, completamente por su cuenta, instalarlo, iniciarlo, resolver los errores y verificar que el software funciona, como un ingeniero en su primer día, sin ayuda humana?

3. Por qué proyectos recientes

Los benchmarks estáticos se degradan a medida que sus respuestas se filtran en los datos de entrenamiento. SWE-rebench (Badertdinov et al., 2025) ejecutó los mismos agents sobre SWE-bench Verified y sobre tareas recopiladas después de que ese benchmark fuera público, y las puntuaciones cambiaron mucho: su Tabla 2 indica que DeepSeek-V3-0324 resuelve el 39.7% de SWE-bench Verified y el 21.3% del conjunto filtrado por fecha, una diferencia de 18 puntos porcentuales en un solo modelo. Argusic prueba proyectos que son tendencia en las últimas semanas, con un grupo secreto que rota cada mes, así que no hay nada que memorizar.

4. Qué se mide

Medimos exactamente una cosa: la capacidad autónoma de hacer que el software real funcione. Cada agent evaluado es una combinación fija de un modelo en una versión fijada, un harness en una versión fijada, las instrucciones estándar publicadas de Argusic y límites idénticos de tiempo y recursos. Todos los agents reciben exactamente las mismas condiciones.

5. Agents evaluados

El primer ciclo está en curso. La lista de agents se publica con la primera clasificación. Cada agent es una configuración fija y fijada en versión, presentada con una identidad neutral de Argusic; sus versiones exactas se registran y se conservan para que cada cifra de la tabla se pueda rastrear hasta la configuración precisa que la produjo, y un resultado se puede reproducir a través de Argusic si se solicita (consulta "Cómo reproducir un resultado").

6. El grupo de proyectos

• 80% grupo público: la lista y las versiones exactas (hashes de commit) se

publican antes de cada ciclo.

• 20% grupo secreto: se elige entre proyectos que fueron tendencia en los

últimos 30 días, se publica solo cuando termina el ciclo y rota cada mes. Esto es lo que impide que los agents se ajusten a la prueba.

• Criterios de selección: una licencia permisiva, un README, variedad de

lenguajes y de dificultad, y la posibilidad de funcionar a un nivel básico sin cuentas de pago.

6a. Qué puede ser un proyecto evaluado

Un proyecto evaluado es algo que se le puede pedir a un agent que configure y ejecute. Argusic prueba hoy un tipo y está construido para añadir otros sin cambiar nada de cómo se obtiene un resultado: la rúbrica de puntuación, las reglas de evidencia y el vocabulario de los veredictos son idénticos en todas las fuentes, así que una cifra de una fuente significa lo mismo que una cifra de otra.

Fuente	Qué significa aquí "funciona"	Estado
Repositorio de código abierto	Clonar el commit fijado, instalarlo, iniciarlo y verificar que hace el trabajo que describe su propio README	En uso. 3669 proyectos probados
Modelo de Hugging Face	Descargar el modelo en una revisión fijada y ejecutar la inferencia exactamente como la documenta su model card, en un worker con GPU. Funciona cuando el fragmento documentado produce una salida en una máquina limpia sin que quien prueba lo reescriba	En uso. 1 proyecto probado
Hugging Face Space	Compilar e iniciar el Space a partir de su propia definición, después llegar a su interfaz y completar la interacción que anuncia	Declarada, no iniciada
Paquete publicado (npm, PyPI)	Instalar la versión fijada en un proyecto vacío y ejecutar el quickstart de su propio README	Declarada, no iniciada
Herramienta de un fabricante	Instalar e iniciar la compilación publicada por el propio fabricante, siguiendo solo sus propias instrucciones	Declarada, no iniciada
Plantilla de nube preconfigurada	Desplegar la plantilla como la documenta su propia ficha y comprobar que arranca y sirve lo que anuncia, sin que quien prueba la parchee antes	Declarada, no iniciada
Imagen de contenedor	Descargar la imagen en un digest fijado y ejecutar el comando que da su propia descripción, y después comprobar que hace lo que esa descripción afirma	Declarada, no iniciada
Servidor MCP	Instalar e iniciar el servidor como está documentado, conectar un cliente y confirmar que lista y responde las tools que anuncia	Declarada, no iniciada

La columna Estado de la tabla anterior no se escribe a mano. Se lee de la base de datos cada vez que se sirve esta página: una fuente aparece como en uso en cuanto un proyecto publicado de ese tipo tiene una ejecución registrada, y muestra el recuento. Es la misma regla que sigue cualquier otra cifra de este sitio, y significa que nadie tiene que acordarse de actualizar esta página cuando una fuente nueva produce su primer resultado.

Dos cosas hacen que un proyecto de Hugging Face sea distinto de un repositorio, y ambas se registran con la ejecución en lugar de disimularse. Necesita un worker con GPU, así que su costo por intento es mayor y su presupuesto se decide por separado. Y una model card suele documentar un fragmento de código en lugar de una aplicación, así que el comportamiento verificado es "el fragmento documentado produjo una salida", no "el producto funciona": la página de la ejecución dice cuál de los dos, con esas palabras, y la puntuación se obtiene de la misma manera.

La tabla dice "no iniciado" en lugar de "próximamente" a propósito. Una fuente cuenta como en uso el día en que se registra una ejecución real de ese tipo con su evidencia, y ni un día antes. Hasta entonces la fila es una declaración de alcance, nunca de resultados: ninguna página muestra un veredicto, un recuento, una clasificación ni una tarjeta para compartir de una fuente que no se ha ejecutado, y esta tabla es el único lugar donde se nombra una fuente prevista.

7. Una medición

1. Una máquina limpia de un solo uso (su entorno exacto se publica). No acepta

conexiones entrantes y se destruye al terminar la ejecución. El acceso de red saliente no se filtra en esta edición; lo que limita una ejecución es la máquina de un solo uso y las reglas de la clave del modelo que siguen a la lista. La máquina descarga solo el commit fijado, no el historial del proyecto, que no forma parte de la prueba.

2. El agent recibe una sola misión: hacer que este proyecto funcione, siguiendo

las instrucciones estándar publicadas.

3. Un límite de tiempo. Cada ejecución recibe uno de exactamente tres

presupuestos (la tabla que sigue a la lista), y el presupuesto asignado se muestra en la página de la ejecución.

4. Tres ejecuciones independientes; cuenta el resultado intermedio. Si los tres

resultados difieren en más del 30%, el conjunto se marca como inestable y se aparta de la tabla de ese ciclo.

5. Cada ejecución guarda un log completo y una grabación de terminal completa,

que se publican con los resultados.

6. Las aplicaciones de escritorio se inician en una pantalla virtual dentro de

la máquina (desde v1.1). "Iniciada" significa que el proceso principal de la aplicación arrancó en esa pantalla y siguió en marcha, o que respondió a un comando de versión o de ayuda. No se hace clic en nada; lo que se mide es si el software arranca en una máquina limpia, la misma pregunta que se le hace a cualquier otro proyecto. Se le indica al agent que no envíe imágenes a su modelo (desde v1.3): el modelo estándar solo acepta texto, y una captura de pantalla adjunta a un mensaje terminó la sesión antes del informe.

Los presupuestos de tiempo del punto 3:

Nivel	Presupuesto
standard	90 minutos
heavy	120 minutos
gpu	120 minutos

El presupuesto standard era de 45 minutos antes de v1.3: en la primera semana, 36 de 38 tiempos agotados de un mismo día fueron compilaciones que seguían en curso con todo el presupuesto consumido, así que se duplicó. El nivel heavy existe desde v1.2 para un proyecto que el Owner marca como heavy, o cuyo repositorio supera los 500 MB según GitHub, porque un juego grande o una aplicación de escritorio necesita ese tiempo para compilar. Un proyecto que necesita GPU recibe los mismos 120 minutos.

Las tres cifras anteriores no son decorativas. scripts/check-ttl-methodology.sh lee esta tabla y la compara con los presupuestos con los que el orquestador está configurado de verdad, y make test falla si no coinciden. Esa comprobación existe porque entre 2026-09-06 y 2026-09-11 el presupuesto de GPU del sistema en funcionamiento era de 240 minutos mientras esta página decía 120, y nada comparaba ambos valores (ISSUE-072).

La clave del modelo. Un agent necesita una clave para llamar a su modelo, y una ejecución corre código de un proyecto no confiable, así que esa clave es la credencial que más conviene limitar. Para los agents que llegan a su modelo a través de la capa de enrutamiento de Argusic, cada ejecución recibe su propia clave, creada solo para esa ejecución. Límite de gasto de la clave del modelo de cada ejecución: 3 USD. La clave se elimina cuando la ejecución termina, se cancela o agota el tiempo, y un barrido programado elimina cualquier clave que ya no pertenezca a un trabajo en curso. Si no se puede crear la clave de una ejecución, la ejecución no se inicia y se reintenta; nunca se usa una clave compartida en su lugar. Los agents que usan el servicio propio del fabricante de su modelo lo llaman con una clave compartida que guarda Argusic, no con una clave por ejecución; pasarlos a claves por ejecución está en nuestra lista de pendientes. La línea del límite anterior la lee scripts/check-cost-methodology.sh, que hace fallar make test si no coincide con el valor configurado, por la misma razón que los presupuestos de tiempo.

8. Puntuación, sobre 100

• Instalación correcta: 30
• Inicio o pruebas correctos: 30
• Recuperación de errores: 20, en proporción a los errores encontrados que se

corrigieron de forma válida

• Profundidad de verificación: 20 (verificado funcionando de verdad: 20;

verificado con servicios simulados: 12; sin verificar: 0)

El resultado de una ejecución es uno de estos:

Resultado	Significado
pass_full	Funcionó y se verificó de verdad
pass_mock	Funcionó, verificado con servicios simulados
fail	No se instaló o no se inició
timeout	Se quedó sin tiempo

Las cuatro líneas de puntuación dejan algunos casos implícitos. Se resuelven aquí y no solo en el código, porque una regla que nadie puede leer es una regla que nadie puede comprobar. La puntuación la calcula un programa determinista con pruebas que cubren cada regla de abajo; ningún modelo de IA interviene en la puntuación en ningún momento.

• Si nada salió mal, la recuperación de errores obtiene los 20 completos.

Puntuar cero penalizaría a un agent porque el proyecto se instaló sin problemas, lo que mide el proyecto, no el agent.

• En caso contrario, la recuperación de errores es la proporción de errores

encontrados que se corrigieron, sobre 20. Una ejecución nunca puede declarar más errores corregidos que encontrados; una ejecución así se rechaza.

• El inicio requiere la instalación: un agent que no instaló el software no

pudo haberlo iniciado.

• La profundidad de verificación requiere el inicio: sin un inicio correcto no

hay nada que verificar, así que la profundidad puntúa 0.

• Instalado e iniciado pero sin verificar no es un aprobado. Puntúa 80 de 100 y

sigue contando como fallo, porque la pregunta es si el agent verificó que el software funciona, y un inicio sin verificar no la responde.

• Un tiempo agotado puntúa 0 en todas las líneas. No hay crédito parcial: el

agent no terminó dentro del mismo límite que tuvo cualquier otro agent.

• Una ejecución sin log y grabación completos no es válida y se vuelve a

ejecutar. Nunca se puntúa y nunca llega a la tabla.

9. De muchas ejecuciones a una puntuación en la tabla

La puntuación califica un par proyecto y agent. La clasificación necesita una sola cifra por agent, y cómo se combinan es una decisión de metodología, así que se explica aquí.

La puntuación de un agent en la tabla es el valor intermedio de sus puntuaciones intermedias por proyecto. Volvemos a usar el valor intermedio, en lugar de una media, por la misma razón: un proyecto desastroso no debería hundir a un agent capaz, y un proyecto con suerte no debería elevar a uno débil.

Dos tipos de resultado se excluyen de esa cifra, y ambos se siguen mostrando en la tabla para que la exclusión sea visible y no silenciosa: los resultados marcados como inestables (consulta la sección siguiente) y todos los resultados de un proyecto marcado como en revisión (consulta el control de calidad del entorno).

Un agent cuyos resultados se excluyen todos no tiene puntuación en la tabla. Se muestra al final sin puntuación en lugar de eliminarse, porque un agent que se probó y no produjo nada utilizable es en sí un resultado, y ocultarlo favorecería discretamente al resto.

La tasa de aprobados cuenta cada intento que hizo un agent en el ciclo, incluidos los fallos y los tiempos agotados. Consulta independencia y sin selección de resultados más abajo.

10. Dispersión e inestabilidad

La dispersión es el rango de las tres ejecuciones como porcentaje de su valor intermedio:

spread = (highest - lowest) / middle * 100

Un conjunto se marca como inestable cuando la dispersión es estrictamente mayor que el 30%. Exactamente el 30% no supera el 30% y se queda en la tabla. De la fórmula se derivan dos casos límite:

• Si el valor intermedio es 0 pero alguna ejecución puntuó por encima de 0, la

dispersión no tiene límite y el conjunto es inestable: un resultado que apareció una vez y no las otras dos es el resultado menos reproducible que existe.

• Si las tres ejecuciones puntuaron 0, la fórmula divide entre cero y no tiene

valor, así que la dispersión se define como 0 por esta regla y el conjunto es estable. Un fallo constante es una medición reproducible y pertenece a la tabla como tal.

11. El veredicto del proyecto

La tabla clasifica agents. El veredicto responde otra pregunta, sobre el propio proyecto: ¿puede un recién llegado, en forma de AI agent, hacer que este software funcione hoy?

Las pruebas son adaptativas, porque la evidencia es asimétrica. Un aprobado demuestra que el proyecto funciona; un solo fallo no demuestra nada por sí mismo, porque puede deberse al agent y no al proyecto.

1. Primero, el agent estándar se ejecuta una vez. Cualquier aprobado termina el

proceso: un aprobado completo da "funciona", un aprobado con servicios simulados da "funciona con mocks". No hay razón para seguir probando algo que ya ha demostrado que funciona.

2. Si falló, un reintento con el mismo agent descarta una casualidad puntual.
3. Si sigue fallando, el veredicto es "no se pudo verificar", nunca "roto":

Argusic informa de lo que los agents pudieron hacer y dice exactamente eso (desde v1.3: dos intentos completos con el agent estándar lo deciden). Se puede ejecutar un agent más potente si se solicita; cuando se hace, su aprobado deja el proyecto en "funciona" (el registro muestra qué agent lo verificó) y su fallo también deja "no se pudo verificar".

Un intento completo es aquel cuya grabación muestra al agent trabajando hasta su propio final o hasta el límite de tiempo. Un intento que las propias herramientas de Argusic cortaron antes de tiempo (un harness que no pudo leer el informe del agent, un error de instrumentación ajeno al proyecto) se marca como no válido con el motivo guardado en la ejecución, sigue publicado con su evidencia y no cuenta.

El veredicto es el mejor resultado que alcanzó cualquier intento:

• funciona: algún intento funcionó y se verificó de verdad.
• funciona con mocks: el mejor intento funcionó, verificado con servicios

simulados, normalmente porque el proyecto necesita credenciales reales de terceros.

• no se pudo verificar: ningún aprobado tras dos intentos completos (o tras

el agent más potente, cuando se ejecutó). La página lo dice y enlaza el log que muestra dónde se detuvo cada intento.

• aún no verificado: las pruebas no han terminado.

Cada intento se publica con toda su evidencia, sea cual sea el veredicto, con una excepción: una grabación de la que no se puede demostrar que esté libre de una credencial activa se retiene y su ejecución se repite (sección 17, "Redacción de seguridad").

12. Qué no mide Argusic

Para evitar malentendidos, lo decimos con claridad. Argusic no mide la calidad a largo plazo del código que escribe un agent, la seguridad de sus correcciones ni la experiencia de producto a fondo, función por función. Mide una sola cosa: la capacidad autónoma de hacer que el software real funcione.

13. Independencia y sin selección de resultados

• Argusic no acepta dinero para alterar su metodología, su puntuación ni sus

clasificaciones.

• El patrocinio de cómputo, si lo hay, compra exactamente una cosa: el modelo

del patrocinador se añade a la lista evaluada en condiciones idénticas a las de cualquier otro agent, con el patrocinio indicado junto a los resultados.

• Cada ejecución de cada agent cuenta y se publica. No hay pruebas privadas

seguidas de la publicación solo del mejor resultado. Si un agent está en la tabla, todos sus intentos del ciclo constan en el registro.

14. Transparencia del harness

El harness (el andamiaje, las herramientas, las instrucciones y los límites que rodean al modelo) es público e idéntico para todos los agents de un ciclo. Cualquier diferencia de puntuación debe poder atribuirse al agent, no a la infraestructura. Los cambios en el harness solo se publican entre ciclos y se anotan en el registro de cambios.

15. Control de calidad del entorno

Cuando un proyecto falla con todos los agents, se marca automáticamente como en revisión y se excluye de la puntuación hasta que una persona lo revisa: el fallo puede deberse al entorno o al proyecto y no a los agents. Un problema de configuración común nunca debería puntuarse como un fallo del agent.

16. Verificar significa decodificar, no sondear

Que un archivo exista no es un resultado, y leer su cabecera no es una comprobación. ffprobe -show_streams, file y un recuento de bytes informan todos de un contenedor y no decodifican nada: un video cuyos fotogramas son todos verdes supera los tres exactamente igual que uno bueno. La regla, vigente desde v1.4, es que un agent informa de lo que decodificó, nunca de lo que esperaba.

• Decodifica lo que produjiste. ffmpeg -v error -i FILE -f null - para

video y audio, un decodificador real para una imagen, imprimirlo para el texto. Informa del comando y de lo que devolvió.

• Nunca afirmes lo que no observaste. El prompt que le diste a un modelo no

es evidencia de lo que salió; lo que promete un README no es evidencia de que haya ocurrido aquí. "81 fotogramas decodificados sin errores" es un hallazgo. "Un video de dos gatos" no lo es.

• Decodificar es lo que da la máxima profundidad de verificación.

test_depth es el campo que registra hasta dónde llegó una ejecución (sección 8: tier1_real es "verificado funcionando de verdad" y puntúa 20, tier2_mock es "verificado con servicios simulados" y puntúa 12, tier3_none es "sin verificar" y puntúa 0). tier1_real requiere una decodificación correcta, no la capacidad de describir una salida.

• verified_how lleva la prueba. Es el campo del informe que contiene el

comando exacto que ejecutó el agent para verificar su propia salida y lo que devolvió ese comando. "not verified" es una respuesta aceptada y útil.

• **final_state es la frase de cierre del propio agent sobre lo que

ocurrió**, y se publica literalmente en las páginas de la ejecución y del proyecto, así que cada hecho que contiene debe ser uno que el agent observó con sus propios comandos.

17. Integridad de la evidencia

Dos capas, que nunca se confunden.

La capa de evidencia es en bruto y permanente: cada ejecución produce una grabación de terminal completa de la sesión real, y para las aplicaciones gráficas un video en bruto de la sesión, además de logs completos. A cada archivo se le calcula una huella al llegar y se guarda para siempre. Cualquiera puede reproducir la sesión completa sin editar.

La capa de presentación es derivada: cualquier video o imagen para redes sociales es un render de la evidencia. Las ediciones permitidas son acelerar, recortar por duración, subtítulos tomados de la cronología registrada de errores y correcciones, y voz en off. Las ediciones prohibidas son reordenar eventos, empalmar sesiones distintas, ocultar fallos o alterar la sustancia de lo que hizo el agent. Cada video publicado enlaza de vuelta a su evidencia.

Se aplican tres transformaciones derivadas a la grabación antes de servirla, y ninguna cambia la sustancia del trabajo del agent:

• Redacción de seguridad. Se eliminan los valores de credenciales activas.

Nada impide que un repositorio no confiable induzca al agent a imprimir el entorno, que contiene la única clave que el agent necesita, así que cualquier valor con forma de secreto se elimina antes de guardar o servir la grabación. Una grabación de la que no se puede demostrar que esté libre de una credencial se retiene, y su ejecución se repite.

• Material de claves generado. Algunos proyectos generan claves como parte

de su función (un gestor de contraseñas, una herramienta de PKI), y el agent puede ejecutarlos e imprimir el resultado. Eso es salida real de la prueba, no una credencial de Argusic, así que no retiene la ejecución: en la copia servida de la grabación y del log se enmascara el cuerpo de cualquier clave privada de ese tipo, el archivo en bruto se archiva con su propia huella registrada en la ejecución, y la página de la ejecución indica que se aplicó la máscara. Un cuerpo del que no se puede demostrar que esté enmascarado sigue reteniendo la ejecución (desde v1.2, decisión del Owner 2026-09-05).

• Marca neutral del agent. La grabación se presenta con la voz de Argusic

Agent: se suprime el banner de arranque de la herramienta subyacente (que nombra a su fabricante, proveedor y modelo), igual que una vista formateada sustituye la salida en bruto de la máquina. Esto nunca edita los comandos que ejecutó el agent ni los cambios que hizo; esos aparecen completos. Tampoco censura los nombres de fabricantes que aparecen de forma natural en rutas de archivos, nombres de paquetes o el propio código del repositorio, que forman parte del trabajo real.

Se aplica una transformación de presentación al texto citado (decisión del Owner 2026-09-04): cuando una página muestra la frase de estado final del propio agent ("What the test found") o la descripción de GitHub de un repositorio, un guion largo que escribió el autor se muestra como una coma o un punto para que la página siga la puntuación de la casa. El informe guardado, el registro del repositorio, el log, la grabación y las imágenes generadas a partir de la grabación no se tocan; las palabras y su orden nunca cambian.

Regla permanente: cada cifra se rastrea hasta un log, y cada fotograma se rastrea hasta una grabación de la sesión real.

18. Cómo reproducir un resultado

La parte del proyecto de cada resultado es totalmente pública: el commit exacto probado, el entorno publicado, las instrucciones estándar y el log y la grabación completos. La página de cada ejecución contiene todo esto. El agent es una configuración fija de Argusic, fijada en versión, con una identidad neutral; Argusic guarda sus versiones exactas y puede volver a ejecutar un resultado para reproducirlo. La lista pública de proyectos y la divulgación del grupo secreto se publican junto con la primera clasificación.

19. Impugnar un resultado

Si un mantenedor o un laboratorio cree que un resultado es incorrecto, puede impugnarlo. Escribe a [email protected] con el enlace de la ejecución. Revisamos el log y la grabación completos frente a la reclamación y respondemos. Si el resultado se vio afectado por un problema de entorno o de configuración por nuestra parte, lo volvemos a ejecutar y corregimos el registro con una nota; si la evidencia respalda el resultado original, explicamos lo que muestra la grabación. La evidencia original nunca se edita ni se elimina.

20. Registro de cambios

Cada edición lleva dos fechas, y responden a preguntas distintas. Redactada es el día en que la regla se anotó en este documento. En vigor desde es el día en que se midió de verdad la primera ejecución con ella, según los registros de ejecución, no según este archivo. Normalmente coinciden. Cuando no, mandan los registros de ejecución y se indican aquí, porque una edición que llegó a las máquinas antes de llegar a esta página es justo lo que un registro de cambios existe para dar a conocer. Ninguna edición se aplica nunca con carácter retroactivo: una ejecución conserva las reglas que estaban en vigor el día en que se ejecutó.

Las ediciones v0.2 a v1.0 se anotaron todas el 2026-08-31, en el commit que creó la primera edición pública; sus fechas de abajo son los días en que se decidieron las propias reglas, antes de la primera medición.

• v0.2 (2026-08-29): explicó los casos que la rúbrica de puntuación dejaba

implícitos (recuperación de errores con cero errores, las dependencias entre instalación e inicio, los tiempos agotados, las ejecuciones no válidas) y la fórmula exacta de la dispersión con sus dos casos límite. Redactada antes de la primera medición, así que no se aplicó nada con carácter retroactivo.

• v0.3 (2026-08-30): explicó cómo se combinan los resultados por proyecto en

una sola cifra de la tabla (el valor intermedio de los valores intermedios por proyecto), qué resultados se excluyen y que un agent sin nada puntuable se muestra sin puntuación en lugar de eliminarse.

• v0.4 (2026-08-30): añadió el veredicto del proyecto (pruebas adaptativas:

agent estándar, un reintento y luego un agent más potente, parando en el primer aprobado). La puntuación de la tabla no cambió.

• v1.0 (en vigor desde 2026-08-31, redactada 2026-08-31): primera edición

pública. Ninguna regla cambió respecto a v0.4; esta edición reordena el documento, define los términos en lenguaje sencillo y añade las secciones de reproducción e impugnaciones.

• v1.1 (en vigor desde 2026-09-04, redactada 2026-09-04): las aplicaciones de

escritorio se inician en una pantalla virtual dentro de la máquina de prueba (sección 7, punto 6), para que se puedan medir los proyectos con interfaz gráfica. La imagen de la máquina también incorporó los entornos de ejecución de escritorio habituales y herramientas de compilación nativas; el digest de la imagen se registra en cada ejecución, así que los resultados de antes y de después se pueden distinguir. Puntuación sin cambios.

• v1.2 (en vigor desde 2026-09-04, redactada 2026-09-05): el nivel heavy

(sección 7, punto 3): los proyectos grandes reciben 120 minutos en la misma clase de máquina, según la marca del Owner o un tamaño de repositorio de 500 MB, y el presupuesto se muestra en la página de la ejecución. La máquina descarga solo el commit fijado. La sección 17 incorpora la transformación de material de claves generado. Puntuación sin cambios. Esta edición se anotó primero aquí como vigente desde 2026-09-05; los registros de ejecución muestran tres proyectos heavy (cataclysm-dda, veloren, supertux) ya medidos con el presupuesto de 120 minutos el 2026-09-04, así que la fecha anterior es la que figura arriba.

• v1.3 (en vigor desde 2026-09-05, redactada 2026-09-05): el veredicto se

decide tras dos intentos completos con el agent estándar (sección 11); el agent más potente ya no forma parte de la cadena estándar. Los intentos cortados antes de tiempo por las propias herramientas de Argusic no son válidos y no cuentan (92 ejecuciones así entre 2026-08-30 y 2026-09-05 se marcaron de esa forma, con el motivo en cada ejecución). Límite de tiempo estándar de 90 minutos (sección 7, punto 3); ninguna imagen al modelo (punto 6). Puntuación sin cambios.

• v1.4 (en vigor desde 2026-09-07, redactada 2026-09-07): verificar significa

decodificar, no sondear (sección 16). Un agent debe decodificar lo que produjo e informar del comando que usó, nunca puede afirmar nada que no haya observado y obtiene tier1_real solo con una decodificación correcta. Un nuevo campo del informe, verified_how, contiene ese comando y su resultado, y "not verified" es una respuesta aceptada. Las primeras ejecuciones con verified_how se registraron el 2026-09-07. Puntuación sin cambios. Esta edición vino de un lector, no de nosotros. Alguien que vio un reel publicado preguntó si habíamos visto fallos de MP4 válido con fotogramas corruptos, y el cast de la sesión mostró que el agent había ejecutado justo la comprobación de cabecera que no puede detectar uno. La mitad de la frase que informó era verificable (códec, dimensiones, número de fotogramas, duración, todo leído de la cabecera) y la otra mitad no: la descripción de lo que mostraba el video era el prompt de la model card, repetido como si fuera una observación. Esa frase se había publicado literalmente en un reel, un subtítulo y una página de proyecto (ISSUE-056).

• v1.5 (en vigor desde 2026-10-08, redactada 2026-10-08): corrige la

descripción de la red de la máquina de prueba y de la clave del modelo en la sección 7 para que coincida con el sistema tal como está construido, y arregla la numeración de la lista de esa sección moviendo la tabla de presupuestos de tiempo detrás de la lista (así "sección 7, punto 6" en v1.1 y v1.3 vuelve a ser el punto 6). Antes de esta edición la sección 7 decía que la máquina tenía una "red restringida"; el tráfico saliente de la máquina no se filtraba, y esta edición lo dice. También explica la clave del modelo por ejecución, su límite de gasto de 3 USD y su eliminación, incluido que las ejecuciones canceladas y las paradas de emergencia ahora también eliminan la clave (antes del 2026-10-08 no lo hacían), y que los agents que usan el servicio propio del fabricante de su modelo usan una clave compartida. Es una corrección de la descripción, no un cambio de ninguna regla de puntuación ni de medición: ninguna ejecución anterior se reetiqueta, nada se midió con una regla distinta y la edición no se aplica con carácter retroactivo. Puntuación sin cambios.

Apéndice: estimaciones de hardware, qué cabe y a qué velocidad

Las estimaciones de abajo aparecen junto a los portátiles y equipos de sobremesa para programación, IA y ciencia de datos que lista Argusic.

Este apéndice no forma parte de las reglas del benchmark anteriores y no cambia ninguna edición: explica las estimaciones que Argusic muestra junto a los portátiles y equipos de sobremesa que lista a la venta, que son aritmética sobre las cifras publicadas por los fabricantes, nunca mediciones. Las cifras de esta sección las calcula un único archivo compartido (lib/hardware-estimates.ts), y ninguna puede cambiar sin que ese archivo y su prueba cambien en el mismo commit.

El listado de hardware de Argusic muestra, para cada portátil y equipo de sobremesa, el mayor tamaño de modelo que puede alojar y un límite superior de la velocidad a la que puede generar texto. Ambos son Estimados: se calculan a partir de las especificaciones publicadas por el fabricante con las fórmulas de abajo. Argusic no ha ejecutado ningún modelo en estas máquinas. Cuando Argusic mide de verdad una máquina, esa cifra lleva la etiqueta Medido, enlaza al log de su ejecución y nunca se mezcla con una estimación.

Una estimación solo se muestra cuando se conocen todos los datos de entrada. Si falta el tamaño de la memoria, el tipo de memoria o el ancho de banda del chip, la página dice "Desconocido" en lugar de adivinar.

Datos de entrada y su origen

• Memoria para el modelo: la memoria en la que puede residir un modelo. En una máquina con GPU dedicada, es la VRAM de la GPU. En Apple silicon, AMD Ryzen AI Max y NVIDIA GB10, es la memoria unificada que comparten la CPU y la GPU. Se lee de la ficha del producto.
• Ancho de banda de memoria: se lee de la página de especificaciones o la hoja de datos del propio fabricante del chip o de la GPU (Apple, NVIDIA, AMD), una fila de referencia por chip, cada una con un enlace a la página de la que procede. Un chip cuyo fabricante no publica su ancho de banda no muestra ancho de banda en la página. Argusic no calcula el ancho de banda a partir del ancho del bus y la velocidad de la memoria, ni lo copia de bases de datos de terceros.
• Tamaño del modelo: el número de parámetros, en las cinco clases de tamaño del filtro: 7-8B, 14B, 27-32B, 70B, 120B y más. Cada clase se comprueba con su tamaño máximo (8B, 14B, 32B, 70B, 120B), así que si cabe, cabe toda la clase.

Memoria: qué tamaño de modelo cabe

Un modelo necesita espacio para tres cosas.

1. Pesos. Argusic supone la cuantización Q4_K_M de llama.cpp, a 4.8944 bits por peso (README de quantize de llama.cpp):

bytes de pesos = parámetros x 4.8944 / 8. Ejemplo, calculado y no medido: un modelo de 70B necesita 42.8 GB de pesos.

2. Contexto (caché KV). Según la fórmula de NVIDIA (Mastering LLM Techniques: Inference Optimization, NVIDIA Technical Blog, 2023-11-17):

bytes de caché KV por token = 2 x capas x (cabezas x dimensión de cabeza) x bytes por valor. Los modelos modernos comparten cabezas de clave/valor entre las cabezas de atención (grouped-query attention), así que aquí "cabezas" es el número de cabezas de clave/valor que el modelo almacena realmente en caché. Argusic reserva 8,192 tokens de contexto con precisión de 16 bits (2 bytes, el tipo de caché predeterminado de llama.cpp), usando la configuración publicada de un modelo denso abierto por clase: Qwen3-8B, Qwen3-14B, Qwen3-32B, Qwen2.5-72B-Instruct y Mistral-Large-Instruct-2411.

3. Sobrecarga del entorno de ejecución. Argusic reserva 1 GB para los búferes propios del entorno de inferencia.

El contexto de 8,192 tokens y la sobrecarga de 1 GB son la reserva de Argusic, una decisión de criterio y no una medición. Los contextos más largos necesitan más memoria; un modelo que cabe aquí puede no caber con una conversación mucho más larga.

Cuánta memoria de la máquina cuenta. Cuenta toda la VRAM de una GPU dedicada. De la memoria unificada o del sistema, Argusic cuenta el 75% y deja el 25% para el sistema operativo y otros programas. Esto coincide con lo que AMD indica para sus propios chips de memoria unificada: hasta 96GB de 128GB se pueden convertir en VRAM (AMD), y 64GB permiten hasta 48GB (AMD).

Los tamaños de memoria se leen como 10^9 bytes por GB, la misma unidad que usan los fabricantes para el ancho de banda. La memoria se dimensiona en realidad en unidades binarias, así que esto subestima la capacidad en torno a un 7% y hace que cada ajuste sea ligeramente conservador.

El requisito resultante para cada clase, calculado con las reglas anteriores:

Clase	Pesos (Q4_K_M)	Reserva de contexto	Sobrecarga	Necesita	VRAM desde	Memoria unificada desde
7-8B	4.89 GB	1.21 GB	1 GB	7.10 GB	7.10 GB	9.47 GB
14B	8.57 GB	1.34 GB	1 GB	10.91 GB	10.91 GB	14.54 GB
27-32B	19.58 GB	2.15 GB	1 GB	22.73 GB	22.73 GB	30.30 GB
70B	42.83 GB	2.68 GB	1 GB	46.51 GB	46.51 GB	62.01 GB
120B y más	73.42 GB	2.95 GB	1 GB	77.37 GB	77.37 GB	103.16 GB

Así, por ejemplo, una GPU de 8GB aloja la clase 7-8B, una GPU de 24GB la clase 27-32B y 64GB de memoria unificada la clase 70B. Una máquina por debajo de la primera fila se muestra como que no le cabe ninguna clase.

Velocidad: un límite superior, no una predicción

Generar cada token requiere leer una vez de memoria todos los pesos del modelo, así que la generación de texto está limitada por el ancho de banda de memoria (NVIDIA: "Model execution is frequently memory-bandwidth bound"). Eso da un techo:

tokens por segundo, como máximo = ancho de banda de memoria / bytes de pesos.

Ejemplo, calculado y no medido: un chip con 546 GB/s que ejecuta un modelo de 8B en Q4_K_M (4.89 GB de pesos) no puede superar unos 111 tokens por segundo.

La velocidad real siempre es menor. El límite ignora el tiempo dedicado a leer el contexto, el cálculo y la sobrecarga del software. Las mediciones recopiladas en la discusión #4167 de llama.cpp muestran que la velocidad aumenta con el ancho de banda, pero por debajo de lo lineal. Para Llama 2 7B en Q4_0 en Apple silicon: M3 Max (400 GB/s) 66.31 tokens por segundo, M4 Max (546 GB/s) 83.06, M2 Ultra (800 GB/s) 94.27. Pasar de 400 a 546 GB/s (1.37 veces el ancho de banda) dio 1.25 veces la velocidad; duplicarlo a 800 GB/s dio 1.42 veces. Lee el límite como "esta máquina no puede ser más rápida que esto", nunca como "esta máquina funciona a esta velocidad".

El límite supone un modelo denso, en el que se leen todos los pesos para cada token. Los modelos mixture-of-experts leen solo los expertos activos para cada token, así que pueden ir más rápido de lo que sugiere el límite para su tamaño total.

Memoria para el modelo por dólar

Uno de los órdenes de ese listado es la memoria para el modelo por dólar: los gigabytes de memoria para el modelo (VRAM o memoria unificada) divididos entre el precio actual en Amazon, con la fecha del precio indicada. Responde a "qué aloja el modelo más grande por este dinero". No es una clasificación de calidad ni de velocidad, y una comisión nunca la cambia.

Lo que no son estas estimaciones

• No son benchmarks. No se ejecutó ningún modelo en las máquinas listadas para obtenerlas.
• No cubren la duración de la batería, el calor, el ruido ni el rendimiento sostenido bajo carga.
• Suponen un usuario, una conversación y pesos Q4_K_M al estilo de llama.cpp. Otros entornos de ejecución, otras cuantizaciones y contextos más largos cambian la respuesta.