Tengo la sensación de que Kiro es más eficiente. ¿Soy yo o es real?

Últimamente, en cualquier evento al que voy, termino discutiendo con otros compañeros, Ambassadors o Community Builders sobre qué asistente nos funciona mejor: Codex, Claude Code o Kiro. Y, personalmente, en este tiempo tenía un feeling bastante claro: Kiro es el más eficiente.

No tenía un dato real. No tenía pruebas. Básicamente, mi tenant personal de Kiro me duraba más que el de Codex o Claude Code, y podía usar un modelo potente sin llegar a un punto de bloqueo en cuestión de horas (me ha pasado). Pero ya me ha pasado otras veces que lo que pienso o mis sensaciones pueden estar influenciadas y que, sin números, nadie se lo cree — ni yo mismo.

Así que empecé a preguntarme si podía medirlo de forma objetiva y verificable. Y aquí estamos, con un benchmark reproducible sin posibilidad de influir:

• El mismo modelo en cada herramienta
• Los mismos ejercicios
• El mismo prompt
• Los mismos pesos

La respuesta corta

Por si no te apetecen seis mil palabras: la sensación era cierta, pero el motivo no era el que yo pensaba.

En el coste por tarea no hay un ganador único: depende del modelo y no es un valor comparable al 100%. Aquí sale perdiendo Kiro en comparaciones directas, aunque en el modo auto Kiro gana. Me ha sorprendido gratamente el coste de Codex, que realmente tenía como tercera opción.

Mi sensación venía de otras dos cosas: termina antes (entre un 20% y un 35% más rápido con el mismo modelo) y no te bloquea, porque su límite es mensual, mientras que Codex te corta cada semana y Claude Code cada 5 horas.

En cuanto a la calidad del código, los tres están prácticamente empatados — 4,34, 4,22 y 3,95 sobre 5. Pensaba que Claude Code iba a arrasar, pero no ha podido con Kiro, lo cual ha sido una grata sorpresa.

Si quieres saber cómo se mide esto y por qué el esfuerzo de razonamiento lo cambia todo, sigue leyendo.

Las diferencias de cada asistente

Lo primero es saber qué hace cada herramienta, porque, aunque son muy similares, funcionan de forma diferente.

Kiro

Kiro es la herramienta de AWS; originalmente solo usaba los modelos de Claude, pero últimamente ha ido ampliando su catálogo — Claude, GPT-5.6, DeepSeek, Qwen, GLM — y también incluye un router automático (auto) que elige el modelo según la tarea. Factura en credits con un multiplicador por modelo. El plan Pro son 20$/mes con 1000 credits.

Una cosa que hay que tener en cuenta es que Kiro no expone directamente los tokens consumidos. Da credits y tiempo, pero no un desglose de input/output/caché.

Codex

Codex CLI es la herramienta de OpenAI. Con el plan ChatGPT Plus (20$/mes) tienes acceso a los modelos GPT-5.6 — Sol, Terra y Luna — con límites por ventana semanal. No tiene router de modelo: eliges uno o, si no defines modelo por defecto, usas Sol con esfuerzo bajo.

A diferencia de Kiro, Codex sí da tokens exactos por ejecución, con un desglose completo: input, output, caché leída, caché escrita y tokens de razonamiento.

Claude Code

Claude Code es la herramienta de Anthropic. Con Claude Pro (20$/mes) da acceso a Haiku, Sonnet, Opus y también Fable (En EEUU puedes acceder a Mithos). Tiene algo parecido a un router — opusplan, que usa Opus para planificar y Sonnet para ejecutar — pero no es una selección automática por tarea.

Un detalle interesante es que Claude Code siempre usa dos modelos a la vez. Cuando pides Sonnet, en realidad se usa Sonnet + Haiku de fondo. Solo --model haiku usa un único modelo. Y su esfuerzo de razonamiento por defecto es high, mientras que Codex va a medium o low según el modelo.

El campo de juego: 3 suscripciones a 20$/mes

