A-CODE-CLI Bench: Benchmark de CLI agénticas
Las herramientas CLI agénticas son herramientas de programación con IA que pueden crear y eliminar archivos, ejecutar comandos, planificar y ejecutar la programación de todo el proyecto. Evaluamos las herramientas líderes en 10 escenarios reales de desarrollo web, realizando ~600 comprobaciones de validación atómicas por agente y más de ~5.000 ejecuciones de pruebas automatizadas totales, incluyendo lógica de backend, funcionalidad de frontend y verificación de consistencia en múltiples ejecuciones.
Resultados del benchmark de CLI agénticas
Información sobre el rendimiento de las herramientas CLI agénticas
La corrección del backend determina la clasificación; la puntuación combinada la pondera con 0.7 frente a 0.3 del frontend.
- Los nueve agentes que se ejecutan limpiamente usan el mismo Sonnet 4.6, pero el backend va desde el 77.3 % de Opencode hasta el 55.4 % de Goose. Esa brecha de 22 puntos proviene enteramente de la orquestación.
- Un backend sólido no garantiza un buen resultado final: Cline (4 en backend, 69.5 %) y Forge (5, 67.2 %) se sitúan cerca de la cima en backend, pero quedan muy rezagados en frontend; el 52.5 % de Cline es el más débil del grupo, por lo que ambos bajan en la clasificación combinada.
- Codex ocupa el 10 en backend (52.1 %) a pesar de un frontend perfecto del 100 %. Aquí se ejecuta a través de un proxy para llegar al modelo común, lo que puede perjudicar sus capacidades, por lo que es probable que esto sea un suelo y no el verdadero backend del agente.1 Gemini, que también se ejecuta a través de un proxy, está limitado de la misma manera.
- La clasificación en compilació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 mitad del grupo lo retiene todo.
Velocidad, uso de tokens y coste frente a puntuación
Evaluamos la eficiencia en tiempo de ejecución utilizando 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:
Lo rápido, barato o ligero en tokens que sea un agente no predice su puntuación.
- Opencode gana en los tres 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 el típico equilibrio entre precisión y coste.
- El coste varía unas 40x, desde $0,18 para Forge hasta $7,58 para 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 74.7 % de mitad de tabla y constituyen 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 agente más rápido ni el más lento gana: Kiro (439s) y Gemini (1.158s, sobrecarga de proxy) se quedan en la zona media. El gasto adicional compra reintentos y revalidaciones, no profundidad en la resolución de problemas.
- Las cifras de tokens se deben sobre todo al almacenamiento en caché. Codex, Claude Code, Cline, Opencode, Gemini y Grok guardan en caché 86–98 % de su entrada, de modo que los 4.18M tokens brutos de Claude Code se reducen a un efectivo de 115k. Junie, Goose, Kiro, Forge y Aider no guardan en caché, por lo que pagan por cada token que reenvían; por eso los 2.36M de Junie son los más altos del grupo.
- Tres advertencias sobre las cifras: para los cinco agentes sin caché, la entrada efectiva es todo lo que enviaron, por lo que hay que leerla como un techo; los $1,72 de Kiro son un suelo (facturado por créditos, más cerca de $2,23); el 64.4 % de Cline incluye cuatro tareas en las que alcanzó su límite de errores antes de entregar un frontend, cada una puntuada con 0.
Puedes ver nuestra metodología a continuación.
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 los usuarios las emplean para tareas de programació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
- Realizar acciones
- 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 marco 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 de computadora, integraciones de MCP o “skills” reutilizables.
Las distintas arquitecturas de 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 robustez de comportamiento reducida.
Inteligencia del modelo frente a arquitectura del agente
Las diferencias de rendimiento entre las herramientas CLI agénticas no provienen de una única fuente. Surgen de dos capas: el modelo fundacional y el marco de orquestación que lo envuelve.
Este benchmark prueba a ambos agentes con el mismo modelo fundacional: Claude Sonnet 4.6. Por tanto, cualquier diferencia de puntuación es una diferencia de 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 obtiene un 74.9 %. Dos agentes, el mismo modelo, una diferencia de 2.4 puntos porcentuales en la corrección del backend. Kiro y Opencode usan ambos Sonnet 4.6. Kiro obtiene un 64.2 % en backend; Opencode obtiene un 77.3 %. La brecha de 13 puntos es la contribución de la CLI.
Los dos benchmarks observatorios que se presentan 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 brechas no son de 13 puntos, sino la diferencia entre encontrar la respuesta correcta e inventar una equivocada.
Fundamentación de la investigación web
Pedimos a cada agente que auditara la documentación de los marcos: qué versión introdujo una función, cuál es su estado actual y qué cambió recientemente. Cada respuesta debía citar una fuente oficial. Ejecutamos la prueba dos veces, una en Unity y otra en Next.js/React. Los hechos se seleccionaron de modo que la respuesta correcta solo exista en una página actual publicada. Responder a partir de los datos de entrenamiento produce una respuesta segura pero equivocada. Comprobamos una sola 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 en sus modelos nativos no Sonnet; los otros ocho, incluido Claude Code, se ejecutaron en Sonnet 4.6.
Surgieron cuatro patrones.
- Búsqueda en vivo real Codex, Claude Code, Gemini y Grok obtienen páginas actuales y captan cambios recientes. Codex fue el único agente que llegó al foro de desarrolladores, donde viven los hechos más difíciles.
- Busca, pero aterriza en 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 obsoletas.
- Sin búsqueda, responde desde el entrenamiento Aider no navega y lo dice. Es la respuesta honesta.
- Fuentes fabricadas Forge no obtuvo nada que funcionara y, sin embargo, citó 31 fuentes en la prueba de Next.js. Las páginas citadas no existen. Su declaración de cierre: “cada celda proviene 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 apila las citas fundamentadas de cada agente frente a las fabricadas, de modo que los agentes honestos aparecen como barras verdes completas y Forge como una sola barra roja. El gráfico cubre a 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 en Sonnet 4.6 en esta prueba. Claude Code encontró y abrió la página con la respuesta correcta. Cline no lo hizo. El mismo modelo, distinto resultado.
Puntuamos cada respuesta por su exactitud factual, pero esas puntuaciones dependen de una clave de respuestas que está actualmente en revisión. Retenemos las tablas de exactitud hasta que se finalice la clave.
Compactación de contexto
Cuando una sesión se alarga, el agente compacta su contexto: sustituye el historial detallado por un resumen breve y descarta los originales. Comprobamos si el resumen retiene lo importante.
Dimos 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 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 obtuvieron 0 de memoria solo habían respondido 13 de 13 mientras aún podían volver a leer los archivos. Estaban releyendo en cada consulta. Cuando los archivos desaparecieron, escribieron “desconocido” en lugar de adivinar.
Goose, Forge, Opencode y Kiro se ejecutan todos con Sonnet 4.6. Kiro retuvo los 13. Los otros tres no retuvieron ninguno. El mismo modelo, resultado opuesto.
Opencode ocupa el primer lugar en el benchmark de compilación y no retiene nada en la compactación. Kiro ocupa el séptimo lugar en el benchmark de compilación y retiene todo en la compactación. Un buen rendimiento de compilació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. No se pudo llevar a Cline a su umbral de compactación. Creamos un conjunto de documentos de 863.000 tokens y le hicimos leer todos los archivos, pero Cline trunca cada salida de herramienta a unos 2.000 caracteres, de modo que los documentos se colapsaron en vistas previas cortas. 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 que Cline no es 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 de chat, no el contenido de los archivos añadidos a la sesión, que es donde vivían los hechos. Junie no tiene función de compactación.
Comportamiento 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 las distintas arquitecturas de CLI bajo las mismas restricciones cuando todas se ejecutan con el mismo modelo.
Tarea 6: Sistema de tickets de mesa de ayuda (Web)
La tarea 6 requería crear un sistema de tickets de mesa de ayuda de pila completa con:
- Dos roles de usuario (cliente y agente)
- Autenticación basada en JWT
- Transiciones estrictas del flujo de trabajo de estados
- Aislamiento de datos (404 en lugar de 403 para el acceso entre usuarios)
- Backend con FastAPI
- Frontend con React/Vue/Svelte + Vite
- Comandos de ejecución deterministas
La prueba de humo validó:
- Verificació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 interfaz y comportamiento posterior al inicio de sesión
Esta tarea pone a prueba la gestión de estado, la corrección de la autenticación, la disciplina del 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 grupos.
- 60 % de backend, siete agentes (codex, claude-code, cline, grok, goose, junie, opencode): los mismos seis pasos fallaron en las tres repeticiones. La autenticación, el CRUD de tickets, las respuestas y el aislamiento de datos pasaron; ambos fallos estuvieron en
/tickets/{id}/assigny/tickets/{id}/status, donde construyeron unPATCH /tickets/{id}unificado en lugar de las rutas separadas de las especificaciones. La lógica de negocio era correcta, pero el contrato REST estaba mal. En la ejecución nativa anterior con Gemini 3 Pro, Opencode construyó los endpoints separados y obtuvo un 93.3 %; con Sonnet 4.6 eligió el diseño unificado como el resto. - 13.3 %, tres agentes (aider, forge, gemini-cli): la autenticación funcionó, pero la propia creación de tickets falló, por lo que todos los pasos dependientes cayeron en cascada.
- 24.4 %, Kiro: inestabilidad, no un único modo de fallo. Pasó nueve pasos en la primera ejecución, dos en la segunda y en la tercera el backend nunca arrancó (falló la verificación de salud). Los otros diez agentes se repitieron de forma idéntica en cada repetición.
- Interfaz de usuario dentro del clúster del 60 %: claude-code y cline fallaron en el inicio de sesión por un mismo error de CORS; el frontend llamó al backend en
localhost:8000desde un origen127.0.0.1y el navegador lo bloqueó, de modo que ambos obtuvieron 75 %; los otros cinco renderizaron e iniciaron sesión sin problemas 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, lo contrario de los benchmarks observatorios que se muestran a continuación.
Codex
Instalación
Instala globalmente con:
- npm install -g @openai/codex
Alternativamente, instala globalmente con Homebrew (macOS/Linux)
- brew install –cask codex
Autenticación
Tras 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 la tarea
Codex construyó un sistema funcional en 454 segundos y se situó en el clúster del 60 %. La lógica de negocio era correcta; falló en el contrato REST en asignación y estado, como el resto del grupo.
Comportamiento del backend
La autenticación, el CRUD de tickets, las respuestas y el aislamiento de datos pasaron. 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, de modo 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 estado posterior al inicio de sesión se comportaron correctamente. 100 % de interfaz.
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. Hay múltiples opciones de proveedor disponibles.
Informe de la tarea
Junie produjo un sistema completo de pila completa en 444 segundos y obtuvo un 60 % en backend, en el clúster principal. Su entrada efectiva en esta tarea es la más alta del grupo, con 1.52M, un límite superior sin caché afectado por un error conocido de contabilidad de caché (véase la nota de la tabla de resultados).
Comportamiento del backend
Pasaron nueve de dieciséis pasos: 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 manejó el estado y la asignación a través de un endpoint de actualización unificado, de modo que las rutas `/tickets/{id}/assign` y `/tickets/{id}/status` de las especificaciones 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 % de 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):
- Download: 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 de Kiro-Code. No hay opciones de proveedor disponibles.
Informe de la 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 compilación en sí era sólida cuando se ejecutaba; el problema era que no se ejecutaba igual dos veces.
Comportamiento del backend
En la primera ejecución, Kiro pasó nueve de dieciséis pasos, el mismo perfil que el clúster del 60 %, fallando solo en las rutas de asignación y estado. En la segunda ejecución pasó dos. En la tercera, el backend nunca se levantó e incluso falló la verificación de salud. Promediado, esto es 24.4 %. La inestabilidad, no el diseño de los endpoints, es lo que separa a Kiro del clúster aquí.
Comportamiento de la interfaz
Cuando el backend estaba activo, el frontend pasó los ocho pasos de validación. 100 % de interfaz. Esto supone un cambio respecto a la ejecución anterior, en la que el formulario de inicio de sesión no se renderizó debido a un 422 en el montaje.
Claude Code
Instalación
Para macOS/Linux/WSL, teniendo en cuenta tu gestor de paquetes preferido, puedes instalar Claude Code con cualquiera de estas opciones:
- curl -fsSL https://claude.ai/install.sh | bash
- npm install -g @anthropic-ai/claude-code
Autenticación
Tras 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 clúster principal. Esto supone una mejora notable respecto a la ejecución anterior, en la que 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
La autenticación, el CRUD de tickets, las respuestas y el aislamiento de datos pasaron. 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 las especificaciones. Estable en las tres repeticiones.
Comportamiento de la interfaz
El paso de inicio de sesión falló. El frontend llamó 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 por la política de CORS. Pasaron cinco pasos, uno falló y dos quedaron bloqueados. 75 % de 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 de 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 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 todos los pasos que necesitaban un ticket existente fallaron con él.
Comportamiento del backend
Pasaron dos pasos. La compilación se rompió en la creación de tickets, de modo que las listas de tickets de clientes y agentes, las respuestas, la asignación, las transiciones de estado y las comprobaciones de roles cayeron todas en cascada. Estable en las tres repeticiones. Se trata de una clase de fallo diferente a la del clúster 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ó por la misma discrepancia de origen CORS observada en claude-code y cline. Pasaron cinco pasos, uno falló y dos quedaron bloqueados. 75 % de interfaz.
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, teniendo en cuenta 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 el proveedor deseado y autentícate con /connect
Informe de la tarea
Opencode lidera el benchmark general, pero en la Tarea 6 obtuvo un 60 % en backend, en el clúster principal, en 542 segundos. Esta es la evidencia de modelo más clara del artículo. En la ejecución nativa anterior con Gemini 3 Pro Preview, Opencode construyó los endpoints separados de las especificaciones y obtuvo un 93.3 % aquí. La misma CLI con Sonnet 4.6 eligió el endpoint unificado y bajó al 60 %. La herramienta no cambió; el modelo sí.
Comportamiento del backend
La autenticación, el CRUD de tickets, las respuestas y el aislamiento de datos pasaron. 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 % de 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 arranque o establece una clave de API para uso sin interfaz:
- export XAI_API_KEY=”xai-…”
Informe de la tarea
Grok terminó segundo en el benchmark de compilación con un 75.4 % en backend. En la Tarea 6 obtuvo un 60 % en backend en 433 segundos, en el clúster principal. En esta ejecución, Grok llegó a Sonnet 4.6 a través de OpenRouter.
Comportamiento del backend
Pasaron nueve de dieciséis pasos: 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, de modo 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 estado posterior al inicio de sesión se comportaron correctamente. 100 % de 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 cayó en cascada.
Comportamiento del backend
Pasaron dos pasos. La creación de tickets falló, de modo que las listas de tickets, las respuestas, la asignación, las transiciones de estado y las comprobaciones de roles fallaron todas con él. 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ó por la misma discrepancia de origen CORS observada en claude-code, cline y aider. Pasaron cinco pasos, uno falló y dos quedaron bloqueados. 75 % de interfaz.
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): exporta GOOGLE_CLOUD_PROJECT=”YOUR_PROJECT_ID” y luego inicia gemini.
Opción 2 (clave de API): exporta GEMINI_API_KEY=”YOUR_API_KEY” y luego inicia gemini.
Opción 3 (Vertex IA): exporta 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 cayó en cascada. Su frontend, que en la ejecución anterior falló por completo debido a una incompatibilidad entre Node 18 y Vite 7, pasó todos los pasos esta vez.
Comportamiento del backend
Pasaron dos pasos. La creación de tickets falló, de modo 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 % de 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
Instala globalmente con:
- npm install -g cline
Autenticación
Al escribir `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 clúster principal. Se trata de un gran cambio respecto a la ejecución anterior, en la que su límite de ocho errores terminó la compilación de forma anticipada y dejó un frontend vacío. Aquí completó la pila completa.
Comportamiento del backend
La autenticación, el CRUD de tickets, las respuestas y el aislamiento de datos pasaron. 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ó por la misma discrepancia de origen CORS observada en claude-code, en una página 127.0.0.1 que llamaba a un backend localhost. Pasaron cinco pasos, uno falló y dos quedaron bloqueados. 75 % de 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 clúster principal, pero consumió 1.06M tokens de entrada para lograrlo. Esta vez completó la pila completa, un cambio respecto a la ejecución anterior, en la que el directorio del frontend quedó vacío.
Comportamiento del backend
La autenticación, el CRUD de tickets, las respuestas y el aislamiento de datos pasaron. 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 % de interfaz, frente al 0 % de la ejecución anterior.
Añadir como fuente preferidaHerramientas de programación con IA
Las herramientas de programación con IA se pueden agrupar en tres categorías:
- CLI agénticas: herramientas para flujos de trabajo de desarrollo basados en terminal, que 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 agénticos, estas herramientas ofrecen una interfaz gráfica similar a VS Code (la mayoría están construidas sobre VS Code).
- Ejemplos: Antigravity, Cursor, Kiro Code, Windsurf
- Creadores de apps a partir de prompts: Plataformas de low-code/no-code para crear aplicaciones mediante 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?
Entre herramientas como Codex, Junie, Kiro y Claude Code, las capacidades comunes incluyen:
- Trabajo de código de extremo a extremo: crea y modifica archivos, corrige errores, refactoriza código y ejecuta pruebas o linters directamente desde la terminal.
- Flujos de trabajo agénticos: realizan tareas de varios pasos, como encadenamiento de tareas, resolución de problemas, búsqueda y depuración iterativa.
- Git y gestión de proyectos: revisan el historial, resuelven fusiones, gestionan ramas y crean commits o pull requests.
- Command ejecución y automatización: ejecutan comandos de shell, automatizan análisis y traducen lenguaje natural a operaciones complejas de CLI.
- Manejo profundo del contexto: operan sobre repositorios completos con conocimiento de las dependencias y la estructura del proyecto.
- Flexibilidad de modelos: admiten 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
A-CODE-CLI Benchmark
Evaluamos a los agentes bajo una configuración de ejecución de un solo intento para medir la capacidad autónoma sin intervención humana. Después, 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. Los 11 agentes se ejecutaron en Claude Sonnet 4.6 (sin razonamiento). Dos agentes necesitaron un proxy para llegar a este modelo:
- Codex (OpenAI CLI) no puede apuntar de forma nativa a los modelos de Anthropic. Se enrutó a través de una puerta de enlace LiteLLM a 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 de forma nativa a los modelos de Anthropic. Se enrutó a través de un shim SSE y una puerta de enlace LiteLLM. Sus llamadas auxiliares al modelo (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 necesitó un proxy independiente para eliminar los bloques de pensamiento extendido de las respuestas, que Forge activa por la fuerza y que causan errores 400 cuando se devuelven. Todos los demás agentes usaron Sonnet 4.6 directamente mediante la configuración nativa de su proveedor o 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 compilació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 en Kiro (respaldado por Bedrock, multiplicador 1.3x).
Ningún agente tuvo parámetros de temperatura, reintento o razonamiento ajustados. Cada uno se ejecutó con su configuración predeterminada.
Puntuación. Backend: prueba de humo funcional (adaptive_avg_step_pass_rate). Frontend: prueba de humo de interfaz 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 arrancar. Confirmado en dos compilaciones nuevas (los mismos errores: TypeError en class Card en t-3, AmbiguousForeignKeysError en User.auctions en t-4). Se puntuaron con 0 con una marca backend_never_ready, sin excluirlos.
Para conocer la metodología de evaluación, visita: metodología del benchmark de programación con IA
Versiones de CLI (ejecución del benchmark de junio de 2026)
Versiones leídas de los servidores VPS del benchmark. La ejecución de compilación se llevó a cabo 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 de la 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 sobre la versión, el estado y el cronograma de funciones 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 obtención del agente Y la página obtenida 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 de comportamiento. La clasificación conductual es la salida 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 de infraestructura inventados. 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 los 13 valores inventados, automatizada mediante un script de calificación con una expresión regular por hecho. N=3.
Los agentes que obtuvieron 13/13 con los archivos presentes y 0/13 con los archivos eliminados se clasifican como relectores. Los agentes que obtuvieron 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 los 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 quienes exploran el ecosistema más amplio de herramientas de desarrollo agénticas, aquí están nuestros últimos benchmarks:
- Benchmark de MCP: Una comparación de los principales servidores de 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 = {{A-CODE-CLI Bench: Benchmark 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 139 puntos de datos. Descargue los datos utilizados en este artículo como un archivo ZIP que contiene 4 archivos CSV y un README.
Registro de cambios
21 actualizaciones- 2026
Añadido, una frase a la introducción, aclarando que todos los agentes se ejecutaron en el mismo modelo.
Se actualizó la sección de Metodología, proporcionando una explicación más detallada de la configuración del modelo, la puntuación y las versiones de CLI utilizadas, ofreciendo a los lectores una comprensión más clara de la configuración experimental.
Se amplió la metodología de evaluación comparativa en la introducción, ofreciendo una comprensión más clara del rigor de las pruebas.
Se eliminó la metodología detallada, reduciendo la extensión del artículo.
Se actualizó el formato de los encabezados para mejorar la legibilidad y la coherencia.
Se redujo el alcance del benchmark en la introducción, ofreciendo a los lectores una comprensión más precisa de la amplitud de la evaluación.
Se amplió la sección de Metodología, proporcionando una descripción detallada de la configuración de evaluación, las configuraciones del modelo y los mecanismos de puntuación para los agentes.
Se actualizó la introducción, la sección 'Grupo de proyectos y configuraciones de modelos', la sección 'Listas de verificación funcionales (auditoría del lado del navegador)', la sección 'Ejemplo de tarea de evaluación comparativa: panel de plataforma de educación en línea', la sección 'Alcance del proyecto y pila tecnológica', la sección 'Resultados detallados de la evaluación comparativa: rendimiento de Kiro vs Gemini CLI Kiro (95% de éxito)', la sección 'Como se vio anteriormente, Kiro entreg
Se amplió la sección '¿Qué son los agentes de codificación basados en CLI?', proporcionando una explicación más detallada de sus capacidades y beneficios para los lectores.
Se actualizó la Introducción, proporcionando una visión general más clara del alcance y la metodología del benchmark.
Se añadió una frase a la sección de Metodología, aclarando cómo se solicitaron las herramientas CLI para una evaluación comparativa más justa.
- 2025
Se amplió la sección de Metodología, proporcionando un estudio de caso detallado del proyecto 'EduSphere', ofreciendo a los lectores una comprensión más profunda de la aplicación y los resultados del benchmark.
Añadido, Resultados al artículo, proporcionando a los lectores un análisis del rendimiento de la herramienta y la metodología utilizada.
Actualizada la introducción, sección "Explore las principales herramientas CLI agenciales para optimizar y mejorar su flujo de trabajo de edición de código", para clarificar la definición y el alcance de las herramientas CLI agenciales.
Se eliminaron detalles de la sección 'Manejo de salida y contexto', simplificando la descripción del rendimiento y manejo de contexto de Claude Code.
Se movieron Claude Code y Cline CLI, en las descripciones de productos, para mejorar el flujo lógico de la información.
Se añadió Gemini CLI, OpenHands, Cline CLI y Codex CLI a la sección 'Agentes de codificación basados en CLI', proporcionando a los lectores información sobre cuatro nuevas herramientas.
Eliminada la sección 'Mejores casos de uso', reduciendo la información sobre las aplicaciones ideales de Claude Code.
Se actualizó la introducción para reflejar mejor el enfoque del artículo en las principales herramientas CLI agenciales.
Actualizada la Introducción, proporcionando a los lectores ejemplos actuales de modelos de lenguaje grandes.
Se actualizó la descripción de los 'agentes de codificación basados en CLI' en la sección 'herramientas de codificación de IA', proporcionando una comprensión más clara de su función.
Enlaces de referencia
El trabajo de Cem en AIMultiple ha sido citado por publicaciones líderes mundiales como Business Insider, Forbes, Morning Brew y Washington Post, empresas globales como Deloitte y HPE, ONG como World Economic Forum y organizaciones supranacionales como European Commission. [1], [2], [3], [4], [5]
A lo largo de su carrera, Cem trabajó como consultor tecnológico, comprador de tecnología y emprendedor tecnológico. Asesoró a empresas en sus decisiones tecnológicas en McKinsey & Company y Altman Solon durante más de una década. También publicó un informe de McKinsey sobre digitalización.
Dirigió la estrategia tecnológica y las adquisiciones de una empresa de telecomunicaciones reportando al CEO. También lideró el crecimiento comercial de la empresa de deep tech Hypatos, que alcanzó unos ingresos recurrentes anuales de 7 dígitos y una valoración de 9 dígitos desde 0 en 2 años. El trabajo de Cem en Hypatos fue cubierto por publicaciones tecnológicas líderes como TechCrunch y Business Insider.
Cem participa habitualmente en conferencias internacionales de tecnología. Se graduó en Bogazici University como ingeniero informático y tiene un MBA de Columbia Business School.
Siguiente para leer
Los 10 mejores software MSP todo en uno comparados: características y precios
AIM Enterprise: Benchmark empresarial agéntico
Agentic IT: Can LLMs Design a Benchmark
Benchmark de plataformas de agentes de IA: Claude Managed Agents vs Google Vertex Agent Engine
Las 4 principales barreras de IA: Weights and Biases y NVIDIA NeMo
Principales 9 Proveedores de IA Comparados
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.