A-CODE-LLM Bench: Benchmark de codificación agente
Realizamos un benchmark de los mejores modelos de lenguaje grandes (LLMs) en 10 tareas de desarrollo de software usando una herramienta CLI agente. Ejecutamos ~3,500 pasos de validación automatizados por modelo tanto en la capa de API como en la de UI.
Resultados de A-CODE-LLM Bench
Cada alias se ejecutó 3 veces en 10 tareas (30 muestras por alias, 400 celdas por iteración en 40 alias). Consulta más detalles en metodología.
- Sonnet de gama media supera al Opus insignia. Ambas versiones de Sonnet puntúan por encima de cualquier Opus, incluido Opus 4.8 (0.702). El nivel más caro de Anthropic no es su mejor codificador.
- La cima ya no es solo de Anthropic: Grok 4.5 (0.732) supera a todas las variantes de Opus. La nueva insignia de OpenAI, GPT 5.6 Sol, registra la mejor puntuación de la compañía (0.615), todavía 0.157 por debajo de Sonnet 5, y sus variantes pro de mayor cómputo quedan mayoritariamente por debajo de sus propias bases (Sol Pro 0.543, Terra Pro 0.568; solo Luna Pro mejora, 0.603 vs 0.579).
- Los especialistas en código no ganaron el benchmark de codificación. GPT 5.3 Codex, la variante afinada para código de OpenAI, obtiene 0.572, en la mitad de la tabla y por debajo del modelo general de OpenAI, GPT 5.4 Mini (0.594). Kimi K2.7 Code de Moonshot es el especialista más fuerte con 0.611.
- Kimi K3, un modelo general, toma la delantera en pesos abiertos frente al especialista en código de Moonshot: 0.725, sexto global, 0.114 por encima de K2.7 Code. Su 0.632 en backend ocupa el quinto puesto, por encima de todos los alias de Opus y GPT.
- Inkling, el primer modelo de Thinking Machines, debuta con 0.575, tercero entre las entradas de pesos abiertos. Su 0.747 en frontend supera a todos los alias de GPT 5.6; el 0.501 en backend limita su clasificación.
- Ningún modelo es fiable en backend: el techo es 0.701 (Sonnet 5), por lo que incluso el ganador falla alrededor de un tercio de las comprobaciones de lógica de negocio y contratos. Grok 4.5 es el más cercano entre las incorporaciones de julio con 0.663. El frontend está casi resuelto entre los líderes (0.79 a 0.96), así que el backend es el problema abierto y determina la clasificación. Claude Haiku 4.5 renderiza bien (0.731), pero un backend de 0.277 lo mantiene en 0.413.
- El punto débil de GPT es el frontend. GPT 5.4 y 5.5 igualan a Opus 4.8 en backend (alrededor de 0.6) pero obtienen entre 0.53 y 0.55 en frontend; la familia GPT 5.6 eleva esa cifra a 0.63–0.71, aún muy por debajo de la línea de Sonnet de más de 0.91.
Comparación de coste y éxito
- Los modelos con precio de insignia son el peor valor. Opus 4.7 es el más caro ($3.08/celda) y puntúa 0.610, por debajo de Sonnet 4.6 a $1.33.
- La cima cobra una prima elevada por poca ganancia: Sonnet 5 puntúa 0.024 por encima de Sonnet 4.6 con un 70% más de coste por celda.
- Grok 4.5 es la nueva mejor relación calidad-precio: 0.732, a 0.040 del ganador, a $0.46 por celda, frente a los $2.23 de Sonnet 5. Dentro de la familia GPT 5.6, el precio no compra nada: de $0.18 (Luna) a $2.76 (Sol Pro) por celda para puntuaciones entre 0.543 y 0.615, con el alias más barato superando al más caro.
- Kimi K3 consigue su sexto puesto a un precio de gama media: $1.47 por celda, cerca de los $1.33 de Sonnet 4.6 pero 0.007 más alto en puntuación, y muy por debajo de los $2.23 de Sonnet 5. Inkling cuesta $1.64 por celda a precio de lista para 0.575, por encima de Sonnet 4.6 por una puntuación inferior.
Comparación de tiempo de finalización y éxito de la tarea
- La mejor puntuación está entre las más lentas. Sonnet 5 tarda alrededor de 30 minutos por tarea, 3x que Sonnet 4.6 por 0.024 más; Sonnet 4.6 ofrece casi la misma puntuación en un tercio del tiempo.
- Una ejecución larga suele indicar un modelo atascado, no uno exhaustivo: los peor clasificados, ambas variantes de Qwen, GLM 5.1 base y Deepseek V4 Pro, cada uno superó los 1,700 segundos por sobreiteración para puntuaciones inferiores a 0.45.
- Grok 4.3 fue rápido porque abandonaba pronto: 142 segundos y 18 llamadas a herramientas para 0.431. Grok 4.5 mantiene la velocidad y deja de abandonar: unos 9 minutos por tarea, menos de un tercio del tiempo de Sonnet 5, para 0.732.
- Kimi K3 se sitúa en la esquina opuesta: puntuación de primer nivel, peor velocidad. Promedia unos 55 minutos por tarea, el más lento del campo y aproximadamente el doble que Sonnet 5, para un sexto puesto de 0.725. Su precisión es real, pero es la forma menos práctica de entrar en el nivel superior.
Llamadas a herramientas por tarea
- El recuento de llamadas a herramientas no mide ni la capacidad ni el esfuerzo comparables. Sonnet 5 realizó el mayor número de llamadas (125) y obtuvo la puntuación más alta; MiniMax M3 hizo 108 para una puntuación de mitad de tabla de 0.583; Grok 4.5 alcanzó 0.732 con 40; las cifras bajas de OpenAI (16 a 36) se deben a que apply_patch agrupa todo un archivo en una sola llamada. Sol Pro y Terra Pro llaman entre un cuarto y un tercio menos de herramientas que sus bases y puntúan menos: más razonamiento, menos ejecución. No clasifiques a los agentes por volumen de herramientas.
- Dos caminos alcanzan la misma puntuación: Sonnet 5 itera intensamente (125 llamadas), Sonnet 4.6 apenas (alrededor de 50), a 0.024 de distancia.
Rendimiento del LLM en una sola tarea exitosa
Ningún modelo superó todos los pasos del benchmark completo anterior. Para comparar coste y velocidad en igualdad de condiciones, ejecutamos una tarea básica que cualquier modelo puede completar: cuatro endpoints CRUD, validación básica, sin autenticación y sin base de datos.
Comparación de coste y líneas de código
- Las tareas simples no pueden clasificar modelos, por lo que las evaluaciones de juguete engañan. En la base que todos los modelos superan, el código converge a 40–64 líneas, y el coste baja a céntimos; las diferencias solo aparecen en trabajos largos con múltiples archivos.
- El nivel “rápido y ligero” fue el más caro aquí: Gemini 3.5 Flash base escribió 131 líneas para la tarea trivial, de dos a tres veces que el resto, lo que lo convirtió en el más caro de la prueba básica, en contra de su posicionamiento.
- La iteración pesada de Sonnet 5 está ligada a la tarea, no es un hábito: 9 llamadas y $0.09 aquí frente a 125 llamadas en el benchmark.
Consulta más detalles en el artículo Precios de LLM.
Tiempo de finalización y uso de tokens
- La previsibilidad de costes divide a los modelos en dos. Los modelos adaptativos gastan solo cuando es necesario (Opus 4.8: 34s en la base, 1,072s en el benchmark); los modelos de ritmo fijo funcionan lento y costoso incluso en trabajos triviales (MiniMax M3: 475 frente a 1,684s).
- La longitud de salida es un rasgo fijo del modelo, con un rango de casi 10x para la misma tarea (787 a 7,508 tokens), lo que repercute directamente en el coste.
¿Qué son los sistemas de LLM agentes?
Construir software es iterativo: escribir código, ejecutarlo, leer errores, corregirlos, repetir. Los sistemas de IA agente permiten que los LLMs sigan este mismo ciclo. El modelo opera dentro de un entorno de desarrollo donde puede escribir archivos, ejecutar comandos, leer salidas y realizar cambios basándose en lo que ve, continuando hasta que la tarea está completa.
Esto importa porque las aplicaciones reales no son archivos únicos. Tienen backends con rutas y modelos de base de datos, frontends con componentes y llamadas a API, archivos de configuración, dependencias y pruebas. Hacer que todo esto funcione junto requiere pruebas y refinamiento iterativos, que es exactamente lo que permite la arquitectura agente.
Cómo funciona
El modelo se sitúa dentro de un arnés con acceso a un shell, sistema de archivos y salida de ejecución. Cuando se le pide construir una aplicación, escribe archivos de forma incremental. Después de cada paso, el arnés muestra al modelo lo que ha ocurrido: ¿arrancó el servidor, pasaron las pruebas, señaló errores el linter? Basándose en esa retroalimentación, el modelo decide qué escribir o corregir a continuación.
Esto difiere fundamentalmente de la generación de un solo disparo. En configuraciones de un solo paso, el modelo genera una base de código completa a ciegas, sin forma de verificar si funciona. En los sistemas de LLM agentes, el modelo ve las consecuencias de cada acción y corrige el rumbo. Sin embargo, esta capacidad por sí sola no es suficiente. El modelo aún necesita un razonamiento sólido para implementar correctamente la lógica de negocio, y ahí es donde realmente surgen las diferencias de rendimiento.
Añadir como fuente preferidaMetodología del benchmark de LLM agente
Utilizamos Opencode como arnés agente para todos los modelos y los conectamos a través de OpenRouter, con dos excepciones: Claude Fable 5 se ejecutó en la CLI de Claude Code con la suscripción de Claude, e Inkling se ejecutó a través de la API compatible con OpenAI de Thinking Machines porque el modelo no está disponible en OpenRouter. Cada celda se ejecutó 3 veces para medir la varianza por celda y estabilizar la tabla de clasificación. Evaluamos su capacidad para trabajar de forma autónoma en 10 tareas de desarrollo de software (T-1 a T-10), que van desde sistemas de reservas hasta paneles interactivos. Estas tareas exigen que los agentes gestionen proyectos de múltiples archivos y entreguen productos funcionales. Los siete alias añadidos en julio de 2026 (Grok 4.5 y la familia GPT 5.6: Sol, Terra, Luna, cada uno en modo base y pro) se ejecutaron en Opencode 1.15.13 con la configuración predeterminada de la API, igual que todos los modelos aquí; las cifras del lanzamiento de OpenAI para Sol utilizan modos de mayor cómputo.1 Cuatro celdas de Sol Pro y una de Terra Pro terminaron en fallos repetidos de flujo silencioso de la API en lugar de errores del modelo y se puntúan como fallos.
Kimi K3 e Inkling se añadieron el 18 de julio con la configuración predeterminada de la API; Inkling se ejecutó con su esfuerzo de pensamiento predeterminado de 0.9. La columna de coste de Inkling utiliza los precios de lista de Thinking Machines de $3.74 por millón de tokens de entrada y $9.36 por millón de tokens de salida; el proveedor facturó aproximadamente la mitad bajo un descuento de lanzamiento por tiempo limitado.2 Ambos modelos se ejecutaron con un límite de 150 minutos por celda en lugar de los 45 minutos anteriores, porque el flujo de tokens de Kimi K3 es lo suficientemente lento como para alcanzar el límite más corto a mitad de la construcción; el tiempo de finalización se informa por separado en el gráfico de tiempo. La capacidad compartida ascendente de Kimi K3 devolvió frecuentes errores de límite de velocidad y tiempo de espera durante la ventana de ejecución; las celdas afectadas se reejecutaron una vez contra el mismo límite, la misma política aplicada a los fallos de flujo de Sol Pro y Terra Pro mencionados anteriormente.
Ejecución y orquestación
Cada agente y tarea comienza en un entorno limpio. Las instrucciones se proporcionan como un archivo TASK.md, y utilizamos un watchdog de latido de 20 minutos para los scripts de lanzamiento. Durante esta fase, registramos los códigos de salida, el tiempo de ejecución y si se crearon los archivos del backend y del frontend. También rastreamos el uso de tokens en tiempo real en las categorías de entrada, salida y caché.
Validación del backend: Desplegamos los proyectos generados en entornos aislados para probarlos contra un contrato YAML canónico. La validación cubre escenarios de camino feliz, manejo de errores (400/403/409) y consistencia de datos.
Probamos los resultados en dos modos:
El modo adaptativo valida la funcionalidad incluso con nombres de ruta diferentes, mientras que el modo estricto requiere una adherencia exacta al contrato.
La puntuación general del backend se calcula por celda como:
backend_overall = has_backend × (0.7 × adaptive_pass_rate + 0.3 × strict_pass_rate)
donde has_backend es 1 si la celda produjo un proyecto de backend, 0 en caso contrario. El adaptativo se pondera más alto porque mide la corrección del comportamiento; el estricto añade una penalización por desviación del contrato (rutas renombradas, códigos de estado sustituidos, campos de respuesta reestructurados).
Pruebas de UI y escenarios de usuario
Utilizamos automatización del navegador para simular flujos de usuario reales, incluidos preflights, renderizado y autenticación. Verificamos pasos funcionales como el envío del login y el comportamiento posterior al login para asegurar que la aplicación se ejecuta sin fallos.
La puntuación de UI divide ocho pasos en dos grupos. Los pasos de infraestructura (preflight del backend, renderizado del frontend, formulario de login visible, envío del login, login 2xx, sin caída en tiempo de ejecución) miden si la aplicación siquiera funciona. Los pasos de comportamiento (señal de autenticación post-login, señal de comportamiento post-login) evalúan si la aplicación realiza la función prevista una vez en funcionamiento.
ui_score = (behavior_passed / (behavior_passed + behavior_failed)) × (infra_passed / infra_total)
Los pasos de comportamiento bloqueados se excluyen del denominador de comportamiento, para que una celda no reciba doble penalización cuando la aplicación no se carga.
Cálculo de tokens
Los recuentos de tokens se extraen de la respuesta de la LLM API. Restamos los tokens de entrada en caché de los tokens de entrada totales para obtener la entrada efectiva, que refleja solo los tokens recién procesados. Los tokens de salida nunca se almacenan en caché, por lo que permanecen sin cambios.
Agregación final
La puntuación final del benchmark se calcula combinando los resultados de las fases anteriores: Final Score = (0.7 × backend_overall) + (0.3 × ui_score) Asignamos un mayor peso al backend porque los fallos lógicos a nivel de la API suelen invalidar cualquier éxito en el frontend.
Ejemplo de tarea
Tarea 6: Sistema de tickets de helpdesk
La tarea 6 se centra en desarrollar un ecosistema complejo de soporte al cliente. El objetivo principal es construir una plataforma que medie la comunicación entre clientes y agentes de soporte, aplicando estrictamente reglas de negocio y límites de seguridad. Esta tarea evalúa la capacidad de un agente para manejar máquinas de estado multiusuario, aislamiento de datos y comunicación en hilos dentro de un entorno full-stack.
La tarea requería construir un sistema de helpdesk con las siguientes características:
- Permisos diferenciados para clientes (emitir/responder) y agentes (gestión/resolución).
- Un flujo de trabajo de estado rígido que impide transiciones ilegales y hace cumplir acciones específicas por rol.
- Aislamiento de datos avanzado donde las solicitudes de recursos no autorizados devuelven 404 en lugar de 403 para proteger la integridad del sistema.
- Un sistema cronológico de respuestas para una interacción fluida entre agente y cliente.
- Un backend FastAPI combinado con un frontend responsivo basado en Vite (React/Vue/Svelte).
- Configuración reproducible mediante comandos de shell específicos para la activación inmediata del sistema.
Puedes consultar la documentación de la Tarea 6 en GitHub.
Cita este benchmark
Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.
@misc{kalelioglu2026,
author = {Kalelioğlu, Berk and Dilmegani, Cem},
title = {{A-CODE-LLM Bench: Benchmark de codificación agente}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/agentic-llm}},
note = {AIMultiple. Recuperado el 23 de Julio de 2026}
}Resultados y marcas de tiempo de 429 puntos de datos. Descargue los datos utilizados en este artículo como un archivo ZIP que contiene 2 archivos CSV y un README.
Enlaces de referencia
Sé el primero en comentar
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.