Una de las cosas más importantes de un asistente es el Hardness y es algo que no vemos aunque define el funcionamiento, por eso es importante entender que aunque la comparativa es lo más justa posible es muy difícil igualar todo a los mismos parámetros

Qué hemos ejecutado y cómo lo medimos

Los ejercicios

Necesitamos tareas que cumplan tres cosas: que sean públicas (para que cualquiera pueda repetirlas), que tengan tests automáticos (para que el resultado sea binario, sin juicios subjetivos) y que presenten un gradiente de dificultad.

La respuesta era Exercism: ejercicios de programación con tests unitarios incluidos, dificultad del 1 al 10, y todo de acceso público en GitHub. Se seleccionan 15 ejercicios de Python en tres bandas de dificultad:

• 5 fáciles (dificultad 1-2): hamming, eliuds-eggs, list-ops, resistor-color-expert, transpose
• 5 medios (dificultad 4-5): complex-numbers, forth, knapsack, relative-distance, scale-generator
• 5 difíciles (dificultad 7-9): dominoes, paasio, pov, rest-api, sgf-parsing

La selección es determinista y reproducible — el script está en el repo.

Es verdad que solo estamos comparando un lenguaje, pero, por desgracia, no tengo ni tokens infinitos ni tiempo infinito. Aun así, es algo que nos dará una visión muy interesante. Por otro lado, es el caso que más uso, además de IaC en Terraform para AWS, pero aquí Kiro podría tener cierta ventaja por su Hardness y ensuciaría esta comparativa.

El prompt

Idéntico para los tres. Literalmente el instructions.md del ejercicio, con un preámbulo mínimo:

Solve the following Python exercise.
Write your solution in `<fichero>.py`.
Do not modify `<fichero>_test.py`.
The tests are run with `python3 -m unittest <test_module>`.

Sin pistas, sin guía, sin contexto adicional. Lo mismo que si hicieses un test a alguien a quien quisieses contratar. Aquí estamos realizando las entrevistas de trabajo para mis asistentes de código.

El aislamiento

Cada herramienta se ejecutó desnuda: sin configuración personal, sin plugins, sin MCP, sin steering. Como si fuese mi primer día con cada asistente.

Nota: No os recomiendo que tengáis vuestros asistentes desnudos, ya que su rendimiento es peor, pero es verdad que es la forma más justa de compararlos.

Qué medimos

Integridad

Antes de cada ejecución verificamos que los tests fallen con el stub vacío (si no, el ejercicio no mide nada). Después verificamos que el fichero de test no ha sido modificado — un agente que toca los tests para que pasen no cuenta como solución.

Las tandas

En total son más de 390 ejecuciones (26 configuraciones × 15) entre tandas por defecto y tandas con esfuerzo igualado.

El torneo de calidad del código

Lo normal es que todos los asistentes resuelvan todos los ejercicios (pequeño spoiler: no ha sido así), pero no todos lo van a resolver de la misma forma, por lo que tenemos que medir la calidad del código; y para eso hay que buscar la forma más objetiva posible de hacerlo.

Y aquí había una solución bastante salomónica: que otros modelos juzgaran a ciegas las resoluciones de los ejercicios.

Torneo de jueces a ciegas (3 modelos que no compiten en el benchmark):

• Cada ejercicio se juzga con las soluciones anonimizadas (solucion-A, solucion-B…)
• 10 pasadas por juez con el orden barajado, para neutralizar el sesgo de posición
• 3 jueces independientes (glm-5, deepseek-3.2, minimax-m2.5) — Imparciales ya que ninguno es un modelo relacionado con los que juzgan
• Solo cuenta si hay mayoría clara; si los jueces discrepan, se reporta como tal

El torneo tiene dos partes: primero se enfrenta el mismo modelo en dos herramientas (¿quién escribe mejor código con el mismo modelo?) y después, una final entre los modelos más potentes de cada herramienta.

