A-CODE-CLI Bench: Benchmark de CLI agentivas
Las herramientas CLI agentivas son herramientas de codificación con IA que pueden crear y eliminar archivos, ejecutar comandos, planificar y ejecutar la codificación de todo el proyecto. Evaluamos las herramientas líderes en 10 escenarios reales de desarrollo web, realizando ~600 comprobaciones de validación atómica por agente y más de ~5,000 ejecuciones de prueba automatizadas en total, incluyendo lógica de backend, funcionalidad de frontend y verificación de consistencia en múltiples ejecuciones.
Resultados del benchmark de CLI agentivas
Perspectivas de rendimiento de las herramientas CLI agentivas
La corrección del backend determina el ranking; la puntuación combinada pondera el backend con 0.7 y el frontend con 0.3.
- Los nueve agentes que funcionan correctamente usan el mismo Sonnet 4.6, sin embargo el backend oscila entre el 77.3% de Opencode y el 55.4% de Goose. Esa diferencia de 22 puntos se debe enteramente a la orquestación.
- Un buen backend no garantiza un buen resultado final: Cline (4th en backend, 69.5%) y Forge (5th, 67.2%) ocupan los primeros puestos en backend pero van muy mal en frontend; el 52.5% de Cline es el más bajo del grupo, por lo que ambos bajan en la clasificación combinada.
- Codex ocupa el 10th puesto en backend (52.1%) a pesar de tener un frontend perfecto del 100%. En esta prueba se ejecuta a través de un proxy para alcanzar el modelo común, lo que puede perjudicar sus capacidades, por lo que probablemente este sea un límite inferior en lugar del rendimiento real de backend del agente.1 Gemini, también ejecutado a través de un proxy, está limitado de la misma manera.
- La posición en construcción no predice el comportamiento: el agente que lidera aquí no retiene nada después de la compactación, mientras que un agente de mitad de tabla lo retiene todo.
Velocidad, uso de tokens y coste frente a puntuación
Evaluamos la eficiencia en tiempo de ejecución usando el tiempo medio de ejecución (segundos), el uso efectivo de tokens (entrada + salida) y el coste por tarea (USD), cada uno representado gráficamente frente a la puntuación combinada de precisión:
La rapidez, el bajo coste o el bajo uso de tokens de un agente no predicen su puntuación.
- Opencode gana en los tres a la vez: la mejor puntuación combinada (81.6%), el coste más bajo de cualquier agente capaz ($1.03 por tarea), entre los que menos tokens usan y las ejecuciones más rápidas. Invierte el típico equilibrio entre precisión y coste.
- El coste abarca aproximadamente 40 veces, desde los $0.18 de Forge hasta los $7.58 de Junie, sin relación con la posición. Forge es el más barato porque hace lo mínimo: su backend falla en la creación de tickets. Los $7.58 de Junie compran un 74.7% de mitad de tabla y representan un límite superior inflado.
- Goose paga lo máximo por lo mínimo: el segundo más caro con $3.23, pero la puntuación limpia más baja del grupo (62.5%). Los tres primeros en puntuación se mantienen baratos (Opencode $1.03, Claude Code $1.83, Grok $2.03).
- Ni el más rápido ni el más lento gana: Kiro (439s) y Gemini (1,158s, sobrecarga del proxy) terminan en la mitad de la tabla. El gasto extra compra reintentos y revalidación, no profundidad en la resolución de problemas.
- Las cifras de tokens se deben en gran medida al almacenamiento en caché. Codex, Claude Code, Cline, Opencode, Gemini y Grok almacenan en caché entre el 86 y el 98% de su entrada, por lo que los 4.18M de tokens brutos de Claude Code se reducen a 115k efectivos. Junie, Goose, Kiro, Forge y Aider no almacenan en caché, por lo que pagan por cada token que reenvían; esa es la razón de que los 2.36M de Junie sean los más altos del grupo.
- Tres advertencias sobre las cifras: para los cinco agentes que no usan caché, la entrada efectiva es todo lo que enviaron, por lo que debe considerarse un límite superior; los $1.72 de Kiro son un piso (facturado por crédito, más cercano a $2.23); el 64.4% de Cline incluye cuatro tareas en las que alcanzó su límite de error antes de entregar un frontend, cada una puntuó 0.
Puedes consultar nuestra metodología más abajo.
Cómo funcionan las herramientas CLI agentivas
Las herramientas CLI agentivas son agentes autónomos que operan dentro del terminal. Aunque la mayoría de los usuarios las utilizan para tareas de codificación, pueden ejecutar cualquier flujo de trabajo que se pueda realizar mediante comandos de shell.
Estos agentes normalmente operan en un bucle que consta de tres fases:
- Recopilar contexto
- Ejecutar acción
- Verificar resultados
Después de la verificación, el agente recopila el contexto actualizado y repite el bucle hasta que completa la tarea o alcanza una condición de parada.
El bucle está influenciado por dos fuentes:
- El usuario humano, que proporciona la tarea inicial y puede interrumpir la ejecución
- El modelo, que realiza la planificación, el razonamiento y la selección de acciones
El framework de agentes proporciona estructura alrededor del modelo. Define cómo debe planificar el modelo, cuándo debe ejecutar comandos, cómo debe validar los resultados y qué herramientas están disponibles. Estas herramientas pueden incluir ejecución de shell, acceso al sistema de archivos, control del navegador, uso del ordenador, integraciones con MCP o 'habilidades' reutilizables.
Las diferentes arquitecturas de los agentes imponen diferentes estrategias de planificación, políticas de reintento y lógica de verificación. Algunos agentes priorizan la precisión y un razonamiento más profundo a costa de un mayor uso de tokens y latencia. Otros priorizan la velocidad y un menor coste con una menor robustez de comportamiento.
Inteligencia del modelo frente a arquitectura del agente
Las diferencias de rendimiento entre las herramientas CLI agentivas no provienen de una única fuente. Surgen de dos capas: el modelo base y el marco de orquestación que lo envuelve.
Este benchmark prueba a ambos agentes con el mismo modelo base: Claude Sonnet 4.6. Por tanto, cualquier diferencia en la puntuación es una diferencia en la orquestación: cómo la CLI recopila contexto, cuándo ejecuta comandos, cómo valida la salida y si reintenta después de un fallo.
Opencode y Claude Code usan Sonnet 4.6 directamente. Opencode obtiene un 77.3% en backend; Claude Code obtiene un 74.9%. Dos agentes, mismo modelo, una diferencia de 2.4 puntos porcentuales en corrección del backend. Kiro y Opencode también usan Sonnet 4.6. Kiro obtiene un 64.2% en backend; Opencode obtiene un 77.3%. La diferencia de 13 puntos es la contribución de la CLI.
Los dos benchmarks observacionales que aparecen a continuación llevan esto más lejos. Ejecutan la misma prueba con el modelo común en investigación web y compactación de contexto, donde las diferencias no son de 13 puntos sino la diferencia entre encontrar la respuesta correcta e inventar una incorrecta.
Fundamentación en investigación web
Pedimos a cada agente que auditara la documentación de frameworks: qué versión introdujo una funcionalidad, cuál es su estado actual y qué cambió recientemente. Cada respuesta debía citar una fuente oficial. Realizamos la prueba dos veces, una sobre Unity y otra sobre Next.js/React. Los datos se seleccionaron para que la respuesta correcta solo exista en una página actual y publicada. Responder a partir de los datos de entrenamiento produce una respuesta confiada pero errónea. Comprobamos una cosa: ¿realmente el agente accedió a la página que citó?
Cuatro agentes tienen búsqueda web integrada. Tres de ellos (Codex, Gemini, Grok) se ejecutaron con sus modelos nativos no Sonnet; los otros ocho, incluido Claude Code, se ejecutaron con Sonnet 4.6.
Surgieron cuatro patrones.
- Búsqueda real en vivo Codex, Claude Code, Gemini y Grok acceden a páginas actuales y captan cambios recientes. Codex fue el único agente que llegó al foro de desarrolladores, donde residen los datos más difíciles.
- Busca, pero aterriza en páginas antiguas Cline accedió a dos docenas de páginas de documentación reales y aun así informó de una versión que ya había sido reemplazada. Las peticiones fueron reales; las páginas estaban obsoletas.
- Sin búsqueda, responde a partir de los datos de entrenamiento Aider no navega y lo dice. Esta es la respuesta honesta.
- Fuentes inventadas Forge no accedió a ninguna página que funcionara, sin embargo citó 31 fuentes en la prueba de Next.js. Las páginas citadas no existen. Su declaración final: “cada celda procede de una página realmente accedida durante esta sesión.”
En la prueba de Next.js, todos los demás agentes de navegación fundamentaron casi todas sus citas en páginas que realmente habían accedido. Forge no fundamentó ninguna. El gráfico apila las citas fundamentadas de cada agente frente a las inventadas, de modo que los agentes honestos aparecen como barras verdes completas y Forge como una única barra roja. El gráfico cubre los ocho agentes con un registro de fetch por URL verificable. Grok (búsqueda en el lado del servidor), Gemini (ejecución truncada) y Aider (sin citas) aparecen en la tabla anterior pero se excluyen aquí.
Cline y Claude Code se ejecutaron con Sonnet 4.6 en esta prueba. Claude Code encontró y abrió la página con la respuesta correcta. Cline no. Mismo modelo, resultado diferente.
Calificamos cada respuesta por su precisión factual, pero esas puntuaciones dependen de una clave de respuestas actualmente en revisión. No publicamos las tablas de precisión hasta que la clave esté finalizada.
Compactación de contexto
Cuando una sesión se alarga, el agente compacta su contexto: reemplaza el historial detallado por un resumen corto y descarta los originales. Comprobamos si el resumen retiene lo que importa.
Entregamos a cada agente aproximadamente 112,000 tokens de documentos con 13 hechos inventados incrustados: un PIN de guardia, una región de la nube, una etiqueta de compilación y diez más. Inventado significa que los valores son cadenas únicas sin presencia en los datos de entrenamiento. El agente leyó los documentos y compactó. Luego eliminamos los archivos de origen y preguntamos por los 13 hechos. Con los archivos eliminados, la única fuente posible es el resumen de compactación.
Cuatro agentes retuvieron todos los hechos. Tres no retuvieron ninguno. Los tres que puntuaron 0 de memoria solo habían respondido 13 de 13 mientras aún podían releer los archivos. Estaban releyendo en cada consulta. Cuando los archivos desaparecieron, pusieron “desconocido” en lugar de adivinar.
Goose, Forge, Opencode y Kiro ejecutan Sonnet 4.6. Kiro retuvo los 13. Los otros tres no retuvieron ninguno. Mismo modelo, resultado opuesto.
Opencode ocupa el primer puesto en el benchmark de construcción y no retiene nada en la compactación. Kiro ocupa el séptimo puesto en el de construcción y lo retiene todo en la compactación. Un buen rendimiento en construcción y una buena compactación son propiedades independientes.
Cuatro agentes quedaron fuera del alcance de esta prueba, cada uno por una razón concreta. Cline no pudo alcanzar su umbral de compactación. Creamos un conjunto de documentos de 863,000 tokens y le hicimos leer cada archivo, pero Cline trunca cada salida de herramienta a aproximadamente 2,000 caracteres, por lo que los documentos se redujeron a breves vistas previas. Su contexto se estabilizó en 214,000 tokens, el 21% de su ventana de un millón de tokens, y la compactación nunca se activó. Informamos de Cline como no medible bajo este protocolo en lugar de estimar una cifra. Grok tiene un comando de compactación, pero leyó nuestros documentos en fragmentos en lugar de cargarlos completos, por lo que nunca hubo un contexto completo que compactar. El resumidor de Aider comprime los turnos del chat, no el contenido de los archivos añadidos a la sesión, que es donde residían los hechos. Junie no tiene función de compactación.
Añadir como fuente preferidaComportamiento de los agentes en la tarea 6
Evaluamos a los agentes en 10 tareas. A continuación se presenta un desglose detallado de la Tarea 6 para mostrar cómo se comportan las diferentes arquitecturas CLI bajo las mismas restricciones cuando todas se ejecutan en el mismo modelo.
Tarea 6: Sistema de tickets de helpdesk (Web)
La tarea 6 requería construir un sistema completo de tickets de helpdesk con:
- Dos roles de usuario (cliente y agente)
- Autenticación basada en JWT
- Transiciones estrictas de estado del flujo de trabajo
- Aislamiento de datos (404 en lugar de 403 para acceso entre usuarios)
- Backend FastAPI
- Frontend React/Vue/Svelte + Vite
- Comandos de ejecución deterministas
La prueba de humo validaba:
- Verificación de salud
- Autenticación de doble rol
- Operaciones CRUD de tickets
- Asignación y respuestas
- Transiciones de estado
- Cumplimiento de roles
- Aislamiento de datos
- Inicio de sesión en la interfaz y comportamiento después del inicio de sesión
Esta tarea pone a prueba la gestión del estado, la corrección de la autenticación, la disciplina en el contrato REST y la integración frontend-backend. Visita GitHub para ver los detalles de la tarea.
Con un solo modelo, el grupo se dividió en tres.
- Backend al 60%, siete agentes (codex, claude-code, cline, grok, goose, junie, opencode): idénticos seis pasos fallidos en las tres repeticiones. Autenticación, CRUD de tickets, respuestas y aislamiento de datos aprobados; ambos fallos ocurrieron en
/tickets/{id}/assigny/tickets/{id}/status, donde construyeron unPATCH /tickets/{id}unificado en lugar de las rutas separadas de la especificación. Lógica de negocio correcta, contrato REST incorrecto. En la ejecución nativa anterior con Gemini 3 Pro, Opencode construyó los endpoints separados y obtuvo un 93.3%; en Sonnet 4.6 optó por el diseño unificado como el resto. - 13.3%, tres agentes (aider, forge, gemini-cli): la autenticación funcionó, pero la creación de tickets en sí falló, por lo que todos los pasos dependientes cayeron en cascada.
- 24.4%, Kiro: inestabilidad, no un modo de fallo único. Superó nueve pasos en la primera ejecución, dos en la segunda, y en la tercera el backend nunca se inició (falló la verificación de salud). Los otros diez agentes se repitieron idénticamente en cada repetición.
- Interfaz dentro del grupo del 60%: claude-code y cline fallaron el inicio de sesión por un idéntico error de CORS, el frontend llamaba al backend en
localhost:8000desde un origen127.0.0.1y el navegador lo bloqueó, por lo que ambos obtuvieron un 75%; los otros cinco renderizaron e iniciaron sesión limpiamente al 100%. - La conclusión es la convergencia: siete CLIs diferentes en el mismo modelo cometieron el mismo error en el contrato REST, por lo que aquí el modelo domina y la orquestación apenas importa, al contrario que en los benchmarks observacionales que se muestran a continuación.
Codex
Instalación
Instalar globalmente con:
- npm install -g @openai/codex
Alternativamente, instalar globalmente con Homebrew (macOS/Linux)
- brew install –cask codex
Autenticación
Después de configurar Codex, puedes continuar con tu cuenta de ChatGPT, o con tu clave OpenAI API. No hay opciones de proveedor disponibles.
Informe de la tarea
Codex construyó un sistema funcional en 454 segundos y se situó en el grupo del 60%. La lógica de negocio era correcta; falló en el contrato REST en la asignación y el estado, como el resto del grupo.
Comportamiento del backend
Autenticación, CRUD de tickets, respuestas y aislamiento de datos aprobados. Los seis fallos fueron los pasos de asignación y transición de estado, que apuntaban a `/tickets/{id}/assign` y `/tickets/{id}/status`. Codex enrutó ambos a través de un endpoint de actualización unificado, por lo que esas llamadas devolvieron 404. Estable en las tres repeticiones.
Comportamiento de la interfaz
El frontend pasó los ocho pasos de validación. El inicio de sesión y el comportamiento posterior al inicio de sesión fueron correctos. 100% en interfaz.
Junie
Instalación
Junie está disponible a través de JetBrains Toolbox o como una CLI independiente:
- curl -fsSL https://junie.jetbrains.com/install | bash
Autenticación
Continúa con tu cuenta de JetBrains o genera una JUNIE_API_KEY en junie.jetbrains.com/cli, o exporta tu propia clave API de Anthropic, OpenAI, Google u otros proveedores compatibles. Varias opciones de proveedor disponibles.
Informe de la tarea
Junie produjo un sistema completo full-stack en 444 segundos y obtuvo un 60% en backend, en el grupo principal. Su entrada efectiva en esta tarea es la más alta del grupo con 1.52M, un límite superior no almacenado en caché afectado por un conocido error de contabilidad de caché (ver la nota de la tabla de resultados).
Comportamiento del backend
Nueve de dieciséis pasos aprobados: autenticación, CRUD de tickets, respuestas y aislamiento de datos. Los seis fallos fueron los pasos de asignación y transición de estado. Junie gestionó el estado y la asignación a través de un endpoint de actualización unificado, por lo que las rutas `/tickets/{id}/assign` y `/tickets/{id}/status` de la especificación devolvieron 404. La lógica de transición en sí era correcta. Estable en las tres repeticiones.
Comportamiento de la interfaz
El frontend pasó los ocho pasos de validación. 100% en interfaz.
Kiro CLI
Instalación
Para macOS/Linux/WSL:
- curl -fsSL https://cli.kiro.dev/install | bash
AppImage de Linux alternativa (opción portátil):
- Descargar: https://desktop-release.q.us-east-1.amazonaws.com/latest/kiro-cli.appimage
Luego ejecutar:
- chmod +x kiro-cli.appimage && ./kiro-cli.appimage
Autenticación
Puedes continuar con tu plan de Kiro-Code. No hay opciones de proveedor disponibles.
Informe de la tarea
Kiro es el único agente cuya puntuación refleja inestabilidad más que una sola decisión de diseño. Su 24.4% en backend es una media de tres repeticiones que produjeron tres resultados diferentes. La compilación en sí era sólida cuando funcionaba; el problema fue que no funcionó de la misma manera dos veces.
Comportamiento del backend
En la primera ejecución, Kiro pasó nueve de dieciséis pasos, el mismo perfil que el grupo del 60%, fallando solo las rutas de asignación y estado. En la segunda ejecución pasó dos. En la tercera, el backend nunca se inició e incluso falló la verificación de salud. Promediado, esto es 24.4%. La inestabilidad, no el diseño del endpoint, es lo que separa a Kiro del grupo aquí.
Comportamiento de la interfaz
Cuando el backend estaba activo, el frontend pasó los ocho pasos de validación. 100% en interfaz. Esto es un cambio con respecto a la ejecución anterior, donde el formulario de inicio de sesión falló al renderizarse debido a un 422 al montar.
Claude Code
Instalación
Para macOS/Linux/WSL, considerando tu gestor de paquetes preferido, puedes instalar Claude Code con:
- curl -fsSL https://claude.ai/install.sh | bash
- npm install -g @anthropic-ai/claude-code
Autenticación
Después de configurar Claude Code, puedes continuar con tu cuenta de Claude. No hay opciones de proveedor disponibles.
Informe de la tarea
Claude Code obtuvo un 60% en backend en 379 segundos, en el grupo principal. Esta es una mejora notable con respecto a la ejecución anterior, donde un error de validación JWT devolvía 401 en cada ruta autenticada y fallaba 13 de 16 pasos. En esta ejecución el backend funcionó; la pérdida estuvo en la interfaz.
Comportamiento del backend
Autenticación, CRUD de tickets, respuestas y aislamiento de datos aprobados. Los seis fallos fueron los pasos de asignación y transición de estado, enrutados a través de un endpoint de actualización unificado en lugar de las rutas separadas de la especificación. Estable en las tres repeticiones.
Comportamiento de la interfaz
El paso de inicio de sesión falló. El frontend llamaba al backend en localhost:8000 mientras la página se servía desde un origen 127.0.0.1, y el navegador bloqueó la solicitud de inicio de sesión bajo la política CORS. Cinco pasos aprobados, uno falló, dos bloqueados. 75% en interfaz. Cline falló de la misma manera.
Aider
Instalación
Si ya tienes python 3.8-3.13 instalado, primero instala aider:
- python -m pip install aider-install
- aider-install
Autenticación
Inicia sesión en tu cuenta de OpenRouter y autoriza, o exporta tu clave API en tu entorno con:
- export OPENROUTER_API_KEY=”sk-or-v1-…”
Informe de la tarea
Aider fue el agente más rápido con 236 segundos y el más ligero, con 1.3k de entrada y 18k de salida de tokens. También obtuvo un 13.3% en backend. La autenticación funcionó, pero la creación de tickets falló, y cada paso que necesitaba un ticket existente falló con ello.
Comportamiento del backend
Dos pasos aprobados. La compilación se rompió en la creación de tickets, por lo que las listas de tickets de cliente y agente, las respuestas, la asignación, las transiciones de estado y las comprobaciones de roles cayeron en cascada. Estable en las tres repeticiones. Esta es una clase de fallo diferente del grupo del 60%, que creaba tickets correctamente y solo fallaba en las rutas de asignación y estado.
Comportamiento de la interfaz
El paso de inicio de sesión falló bajo el mismo desajuste de origen CORS observado en claude-code y cline. Cinco pasos aprobados, uno falló, dos bloqueados. 75% en interfaz.
OpenCode
Instalación
Para macOS/Linux/WSL:
- curl -fsSL https://opencode.ai/install | bash
Instalar globalmente con:
- npm i -g opencode-ai
Para macOS/Linux, considerando tu gestor de paquetes preferido:
- bun add -g opencode-ai
- brew install anomalyco/tap/opencode
- paru -S opencode
Autenticación
Hay muchas opciones de proveedor, selecciona tu proveedor deseado y autentica con /connect
Informe de la tarea
Opencode lidera el benchmark general, pero en la Tarea 6 obtuvo un 60% en backend, en el grupo principal, en 542 segundos. Esta es la evidencia de modelo más clara de este artículo. En la ejecución nativa anterior con Gemini 3 Pro Preview, Opencode construyó los endpoints separados de la especificación y obtuvo un 93.3% aquí. La misma CLI en Sonnet 4.6 eligió el endpoint unificado y bajó al 60%. La herramienta no cambió; el modelo sí.
Comportamiento del backend
Autenticación, CRUD de tickets, respuestas y aislamiento de datos aprobados. Los seis fallos fueron los pasos de asignación y transición de estado, enrutados a través de un endpoint de actualización unificado. Estable en las tres repeticiones.
Comportamiento de la interfaz
El frontend pasó los ocho pasos de validación. 100% en interfaz.
Grok Build
Instalación
Para macOS/Linux:
- curl -fsSL https://x.ai/cli/install.sh | bash
Autenticación
Inicia sesión con tu cuenta de xAI en el primer lanzamiento, o establece una clave API para uso sin cabeza:
- export XAI_API_KEY=”xai-…”
Informe de la tarea
Grok terminó segundo en el benchmark de construcción con un 75.4% en backend. En la Tarea 6 obtuvo un 60% en backend en 433 segundos, en el grupo principal. En esta ejecución Grok alcanzó Sonnet 4.6 a través de OpenRouter.
Comportamiento del backend
Nueve de dieciséis pasos aprobados: autenticación, CRUD de tickets, respuestas y aislamiento de datos. Los seis fallos fueron los pasos de asignación y transición de estado, que apuntaban a /tickets/{id}/assign y /tickets/{id}/status. Grok enrutó ambos a través de un endpoint de actualización unificado, por lo que esas llamadas y las comprobaciones de roles que dependen de ellas devolvieron 404. Estable en las tres repeticiones.
Comportamiento de la interfaz
El frontend pasó los ocho pasos de validación. El inicio de sesión y el comportamiento posterior al inicio de sesión fueron correctos. 100% en interfaz.
Forge
Instalación
Para macOS/Linux/WSL:
- curl -fsSL https://forgecode.dev/cli | sh
Autenticación
Configura las credenciales de tu proveedor de forma interactiva con:
- forge provider login
Y elige tu proveedor.
Informe de la tarea
Forge obtuvo un 13.3% en backend en 844 segundos. Su recuento de tokens de salida es el más bajo del grupo con 1.6k, lo que apunta a una implementación superficial. Como en la ejecución anterior, la compilación se rompió en la creación de tickets y el fallo se propagó en cascada.
Comportamiento del backend
Dos pasos aprobados. La creación de tickets falló, por lo que las listas de tickets, las respuestas, la asignación, las transiciones de estado y las comprobaciones de roles fallaron con ello. Estable en las tres repeticiones, el mismo perfil de 13.3% que aider y gemini-cli.
Comportamiento de la interfaz
El paso de inicio de sesión falló bajo el mismo desajuste de origen CORS observado en claude-code, cline y aider. Cinco pasos aprobados, uno falló, dos bloqueados. 75% en interfaz.
Gemini CLI
Instalación
Ejecutar al instante:
- npx @google/gemini-cli
O instalar globalmente:
- npm install -g @google/gemini-cli
- brew install gemini-cli
Autenticación
Opción 1 (Google OAuth): export GOOGLE_CLOUD_PROJECT=”YOUR_PROJECT_ID” luego inicia gemini.
Opción 2 (clave API): export GEMINI_API_KEY=”YOUR_API_KEY” luego inicia gemini.
Opción 3 (Vertex IA): export GOOGLE_API_KEY + GOOGLE_GENAI_USE_VERTEXAI=true.
Informe de la tarea
Gemini CLI obtuvo un 13.3% en backend en 926 segundos, uno de los dos agentes más lentos del grupo. La autenticación funcionó, pero la creación de tickets falló y se propagó en cascada. Su frontend, que falló completamente en la ejecución anterior debido a una incompatibilidad de Node 18 con Vite 7, pasó todos los pasos esta vez.
Comportamiento del backend
Dos pasos aprobados. La creación de tickets falló, por lo que todos los pasos dependientes fallaron. Estable en las tres repeticiones, el mismo perfil de 13.3% que aider y forge.
Comportamiento de la interfaz
El frontend pasó los ocho pasos de validación. 100% en interfaz, frente al 0% de la ejecución anterior. Apareció un 401 en la consola en una llamada autenticada, pero no bloqueó el flujo renderizado.
Cline
Instalación
Instalar globalmente con:
- npm install -g cline
Autenticación
Escribiendo `cline auth` puedes seleccionar tu cuenta de Cline o continuar con el proveedor que desees.
Informe de la tarea
Cline obtuvo un 60% en backend en 648 segundos, en el grupo principal. Este es un gran cambio con respecto a la ejecución anterior, donde su límite de ocho errores terminó la compilación antes de tiempo y dejó un frontend vacío. Aquí completó el stack completo.
Comportamiento del backend
Autenticación, CRUD de tickets, respuestas y aislamiento de datos aprobados. Los seis fallos fueron los pasos de asignación y transición de estado, enrutados a través de un endpoint de actualización unificado. Estable en las tres repeticiones.
Comportamiento de la interfaz
El paso de inicio de sesión falló bajo el mismo desajuste de origen CORS observado en claude-code, en una página 127.0.0.1 que llamaba a un backend localhost. Cinco pasos aprobados, uno falló, dos bloqueados. 75% en interfaz.
Goose
Instalación
Para macOS/Linux/WSL:
- curl -fsSL https://github.com/block/goose/releases/download/stable/download_cli.sh | bash
Informe de la tarea
Goose obtuvo un 60% en backend en 553 segundos, en el grupo principal, pero consumió 1.06M tokens de entrada para lograrlo. Completó el stack completo esta vez, un cambio con respecto a la ejecución anterior donde el directorio del frontend quedó vacío.
Comportamiento del backend
Autenticación, CRUD de tickets, respuestas y aislamiento de datos aprobados. Los seis fallos fueron los pasos de asignación y transición de estado, enrutados a través de un endpoint de actualización unificado. Estable en las tres repeticiones.
Comportamiento de la interfaz
El frontend pasó los ocho pasos de validación. 100% en interfaz, frente al 0% de la ejecución anterior.
Herramientas de codificación con IA
Las herramientas de codificación con IA pueden agruparse en tres categorías:
- CLI agentiva: Herramientas para flujos de trabajo de desarrollo basados en terminal, generan, editan y refactorizan código mediante prompts e interacciones de línea de comandos.
- Ejemplos: Aider, Junie, Opencode, Claude Code, Codex
- Editores de código con IA: También conocidos como IDEs agentivos, estas herramientas proporcionan una interfaz gráfica similar a VS Code (la mayoría están construidas sobre VS Code).
- Ejemplos: Antigravity, Cursor, Kiro Code, Windsurf
- Constructores de apps mediante prompts: Plataformas de bajo código/sin código para crear aplicaciones usando prompts en lenguaje natural y flujos de trabajo visuales.
- Ejemplos: Bolt, Lovable, v0.dev, Firebase Studio, Dazl
Herramientas de revisión de código con IA
A medida que el código generado por IA se vuelve más común, las herramientas de revisión de código son esenciales para detectar errores y vulnerabilidades. Evaluamos las mejores herramientas en 309 PRs en nuestro benchmark RevEval.
¿Qué pueden hacer las herramientas CLI agentivas?
En todas las herramientas como Codex, Junie, Kiro y Claude Code, las capacidades comunes incluyen:
- Trabajo de código de extremo a extremo: Crear y modificar archivos, corregir errores, refactorizar código y ejecutar pruebas o linters directamente desde el terminal.
- Flujos de trabajo agentivos: Realizar tareas de varios pasos como encadenamiento de tareas, resolución de problemas, búsqueda y depuración iterativa.
- Git y gestión de proyectos: Revisar el historial, resolver merges, gestionar ramas y crear commits o pull requests.
- Ejecución de comandos y automatización: Ejecutar comandos de shell, automatizar análisis y traducir lenguaje natural a operaciones CLI complejas.
- Manejo profundo del contexto: Operar sobre repositorios completos con conocimiento de las dependencias y la estructura del proyecto.
- Flexibilidad de modelo: Soporte para múltiples modelos en la nube y, en algunos casos, locales; algunas herramientas permiten usar tu propia clave API o elegir entre planes.
- Acceso controlado o en sandbox: Ofrecen modos que van desde solo lectura hasta automatización completa, a menudo con entornos aislados por seguridad.
Metodología
A-CODE-CLI Benchmark
Evaluamos a los agentes en una configuración de ejecución única para medir la capacidad autónoma sin intervención humana. Luego, los agentes se evaluaron mediante pruebas de humo de backend y frontend para medir la preparación de la infraestructura y la corrección del comportamiento.
Configuración del modelo. Todos los 11 agentes se ejecutaron en Claude Sonnet 4.6 (sin razonamiento). Dos agentes necesitaron un proxy para alcanzar este modelo:
- Codex (OpenAI CLI) no puede apuntar a modelos de Anthropic de forma nativa. Se enrutó a través de una pasarela LiteLLM hacia OpenRouter/Anthropic, con un shim de caché que restaura el almacenamiento en caché de prompts. El proxy elimina los tokens de razonamiento (coste de capacidad) y añade latencia.
- Gemini CLI no puede llamar a modelos de Anthropic de forma nativa. Se enrutó a través de un shim SSE y una pasarela LiteLLM. Sus llamadas al modelo auxiliar (detección de bucles, reparación de herramientas malformadas, compresión de contexto) fallan o devuelven contenido no válido a través del proxy, por lo que funcionó sin sus propias redes de seguridad.
Forge requirió un proxy separado para eliminar los bloques de pensamiento extendido de las respuestas, que Forge fuerza y que causan errores 400 cuando se devuelven. Todos los demás agentes utilizaron Sonnet 4.6 directamente a través de su configuración nativa de proveedor o de OpenRouter.
El proxy solo puede perjudicar a Codex y Gemini CLI, nunca inflarlos. Sus puntuaciones son conservadoras.
Junie ejecuta conjuntamente un asistente GPT-4.1-mini no anulable junto con el modelo principal Sonnet 4.6. Es el único agente con un segundo modelo activo durante la construcción. Sus puntuaciones llevan un asterisco de modelo múltiple.
Claude Code se ejecutó mediante suscripción de usuario (OAuth). Kiro se ejecutó con créditos alojados por Kiro (respaldado por Bedrock, multiplicador 1.3x).
No se ajustó la temperatura, los reintentos ni los parámetros de razonamiento de ningún agente. Cada uno se ejecutó con su configuración predeterminada.
Puntuación. Backend: humo funcional (adaptive_avg_step_pass_rate). Frontend: humo de interfaz de usuario mediante Playwright. Combinada: 0.7 × backend + 0.3 × frontend (para agentes con datos de interfaz completos). La puntuación de backend es el eje principal de clasificación. El rendimiento del frontend se satura en todo el grupo.
Aider t-3 y t-4. Ambas tareas produjeron backends que fallaron al iniciarse. Confirmado en dos compilaciones nuevas (mismos errores: TypeError on class Card en t-3, AmbiguousForeignKeysError on User.auctions en t-4). Puntuaron 0 con un indicador backend_never_ready, no se excluyeron.
Para consultar la metodología de evaluación, visita: metodología del benchmark de codificación con IA
Versiones de CLI (ejecución del benchmark de junio de 2026)
Versiones leídas de las cajas VPS del benchmark. La ejecución de construcción se realizó del 5 al 8 de junio de 2026.
- Claude Code: 2.1.165
- Cline: 3.0.27
- Codex: 0.140.0
- Aider: 0.86.2
- Gemini CLI: 0.26.0
- Forge: 2.13.11
- Goose: 1.37.0
- Grok: 0.2.54
- Junie: 26.06.01 (build 1831.35)
- Kiro CLI: 2.6.1
- Opencode: 1.17.7
Metodología de fundamentación en investigación web
Dos pruebas: una auditoría de migración de Unity (prueba 2) y una auditoría de versión de Next.js/React (prueba 3). Cada una pedía al agente que informara de la versión, el estado y la cronología de funcionalidades específicas del framework y citara una URL oficial por afirmación.
La calificación utilizó dos métodos paralelos. Filtrado por verdad fundamental: una afirmación puntúa solo si la URL citada aparece en el registro real de fetch del agente Y la página accedida contiene el hecho, medido contra una clave de respuestas verificada. Clasificación conductual: un juez LLM leyó la transcripción completa de cada agente y lo asignó a una de las cuatro categorías conductuales. La clasificación conductual es el resultado principal; las tablas de precisión puntuadas se publicarán después de que la clave de respuestas complete su revisión de anclaje humano.
Los agentes con búsqueda integrada (Codex, Gemini, Grok) se ejecutaron en sus modelos nativos porque la tarea requiere su capacidad de búsqueda integrada. Los ocho restantes se ejecutaron en Claude Sonnet 4.6. N=1.
Metodología de compactación de contexto
Los agentes recibieron aproximadamente 112,000 tokens de documentos de relleno que contenían 13 hechos inventados sobre infraestructura. Después de que el agente leyera los documentos y compactara su contexto, eliminamos los archivos de origen antes de hacer cualquier pregunta. Puntuación: coincidencia exacta con 13 valores inventados, automatizada mediante un script de calificación con una expresión regular por hecho. N=3.
Los agentes que puntuaron 13/13 con los archivos presentes y 0/13 con los archivos eliminados se clasifican como re-lectores. Los agentes que puntuaron 13/13 con los archivos eliminados se clasifican como retenedores verdaderos. La eliminación de archivos descarta la relectura; los hechos inventados descartan el recuerdo de datos de entrenamiento.
Todos los agentes, excepto Codex (GPT-5.5) y Gemini (Gemini 2.5 Pro), se ejecutaron en Sonnet 4.6. El modelo utilizado por cada agente se indica en la tabla de resultados.
Leer más
Para aquellos que exploran el ecosistema más amplio de herramientas de desarrollo agentivas, aquí están nuestros últimos benchmarks:
- Benchmark de MCP: Una comparación de los mejores servidores MCP para acceso web.
- Navegadores remotos: Cómo la infraestructura emergente de navegadores permite a los agentes de IA interactuar con la web de forma segura.
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{kaleliolu2026,
author = {Kalelioğlu, Berk and Dilmegani, Cem},
title = {{A-CODE-CLI Bench: Benchmark de CLI agentivas}},
year = {2026},
month = jun,
howpublished = {\url{https://aimultiple.com/agentic-cli}},
note = {AIMultiple. Recuperado el 29 de Junio de 2026}
}Resultados y marcas de tiempo de 110 puntos de datos. Descargue los datos utilizados en este artículo como un archivo ZIP que contiene un archivo 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.