Benchmark A-CODE-CLI: Evaluación de CLI Agénticas
Las herramientas CLI agénticas son herramientas de codificación con IA que pueden crear y eliminar archivos, ejecutar comandos, planificar y realizar la codificación de todo el proyecto. Evaluamos las herramientas líderes en 10 escenarios reales de desarrollo web, realizando ~600 verificaciones atómicas por agente y más de ~5,000 ejecuciones de pruebas 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 agénticas
Conclusiones sobre el rendimiento de las herramientas CLI Agénticas
La corrección del backend determina la clasificación; la puntuación combinada lo pondera con 0.7 frente al 0.3 del frontend.
- Los nueve agentes que se ejecutan correctamente utilizan el mismo Sonnet 4.6, sin embargo, la corrección del backend va desde el 77.3% de Opencode hasta el 55.4% de Goose. Esa brecha de 22 puntos se debe enteramente a la orquestación.
- Un backend sólido no garantiza un buen resultado final: Cline (4.º en backend, 69.5%) y Forge (5.º, 67.2%) están cerca de la cima en backend pero se quedan muy atrás en frontend; el 52.5% de Cline es el más bajo del campo, por lo que ambos descienden en la clasificación combinada.
- Codex ocupa el 10.º puesto en backend (52.1%) a pesar de un impecable 100% en frontend. Se ejecuta aquí a través de un proxy para alcanzar el modelo común, lo que puede perjudicar sus capacidades, por lo que es probable que esto sea un piso mínimo más que el verdadero rendimiento de backend del agente.1 Gemini, ejecutado también a través de un proxy, está limitado de la misma manera.
- La posición en la clasificación de 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 la zona media 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 de precisión combinada:
La rapidez, el bajo coste o la ligereza en tokens de un agente no predicen su puntuación.
- Opencode gana en los tres aspectos a la vez: la puntuación combinada más alta (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 la habitual compensación 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 clasificació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 discreto 74.7% y constituyen un límite superior inflado.
- Goose paga el máximo por el mínimo: el segundo más caro, con $3.23, pero la puntuación limpia más baja del campo (62.5%). Los tres primeros en puntuación se mantienen económicos (Opencode $1.03, Claude Code $1.83, Grok $2.03).
- Ni el más rápido ni el más lento ganan: Kiro (439s) y Gemini (1,158s, sobrecarga del proxy) ambos quedan en la zona media. El gasto extra compra reintentos y revalidación, no profundidad en la resolución de problemas.
- Las cifras de tokens tienen que ver sobre todo con la caché. Codex, Claude Code, Cline, Opencode, Gemini y Grok cachean entre el 86 y el 98% de su entrada, de modo que los 4.18M de tokens brutos de Claude Code se reducen a unos efectivos 115k. Junie, Goose, Kiro, Forge y Aider no cachean, por lo que pagan por cada token que reenvían; es por eso que los 2.36M de Junie son los más altos del campo.
- Tres advertencias sobre las cifras: para los cinco agentes que no cachean, la entrada efectiva es todo lo que enviaron, por lo que debe leerse como un techo; 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 donde alcanzó su límite de error antes de entregar un frontend, cada una puntuada con 0.
Puedes consultar nuestra metodología más abajo.
Cómo funcionan las herramientas CLI agénticas
Las herramientas CLI agénticas son agentes autónomos que operan dentro de la terminal. Aunque la mayoría de usuarios las despliegan para tareas de codificación, pueden ejecutar cualquier flujo de trabajo que pueda realizarse mediante comandos de shell.
Estos agentes suelen operar en un bucle que consta de tres fases:
- Recopilar contexto
- Actuar
- Verificar resultados
Tras la verificación, el agente recopila contexto actualizado y repite el bucle hasta completar la tarea o alcanzar 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 agente 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 computador, integraciones MCP o "habilidades" reutilizables.
Distintas arquitecturas de agente imponen diferentes estrategias de planificación, políticas de reintento y lógicas 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 agénticas no provienen de una única fuente. Emergen de dos capas: el modelo de base y el framework de orquestación que lo envuelve.
Este benchmark prueba a todos los agentes con el mismo modelo de base: Claude Sonnet 4.6. Por lo 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 tras un fallo.
Opencode y Claude Code usan directamente Sonnet 4.6. Opencode obtiene un 77.3% en backend; Claude Code un 74.9%. Dos agentes, mismo modelo, 2.4 puntos porcentuales de diferencia en corrección de backend. Kiro y Opencode usan ambos Sonnet 4.6. Kiro obtiene un 64.2% en backend; Opencode un 77.3%. La brecha de 13 puntos es la contribución de la CLI.
Los dos benchmarks observacionales que siguen llevan esto más lejos. Ejecutan la misma prueba con modelo común en investigación web y compactación de contexto, donde las brechas no son de 13 puntos, sino la diferencia entre encontrar la respuesta correcta e inventar una errónea.
Fundamentación en investigación web
Solicitamos a cada agente que auditara documentación de un framework: qué versión introdujo una característica, cuál es su estado actual y qué cambió recientemente. Cada respuesta debía citar una fuente oficial. Realizamos la prueba dos veces, una con Unity y otra con Next.js/React. Los hechos se seleccionaron de modo que la respuesta correcta solo exista en una página actual y publicada. Responder a partir de los datos de entrenamiento produce una respuesta segura pero incorrecta. Verificamos una cosa: ¿realmente obtuvo el agente 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.
Se observaron cuatro patrones.
- Búsqueda real en vivo: Codex, Claude Code, Gemini y Grok obtienen páginas actuales y detectan cambios recientes. Codex fue el único agente que llegó al foro de desarrolladores, donde residen los datos más complejos.
- Busca, pero llega a páginas antiguas: Cline obtuvo dos docenas de páginas de documentación reales y aun así informó de una versión que ya había sido reemplazada. Las obtenciones fueron reales; las páginas estaban desactualizadas.
- Sin búsqueda, responde desde el entrenamiento: Aider no navega y lo dice abiertamente. Esta es la respuesta honesta.
- Fuentes inventadas: Forge no obtuvo nada 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 obtenida durante esta sesión".
En la prueba de Next.js, todos los demás agentes con navegación fundamentaron casi todas sus citas en páginas que realmente habían obtenido. Forge no fundamentó ninguna. El gráfico contrasta las citas fundamentadas de cada agente con 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 obtención verificable por URL. Grok (búsqueda del 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 ambos con Sonnet 4.6 en esta prueba. Claude Code encontró y abrió la página con la respuesta correcta. Cline no lo hizo. Mismo modelo, diferente resultado.
Puntuamos cada respuesta en cuanto a precisión factual, pero esas puntuaciones dependen de una clave de respuestas actualmente en revisión. No publicaremos las tablas de precisión hasta que la clave esté finalizada.
Compactación de contexto
Cuando una sesión se vuelve larga, el agente compacta su contexto: reemplaza el historial detallado por un breve resumen y descarta los originales. Probamos si el resumen retiene lo que importa.
Proporcionamos a cada agente aproximadamente 112,000 tokens de documentos con 13 hechos inventados incrustados: un PIN de guardia, una región de nube, una etiqueta de compilación y diez más. Inventados 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 fuente 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 obtuvieron 0 de memoria solo habían respondido 13 de 13 mientras podían releer los archivos. Estaban releyendo en cada consulta. Cuando los archivos desaparecieron, escribieron "desconocido" en lugar de adivinar.
Goose, Forge, Opencode y Kiro ejecutan todos Sonnet 4.6. Kiro retuvo los 13. Los otros tres no retuvieron ninguno. Mismo modelo, resultado opuesto.
Opencode ocupa el primer lugar en el benchmark de construcción y no retiene nada en compactación. Kiro ocupa el séptimo lugar en el benchmark de construcción y lo retiene todo en 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 ser llevado a 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 unos 2,000 caracteres, por lo que los documentos se colapsaron en vistas previas breves. Su contexto se estancó 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 completamente, por lo que nunca hubo un contexto completo que compactar. El resumidor de Aider comprime los turnos de 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.
Comportamientos de los agentes en la tarea 6
Evaluamos a los agentes en 10 tareas. A continuación se muestra un desglose detallado de la Tarea 6 para mostrar cómo se comportan diferentes arquitecturas CLI bajo las mismas restricciones cuando todas se ejecutan con el mismo modelo.
Tarea 6: Sistema de tickets de soporte (Web)
La tarea 6 requería construir un sistema de tickets de soporte full-stack con:
- Dos roles de usuario (cliente y agente)
- Autenticación basada en JWT
- Transiciones estrictas del flujo de estados
- Aislamiento de datos (404 en lugar de 403 para accesos entre usuarios)
- Backend con FastAPI
- Frontend con React/Vue/Svelte + Vite
- Comandos de ejecución deterministas
La prueba de humo validó:
- Comprobación de salud
- Autenticación de doble rol
- Operaciones CRUD de tickets
- Asignación y respuestas
- Transiciones de estado
- Aplicación de roles
- Aislamiento de datos
- Inicio de sesión en la UI y comportamiento posterior al inicio de sesión
Esta tarea pone a prueba la gestión de estado, la corrección de autenticación, la disciplina del contrato REST y la integración frontend-backend. Visita GitHub para ver los detalles de la tarea.
Con un mismo modelo, el campo se dividió en tres grupos.
- 60% en backend, 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 superados; ambos fallos estuvieron en _11329_0_ y _11329_1_, donde construyeron un _11329_2_ 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%; con 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 cada paso dependiente falló en cascada.
- 24.4%, Kiro: inestabilidad, no un único modo de fallo. Superó nueve pasos en la primera ejecución, dos en la segunda, y en la tercera el backend nunca se inició (la comprobación de salud falló). Los otros diez agentes repitieron de forma idéntica en cada repetición.
- UI dentro del grupo del 60%: claude-code y cline fallaron el inicio de sesión por un error CORS idéntico, el frontend llamó al backend en _11329_3_ desde un origen _11329_4_ y el navegador lo bloqueó, por lo que ambos obtuvieron un 75%; los otros cinco se renderizaron e iniciaron sesión correctamente con un 100%.
- La conclusión es la convergencia: siete CLIs diferentes con el mismo modelo cometieron el mismo error de contrato REST, por lo que aquí el modelo domina y la orquestación apenas importa, justo lo contrario de los benchmarks observacionales siguientes.
Codex
Instalación
Instala globalmente con:
- npm install -g @openai/codex
Alternativamente, instala 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 de API de OpenAI. No hay opciones de proveedor disponibles.
Informe de tarea
Codex construyó un sistema funcional en 454 segundos y se situó en el grupo del 60%. La lógica de negocio era correcta; no cumplió el contrato REST en asignación y estado, como el resto del campo.
Comportamiento del Backend
Autenticación, CRUD de tickets, respuestas y aislamiento de datos superados. 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 dirigió 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 UI
El frontend superó los ocho pasos de validación. El inicio de sesión y el estado posterior funcionaron correctamente. 100% UI.
Junie
Instalación
Junie está disponible a través de JetBrains Toolbox o como 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 de API de Anthropic, OpenAI, Google u otros proveedores compatibles. Múltiples opciones de proveedor disponibles.
Informe de tarea
Junie produjo un sistema full-stack completo 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 campo con 1.52M, un límite superior no cacheado afectado por un error conocido de contabilidad de caché (ver nota en la tabla de resultados).
Comportamiento del Backend
Nueve de dieciséis pasos superados: 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 UI
El frontend superó los ocho pasos de validación. 100% UI.
Kiro CLI
Instalación
Para macOS/Linux/WSL:
- curl -fsSL https://cli.kiro.dev/install | bash
Alternativa Linux AppImage (opción portable):
- Descargar: https://desktop-release.q.us-east-1.amazonaws.com/latest/kiro-cli.appimage
Luego ejecuta:
- chmod +x kiro-cli.appimage && ./kiro-cli.appimage
Autenticación
Puedes continuar con tu plan Kiro-Code. No hay opciones de proveedor disponibles.
Informe de tarea
Kiro es el único agente cuya puntuación refleja inestabilidad en lugar de una única decisión de diseño. Su 24.4% en backend es un promedio de tres repeticiones que produjeron tres resultados diferentes. La construcción en sí era sólida cuando se ejecutaba; el problema fue que no se ejecutó igual dos veces.
Comportamiento del Backend
En la primera ejecución, Kiro superó 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 superó dos. En la tercera, el backend nunca se levantó e incluso la comprobación de salud falló. Promediando, esto da 24.4%. La inestabilidad, no el diseño de los endpoints, es lo que separa a Kiro del grupo aquí.
Comportamiento de la UI
Cuando el backend estaba activo, el frontend superó los ocho pasos de validación. 100% UI. Esto supone un cambio respecto a la ejecución anterior, donde el formulario de inicio de sesión no se renderizó 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 tarea
Claude Code obtuvo un 60% en backend en 379 segundos, en el grupo principal. Esto supone una mejora notable 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 UI.
Comportamiento del Backend
Autenticación, CRUD de tickets, respuestas y aislamiento de datos superados. Los seis fallos fueron los pasos de asignación y transición de estado, dirigidos 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 UI
El paso de inicio de sesión falló. El frontend llamó al backend en _11329_5_ mientras la página se servía desde un origen _11329_6_, y el navegador bloqueó la solicitud de inicio de sesión por la política CORS. Cinco pasos superados, uno fallado, dos bloqueados. 75% UI. 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 de API en tu entorno con:
- export OPENROUTER_API_KEY=”sk-or-v1-…”
Informe de tarea
Aider fue el agente más rápido con 236 segundos y el más ligero, con 1.3k tokens de entrada y 18k de salida. También obtuvo un 13.3% en backend. La autenticación funcionó, pero la creación de tickets falló, y cada paso que requería un ticket existente falló con ello.
Comportamiento del Backend
Dos pasos superados. La construcción se rompió en la creación de tickets, por lo que las listas de tickets de cliente y agente, respuestas, asignación, transiciones de estado y comprobaciones de roles fallaron en cascada. Estable en las tres repeticiones. Esta es una clase de fallo diferente a la del grupo del 60%, que creaba tickets correctamente y solo fallaba en las rutas de asignación y estado.
Comportamiento de la UI
El paso de inicio de sesión falló por la misma discrepancia de origen CORS observada en claude-code y cline. Cinco pasos superados, uno fallado, dos bloqueados. 75% UI.
OpenCode
Instalación
Para macOS/Linux/WSL:
- curl -fsSL https://opencode.ai/install | bash
Instala 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 autentícate con /connect
Informe de 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 más clara de influencia del modelo en el artículo. En la ejecución anterior con modelo nativo en 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 cayó a un 60%. La herramienta no cambió; el modelo sí.
Comportamiento del Backend
Autenticación, CRUD de tickets, respuestas y aislamiento de datos superados. Los seis fallos fueron los pasos de asignación y transición de estado, dirigidos a través de un endpoint de actualización unificado. Estable en las tres repeticiones.
Comportamiento de la UI
El frontend superó los ocho pasos de validación. 100% UI.
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 de API para uso headless:
- export XAI_API_KEY=”xai-…”
Informe de 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 superados: 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 _11329_7_ y _11329_8_. Grok dirigió 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 UI
El frontend superó los ocho pasos de validación. El inicio de sesión y el estado posterior funcionaron correctamente. 100% UI.
Forge
Instalación
Para macOS/Linux/WSL:
- curl -fsSL https://forgecode.dev/cli | sh
Autenticación
Configura tus credenciales de proveedor de forma interactiva con:
- forge provider login
Y elige tu proveedor.
Informe de tarea
Forge obtuvo un 13.3% en backend en 844 segundos. Su recuento de tokens de salida es el más bajo del campo con 1.6k, lo que apunta a una implementación superficial. Como en la ejecución anterior, la construcción se rompió en la creación de tickets y falló en cascada.
Comportamiento del Backend
Dos pasos superados. La creación de tickets falló, por lo que las listas de tickets, respuestas, asignación, transiciones de estado y 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 UI
El paso de inicio de sesión falló por la misma discrepancia de origen CORS observada en claude-code, cline y aider. Cinco pasos superados, uno fallado, dos bloqueados. 75% UI.
Gemini CLI
Instalación
Ejecuta al instante:
- npx @google/gemini-cli
O instala globalmente:
- npm install -g @google/gemini-cli
- brew install gemini-cli
Autenticación
Opción 1 (Google OAuth): export GOOGLE_CLOUD_PROJECT=”TU_ID_DE_PROYECTO” luego inicia gemini.
Opción 2 (clave de API): export GEMINI_API_KEY=”TU_CLAVE_API” luego inicia gemini.
Opción 3 (Vertex IA): export GOOGLE_API_KEY + GOOGLE_GENAI_USE_VERTEXAI=true.
Informe de tarea
Gemini CLI obtuvo un 13.3% en backend en 926 segundos, uno de los dos agentes más lentos del campo. La autenticación funcionó, pero la creación de tickets falló y se produjo el fallo en cascada. Su frontend, que falló por completo en la ejecución anterior debido a una incompatibilidad entre Node 18 y Vite 7, superó cada paso esta vez.
Comportamiento del Backend
Dos pasos superados. 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 UI
El frontend superó los ocho pasos de validación. 100% UI, 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
Instala globalmente con:
- npm install -g cline
Autenticación
Escribiendo `cline auth` puedes seleccionar tu cuenta de Cline o continuar con tu proveedor deseado.
Informe de tarea
Cline obtuvo un 60% en backend en 648 segundos, en el grupo principal. Esto supone un gran cambio respecto a la ejecución anterior, donde su límite de ocho errores terminó la construcción prematuramente y dejó un frontend vacío. Aquí completó el stack completo.
Comportamiento del Backend
Autenticación, CRUD de tickets, respuestas y aislamiento de datos superados. Los seis fallos fueron los pasos de asignación y transición de estado, dirigidos a través de un endpoint de actualización unificado. Estable en las tres repeticiones.
Comportamiento de la UI
El paso de inicio de sesión falló por la misma discrepancia de origen CORS observada en claude-code, en una página _11329_9_ llamando a un backend _11329_10_. Cinco pasos superados, uno fallado, dos bloqueados. 75% UI.
Goose
Instalación
Para macOS/Linux/WSL:
- curl -fsSL https://github.com/block/goose/releases/download/stable/download_cli.sh | bash
Informe de tarea
Goose obtuvo un 60% en backend en 553 segundos, en el grupo principal, pero consumió 1.06M tokens de entrada para lograrlo. Esta vez completó el stack completo, un cambio 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 superados. Los seis fallos fueron los pasos de asignación y transición de estado, dirigidos a través de un endpoint de actualización unificado. Estable en las tres repeticiones.
Comportamiento de la UI
El frontend superó los ocho pasos de validación. 100% UI, frente al 0% de la ejecución anterior.
Añadir como fuente preferidaHerramientas de codificación con IA
Las herramientas de codificación con IA pueden agruparse en tres categorías:
- CLI Agénticas: Herramientas para flujos de trabajo de desarrollo basados en terminal, generan, editan y refactorizan código mediante prompts e interacciones en línea de comandos.
- Ejemplos: Aider, Junie, Opencode, Claude Code, Codex
- Editores de código IA: También conocidos como IDEs agénticos, estas herramientas proporcionan una GUI similar a VS Code (la mayoría están construidas sobre VS Code).
- Ejemplos: Antigravity, Cursor, Kiro Code, Windsurf
- Constructores de apps a partir de prompts: Plataformas low-code/no-code para construir apps 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 agénticas?
En 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 la terminal.
- Flujos de trabajo agentivos: Realizar tareas de varios pasos como encadenamiento de tareas, resolución de problemas, búsqueda y depuración iterativa.
- Gestión de Git y proyectos: Revisar historial, resolver fusiones, 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 en operaciones CLI complejas.
- Manejo profundo de contexto: Operar sobre repositorios completos con conciencia de dependencias y estructura del proyecto.
- Flexibilidad de modelo: Soporta múltiples modelos en la nube y, en algunos casos, locales; algunas herramientas permiten usar tu propia clave de API o elegir entre planes.
- Acceso controlado o en sandbox: Ofrecen modos que van desde solo lectura hasta automatización total, a menudo con entornos aislados por seguridad.
Metodología
Benchmark A-CODE-CLI
Evaluamos a los agentes bajo una configuración de ejecución única para medir la capacidad autónoma sin intervención humana. Luego, los agentes fueron evaluados 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. Los 11 agentes se ejecutaron en Claude Sonnet 4.6 (no razonador). Dos agentes requirieron un proxy para alcanzar este modelo:
- Codex (CLI de OpenAI) no puede apuntar a modelos de Anthropic de forma nativa. Se enrutó a través de una pasarela LiteLLM a OpenRouter/Anthropic, con un shim de caché que restaura el almacenamiento en caché de los 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 a modelos auxiliares (detección de bucles, reparación de herramientas mal formadas, compresión de contexto) fallan o devuelven contenido no válido a través del proxy, por lo que se ejecutó 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 reenvían. Todos los demás agentes utilizaron Sonnet 4.6 directamente a través de su configuración de proveedor nativo o OpenRouter.
El proxy solo puede perjudicar a codex y gemini-cli, nunca inflarlos. Sus puntuaciones son conservadoras.
Junie co-ejecuta un helper GPT-4.1-mini no anulable junto al primario Sonnet 4.6. Es el único agente con un segundo modelo activo durante la construcción. Sus puntuaciones llevan un asterisco de multi-modelo.
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).
Ningún agente tuvo ajustes de temperatura, reintentos o razonamiento. Cada uno se ejecutó con su configuración predeterminada.
Puntuación. Backend: humo funcional (adaptive_avg_step_pass_rate). Frontend: humo de UI mediante Playwright. Combinada: 0.7 × backend + 0.3 × frontend (para agentes con datos de UI completos). La puntuación de backend es el eje de clasificación principal. El rendimiento del frontend se satura en todo el campo.
Aider t-3 y t-4. Ambas tareas produjeron backends que fallaban al iniciarse. Confirmado en dos construcciones nuevas (mismos errores: TypeError en class Card en t-3, AmbiguousForeignKeysError en User.auctions en t-4). Puntuados con 0 con una bandera backend_never_ready, no excluidos.
Para 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 versiones de Next.js/React (prueba 3). Cada una pedía al agente que informara de la versión, el estado y el cronograma de características especificadas del framework y citara una URL oficial por afirmación.
La calificación utilizó dos métodos paralelos. Filtro de verdad fundamental: una afirmación puntúa solo si la URL citada aparece en el registro de obtención real del agente Y la página obtenida contiene el hecho, medido contra una clave de respuestas verificada. Clasificación de comportamiento: un juez LLM leyó la transcripción completa de cada agente y lo asignó a una de las cuatro categorías de comportamiento. La clasificación de comportamiento 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 de infraestructura. Después de que el agente leyera los documentos y compactara su contexto, eliminamos los archivos fuente antes de hacer cualquier pregunta. Puntuación: coincidencia exacta con los 13 valores inventados, automatizada por un script de calificación con una regex por hecho. N=3.
Los agentes que puntuaron 13/13 con archivos presentes y 0/13 con archivos eliminados se clasifican como relectores. Los agentes que puntuaron 13/13 con 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 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 principales servidores MCP para acceso web.
- Navegadores remotos: Cómo la infraestructura de navegadores emergente 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{kalelioglu2026,
author = {Kalelioğlu, Berk and Dilmegani, Cem},
title = {{Benchmark A-CODE-CLI: Evaluación de CLI Agénticas}},
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
Siguiente para leer
Comparativa de Plataformas de Agentes de IA: Agentes Gestionados de Claude vs Vertex Agent Engine de Google
Principales 9 Proveedores de IA Comparados
Constructores de Agentes de IA Bajo Código/Sin Código: n8n,make, Zapier
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.