Nota: los modelos los ha ejecutado Kiro, ya que un cuarto asistente para este ejercicio me parecía excesivo y, además, al ser una revisión ciega, el Hardness no tiene tanta importancia.

Lo que puede medir cada asistente

No todos exponen las mismas métricas, y eso condiciona la comparativa:

Los tres proporcionan un coste estimado por ejercicio en $, por lo que se puede comparar cuánto cuesta resolver la misma tarea en cada herramienta. Ninguno es la factura real — son aproximaciones basadas en la rate card o en el SDK — pero los tres usan la misma lógica: el precio por token del modelo que están usando.

Lo que varía es la granularidad: Codex y Claude Code permiten ver cuánto se fue a caché o a razonamiento; Kiro da el coste total sin abrir la caja.

Cómo comparamos

La comparación se hace en tres ejes:

Mismo modelo, distinto hardness. El eje principal. Si ponemos gpt-5.6-terra en Kiro y en Codex con el mismo prompt, la diferencia que salga es pura herramienta: cómo construye el contexto, cuántas llamadas hace, cuánto cachea. No es una diferencia de modelo, sino de hardness.

Router automático vs elección manual. Kiro tiene auto a 1.00x. ¿Rinde igual que elegir un modelo concreto a mano? ¿Y a qué coste?

Esfuerzo igualado. Cada herramienta tiene un esfuerzo de razonamiento por defecto distinto. Para determinar cuánto pesa esa variable, se lanzan tandas adicionales con el esfuerzo igualado a high en Codex y en Kiro.

Los resultados

Todos resuelven… casi

Lo primero que sorprende es que tengamos 4 fallos:

Los cuatro fallos son todos de Claude Code y ninguno es de Opus ni de Sonnet:

• --model haiku falla tres: forth, scale-generator y transpose
• --model opusplan falla uno: relative-distance

Cuidado con no confundir opusplan con Opus: opusplan es la configuración de router de Claude Code, que planifica con Opus y ejecuta con Sonnet. Opus a secas pasó los 15 y Sonnet también.

Con los tests como único criterio, entonces, la conclusión es aburrida: estas herramientas resuelven ejercicios de Exercism sin dificultad, con casi cualquier modelo. Lo interesante no es si llegan, sino lo que gastan y cuánto tardan en llegar.

Aquí el problema es más el modelo: Haiku 4.5 es un modelo antiguo y poco potente. Salió hace casi un año, y ahora mismo un año es mucho para un modelo, más teniendo en cuenta que Sonnet ha tenido 2 versiones, Opus 3, y que los modelos de GPT son bastante nuevos.

Con el mismo modelo, Kiro va más rápido

Algo curioso de este ejercicio es la medición del tiempo. Wall clock, medido con reloj, sin interpretación posible.

Kiro es más rápido en 6 de los 7 modelos, con reducciones del 20% al 35%. El único empate es Opus (+2%, dentro del ruido). Y el detalle por modelo lo confirma: con Luna, Kiro gana 15 de 15. No es que la media sea más baja por un caso extremo — es que gana ejercicio a ejercicio.

Un caso extremo: Haiku en Kiro tarda 15,8 minutos — tres veces más que Sonnet — porque reintenta 20 veces los tests antes de acertar. Pero acierta los 15. En Claude Code, Haiku no reintenta y falla en 3 casos. El modelo es el mismo; la diferencia es que Kiro insiste y Claude Code se rinde. Esa insistencia tiene un coste: Haiku, con tarifa 0,4x, acaba gastando 6,46 credits frente a los 5,79 de Sonnet, con tarifa 1,3x. El modelo barato de base no siempre es el más eficiente, y menos aún si necesita varios reintentos.

Esto es algo que pasa cuando cotizamos un proyecto: en ciertas tareas, un perfil más junior puede acabar saliendo más caro porque necesita muchas más horas — igual que poner a un senior en tareas muy sencillas.

Lo que consume cada uno

Antes de medir, hay que confesar que medir el consumo es muy complicado. Las tres herramientas cuestan 20$/mes, pero no miden el consumo de la misma forma ni tienen límites temporales iguales:

Eso significa que un mismo porcentaje no tiene el mismo valor en cada herramienta. Cada una tiene un límite principal (semanal o mensual) y, además, Claude Code tiene un límite de ventana de 5 horas, que es el que te bloquea primero en trabajo intensivo.

Nota: Codex tenía una ventana de 5 horas similar, pero OpenAI la suspendió temporalmente el 12 de julio de 2026 cuando GPT-5.6 Sol fue lanzado. A fecha de este benchmark (agosto de 2026), sigue suspendida en los planes Plus, Pro y Business. Si la reactivan, Codex también tendría ese bloqueo adicional.

La siguiente tabla compara el coste por modelo para la ejecución de los ejercicios: el consumo del plan semanal (Kiro está prorrateado a 1 semana), el % del límite que se alcanzaría en una semana (para Kiro es mensual) y el % del límite que se alcanzaría en 5 horas.

Codex es más barato por tarea con los GPT-5.6. Con un uso uniforme repartido a lo largo del mes, Codex ofrece entre 2,4x y 3,3x más capacidad. Pero si concentras el trabajo en pocos días, su ventana semanal se parece al límite mensual de Kiro. A su favor: la ventana de 5 horas está suspendida, así que hoy el único muro de Codex es el semanal.

Este resultado es sorprendente porque el coste es mucho más bajo, y aquí es donde vemos que Kiro emplea un esfuerzo distinto, lo cual revisaremos en el siguiente punto.

Con los modelos de Claude, el precio por tarea es similar — a primera vista puede parecer que Claude Code gana, pero tenemos que tener en cuenta los límites semanales y de 5 horas. Llegas al límite mucho antes en Claude Code, y el primer límite no es el semanal, sino el de 5 horas. Con Opus este test lo podemos lanzar dos veces y ahí se acaba la sesión: cada tanda se come el 47%, así que las dos suman el 94% y la tercera ya no entra.

Esto es un tema interesante, porque si puedes esperar y eres paciente, vas a poder continuar, pero en caso de algo crítico lo normal es subir de tier, aunque no lo necesites el resto del mes.

El router de Kiro es la única victoria clara en coste: 0,37% del mes frente al 2,20% de la semana de opusplan. Y además termina antes.

El esfuerzo de razonamiento no es neutral

Hemos visto en la comparativa que algo raro pasaba con Kiro: los modelos GPT salían excesivamente caros. Investigándolo, descubrimos que el esfuerzo por defecto en Kiro es diferente:

• Codex: Sol va a low, Terra y Luna a medium
• Claude Code: todos a high
• Kiro: GPT-5.6 a high (documentado), Claude a high

Es decir: Kiro y Claude Code ya corren a high por defecto, mientras que Codex va más bajo. Esa asimetría afecta directamente al consumo — un modelo que razona menos gasta menos tokens por tarea.

Para medirlo, tenemos que hacer una nueva prueba con las tandas de Codex forzadas a high:

El gap de coste entre Codex y Kiro se reduce con el esfuerzo igualado. Con Sol en default (low), Codex consume el 1,34% frente al 4,42% de Kiro (3,3x). Con ambos en high, pasa al 2,07% frente al 4,42% (2,1x). Parte de la ventaja de Codex se debía a que su Sol corre a low por defecto.

Pero si la comparación la hacemos contra el límite real de cada uno — la semana de Codex frente al mes de Kiro — el dato empeora para Codex: consume el 2,07% de su semana mientras Kiro se lleva el 1,10% de su mes.

El caso de Sol es el más llamativo: subir de low a high le cuesta a Codex un 55% más de consumo y un 59% más de tiempo.

Detalle por ejercicio

Para quien quiera ver el desglose completo:

Lo que se observa al comparar Cx-Sol (1,34%) con Cx-So-H (2,07%) es que el mismo modelo gasta un 55% más al aumentar el esfuerzo. Y comparando Cx-So-H (2,07%) con K-Sol (4,42%): incluso igualando a high, Kiro sigue siendo 2,1x más caro con Sol. La diferencia ya no es el esfuerzo — es la estructura de costes del plan.

Nota sobre los precios de GPT-5.6 en Bedrock: a finales de julio de 2026, los precios bajaron significativamente — Luna un 80%, Terra un 20% y Sol un 20%. Si Kiro traslada esa reducción a sus multiplicadores de crédito — que a fecha de este benchmark (agosto 2026) no lo ha hecho — el coste de Kiro con GPT podria ser mas bajo.

Calidad del código

Que un ejercicio pase los tests no dice nada sobre si el código es bueno. Para medirlo, un torneo a ciegas: 3 jueces independientes (glm-5, deepseek-3.2, minimax-m2.5) que no participan en el benchmark puntúan las soluciones anonimizadas en 10 pasadas, en orden aleatorio. Solo cuenta si hay una mayoría clara de 2 de los 3 jueces.

Duelos directos: mismo modelo, distinta herramienta

Cada duelo enfrenta las soluciones del mismo ejercicio, con el mismo modelo, producidas por dos herramientas distintas. La pregunta es: ¿quién escribe mejor código con el mismo modelo?

Con esfuerzo por defecto:

Con esfuerzo igualado a high:

En el modo por defecto de cada herramienta, Kiro gana en los modelos potentes (Sol 11-4, Opus 10-5) y empata o pierde ligeramente en los menos potentes (Luna 6-8, Haiku 5-6). El patrón es claro: cuanto más capaz es el modelo, más partido le saca Kiro.

Pero recordemos que el esfuerzo en Codex era distinto: Kiro corre a high por defecto y Codex no. Al igualar a high:

• Luna se invierte: Kiro pasa de perder 6-8 a ganar 9-4. El hardness de Kiro saca más partido a Luna cuando ambos se esfuerzan igual.
• Terra empata: 7-7. Sin diferencia medible.
• Sol se invierte: Codex pasa de perder 4-11 a ganar 8-6. Cuando Sol razona a fondo en Codex, su hardness produce mejor código, aunque el resultado es similar.

No hay un ganador universal claro en calidad. Cada herramienta saca más partido de un perfil de modelo distinto. Y, además, los resultados son similares.

Totales

Comparación justa por enfrentamiento directo (mismo modelo, distinta herramienta):

Kiro gana en los tres cruces, pero ninguno es un dominio aplastante. Con esfuerzo igualado (la fila de high), la diferencia se reduce — Codex se acerca a 22-19.

La final: el mejor de cada herramienta

La última fase enfrenta directamente al mejor modelo de cada herramienta: Kiro con Opus 5, Codex con Sol a esfuerzo high, Claude Code con Opus 5 y Kiro Auto (el router). Cuatro soluciones por ejercicio, mismo prompt, mismos tests — pura diferencia de hardness.

Con consenso (5/15): Kiro Opus 3, CC Opus 2, Codex Sol 0, Kiro Auto 0.

Lo que quiere decir que Kiro Opus gana por poco, pero no de forma abrumadora. Es más: si miramos las medias por ejercicio, el resultado es similar:

Los tres modelos potentes están cerca — 0,39 puntos separan al primero del tercero en una escala de 5. La diferencia entre Kiro y Claude Code con el mismo modelo (Opus) es de 0,12: algo mínimo. Codex Sol queda un escalón por debajo, pero sigue produciendo código de calidad 4/5.

El router auto de Kiro (3,25) confirma lo que cabía esperar: un router que elige modelos baratos para tareas que considera sencillas no puede competir en calidad absoluta con un modelo top razonando a fondo. Pero resuelve los 15 de 15 en 5,8 minutos gastando 3,72 credits — ahí la relación calidad/precio es otra historia.

Detalle de los jueces por ejercicio

Conclusiones

Es curioso porque el resultado me ha sorprendido, en general me ha sorprendido el precio/rendimiento de Codex, pensaba que iba a estar más lejos y la igualdad en calidad de los 3, pero sobre todo que Kiro fuese hasta mejor, esperaba que Claude Code fuese el más potente.

A nivel objetivo es difícil dar un ganador absoluto, pero hay algunas cosas que, a mi modo de ver, dan la victoria a Kiro y probablemente a Codex como segundo en esta revisión (Si Codex vuelve a implementar la ventana de 5 horas empeoraría mi visión).

Claude Code es muy potente, pero a mi modo de ver el límite de 5 horas es un problema, si ejecutas una tarea y llegas a ese límite, lo normal es tener que subir a un plan superior, por lo que su coste real se dispara, esto mismo le pasaba a Codex, pero al eliminar (No sabemos si temporalmente) su ventana de 5 horas, el problema se traslada a la semana, mientras que en Kiro este problema es mensual, lo que lo hace más llevadero.

Sé que esto puede ser lo más controvertido, ya que en un plan mensual sin llegar a los límites Kiro sale perdiendo, pero en el mundo real trabajando con fechas de entrega, picos de trabajo y bastante estrés llegar a los límites de cualquier plan es normal y este modelo de límites temporales de 5 horas y semanales se aprovecha de eso, de que una vez hemos empezado probablemente no nos quede otra opción que subir de Tier.

Por otro lado, Kiro tiene una ventaja que Codex y Claude Code no tienen: dispone de los modelos del otro. es cierto que por ejemplo falta Fable en Claude Code, pero a no ser que tu requisito sea usar Fable no es un problema.

Hay una cosa en la que Kiro no puede competir y es que no permite crear imágenes o PPTs directamente, pero en mi caso es algo salvable con otras herramientas, de hecho prefiero esto que las PPTs clónicas que veo últimamente.

Así que sí podemos decir que Kiro es más eficiente durante el mes completo y más si usamos el modelo auto.

De todos modos, esto no es una verdad grabada en piedra: cada uno tiene sus preferencias. La mía está clara y es Kiro. ¿Cuál es la tuya?

Para reproducirlo

Todo el código está en el repositorio: coding-agents-benchmark.

No hace falta creerse ningún número a ciegas. Los scripts son agnósticos a la herramienta — reciben el comando por plantilla — así que puedes añadir el asistente que quieras, o repetirlo con otros modelos y otro lenguaje.

Preparar los ejercicios:

1
2

./stage-exercises.py --lang python
./check-baseline.sh          # verifica que los tests fallan con el stub vacío

Lanzar una tanda (15 ejercicios con verificación incluida):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Kiro, con HOME aislado para que no herede configuración personal
KA='./kiro-aislado.sh --no-interactive --agent benchmark'
./tanda.py --agente kiro-sonnet5 --cmd "$KA --model claude-sonnet-5 {prompt}"

# Codex
./tanda.py --agente codex-terra \
    --cmd 'codex exec --json -s workspace-write -m gpt-5.6-terra {prompt}'

# Claude Code
CC='claude -p {prompt} --output-format json --permission-mode acceptEdits --safe-mode'
./tanda.py --agente cc-sonnet --cmd "$CC --model sonnet"

tanda.py es reanudable: si un run ya está completo, lo salta, así que puedes cortar y seguir cuando el plan se recupere. Y verificar.sh comprueba el checksum del fichero de test después de cada ejecución — si el agente lo ha tocado, el run se marca como manipulado y no se cuenta.

El torneo de calidad:

1
2
3

./torneo.py --parejas          # ver qué duelos son posibles con los datos que hay
./torneo.py --fase1            # duelos del mismo modelo en dos herramientas
./juez.py --todos --panel      # panel de 3 jueces sobre un directorio preparado

Lo que hay que declarar si lo repites: los porcentajes de plan salen de leer el /status de cada herramienta, que redondea al entero — eso deja una banda de error de entre el ±7% y el ±20% según el caso. Los credits de Kiro sí son exactos: la suma de los 150 logs coincide con lo que reporta la cuenta hasta el segundo decimal.