La reducción del coste de Kiro del 82 % con GPT-5.6 Terra necesita un denominador mayor

OpenAI afirma que GPT-5.6 Terra completó tareas exitosas de Terminal-Bench 2.1 en Kiro con un coste aproximadamente un 82 % menor. Es un resultado útil de un modelo, un entorno de agente y un benchmark concretos. No demuestra que un equipo de ingeniería vaya a gastar un 82 % menos para fusionar cambios fiables en sus propios repositorios.

El puente que falta es el trabajo alrededor de la llamada al modelo. Un agente de programación puede consumir menos créditos y aun así crear un trabajo más caro si los mantenedores tienen que reparar su parche, volver a ejecutar un ciclo de pruebas inestable, deshacer un diff sobredimensionado o revertir un cambio después del despliegue. La métrica de decisión debería ser el coste total por cambio completado que supera un umbral fijo de aceptación de ingeniería, no solo los créditos, los tokens o las líneas de código generadas.

Ninguna de las dos empresas ha publicado en el anuncio suficientes detalles a nivel de tarea para reconstruir de forma independiente la cifra del 82 %.

El resultado del 82 % es más estrecho de lo que sugiere el anuncio

El anuncio de socios de OpenAI del 24 de agosto dice que Sol, Terra y Luna pueden utilizarse en los flujos de planificación, implementación, revisión y pruebas de Kiro. Atribuye el resultado de coste a las pruebas de OpenAI y AWS: GPT-5.6 Terra completó tareas exitosas de Terminal-Bench 2.1 en Kiro con un coste aproximadamente un 82 % menor.

El anuncio no menciona la línea base de comparación, el número de ensayos, la versión de Kiro, la configuración del modelo, el tiempo de espera, la política de reintentos, los costes por tarea ni si la cifra incluye los ensayos fallidos. Tampoco publica trayectorias que mostrarían qué comandos se ejecutaron o cuántas correcciones hizo el agente. Sin esos detalles, el porcentaje es un resultado del arnés comunicado por el proveedor, no una previsión reutilizable.

La disponibilidad también es anterior a la publicación de socios. El registro de cambios del lanzamiento de Kiro fecha el primer despliegue de GPT-5.6 el 14 de julio. Una actualización del 31 de julio redujo después el multiplicador de créditos de Kiro de Terra de 1,2x a 1,0x y el de Luna de 0,6x a 0,1x, mientras Sol se mantuvo en 2,4x. Por tanto, el artículo de OpenAI de agosto añade una afirmación de rendimiento y un marco de asociación; no marca el primer día en que los clientes de Kiro pudieron seleccionar los modelos.

El benchmark en sí es útil, pero acotado. El repositorio de Terminal-Bench 2.1 describe 89 tareas ejecutadas en entornos de contenedores, incluidas tareas de depuración, seguridad, ciencia y sistemas. Los envíos a la clasificación pública deben ejecutar al menos cinco ensayos por tarea y subir los datos de su trabajo. Terminal-Bench 2.1 también modificó tareas de la versión 2.0 para corregir errores, tiempos de espera, restricciones de recursos y debilidades de reward hacking.

Eso lo convierte en una prueba seria para agentes de terminal. No representa la base de código privada, el estándar de revisión, la ruta de despliegue ni el coste de mantenimiento de un equipo. El modelo, el arnés de Kiro, el contenedor de la tarea, las pruebas de aceptación y el presupuesto de reintentos producen conjuntamente el resultado. Ganar un benchmark no puede aislar el modelo como causa, y mucho menos garantizar un ahorro del 82 % en otro lugar.

Los créditos de Kiro ponen precio a la actividad, no al trabajo de ingeniería aceptado

La documentación actual de modelos de Kiro enumera las tres variantes de GPT-5.6 con una ventana de contexto de 272.000 tokens. Sus multiplicadores de créditos son relativos a Auto, la opción de enrutamiento predeterminada de Kiro:

Opción de Kiro	Multiplicador actual	Acceso documentado	Primera hipótesis razonable, no una conclusión
GPT-5.6 Luna	0,1x	Planes de pago	Tareas frecuentes y acotadas en las que importan los intentos baratos y la respuesta rápida
GPT-5.6 Terra	1,0x	Planes de pago	Cambios rutinarios de varios pasos que necesitan un equilibrio entre capacidad y uso de créditos
GPT-5.6 Sol	2,4x	Planes de pago	Planificación más difícil o trabajo de horizonte largo en el que menos intentos fallidos pueden compensar un multiplicador mayor
Auto	1,0x	Todos los planes	Línea base práctica del producto, pero el enrutamiento subyacente puede cambiar entre ejecuciones

Son multiplicadores relativos al producto, no precios de tokens de API. La misma documentación dice que una tarea que consume 10 créditos en Auto consumiría 24 con Sol, 10 con Terra o 1 con Luna. También dice que las solicitudes de GPT-5.6 se sirven desde Estados Unidos con independencia de la región del perfil de Kiro. Esa condición sobre la ubicación de los datos puede descartar la familia para algunos repositorios antes de considerar el coste.

La página de precios de Kiro enumera actualmente planes desde Pro, a 20 $por 1.000 créditos, hasta Power, a 200$ por 10.000 créditos, con créditos adicionales a 0,04 $ cada uno. Los créditos incluidos y el gasto marginal en créditos adicionales responden a preguntas presupuestarias distintas. Un equipo que ya paga por capacidad no utilizada puede no ver un cargo inmediato en efectivo por una prueba, pero el trabajo sigue consumiendo capacidad escasa del plan y puede provocar un exceso más adelante.

Un análisis independiente de Fathom dirige correctamente a los lectores hacia el tiempo de revisión, las pruebas fallidas, las correcciones posteriores y el gasto total en modelos. Sin embargo, no informa de un experimento independiente con Kiro. Su aportación es un marco de medición útil, no una corroboración del resultado del 82 %.

«Cambio completado» es el denominador que falta

Empieza con un único umbral binario que todos los candidatos deban superar. Un cambio cuenta como completado solo cuando se cumplen todas las condiciones necesarias:

• el comportamiento declarado en la tarea está presente;
• pasan las pruebas objetivo y el conjunto completo de pruebas congelado;
• pasan los linters, las comprobaciones de tipos y seguridad y los pasos de compilación requeridos por el repositorio;
• el diff se mantiene dentro del alcance declarado de la tarea y evita archivos protegidos;
• un revisor lo acepta dentro del presupuesto fijo de tiempo de corrección;
• no aparece ninguna regresión introducida por el agente durante la ventana de observación elegida; y
• el cambio no requiere una reversión ni un seguimiento urgente.

Usa una ventana de observación más corta para dispositivos de bajo riesgo y una más larga para pruebas de producción, pero mantenla idéntica entre candidatos. Un resultado puede seguir siendo «aceptado provisionalmente» hasta que se cierre la ventana. Así se evita puntuar como éxito una fusión rápida seguida de una reversión costosa.

No pidas a un único revisor que decida si un parche «tiene buena pinta». Escribe reglas observables para cada tarea. Una actualización de dependencias podría exigir que el archivo de bloqueo contenga una versión concreta, que el análisis de vulnerabilidades se mantenga en el nivel de la línea base o por debajo, que pasen todas las pruebas y que no cambie ningún paquete ajeno. Una reparación de errores podría exigir que pase una prueba que fallaba antes sin eliminarla ni debilitarla.

Un mismo flujo de Kiro puede producir tres experimentos distintos

Selecciona entre 20 y 40 tareas de trabajo reciente y representativo. Incluye el mantenimiento ordinario y también los fallos que consumen un tiempo de revisión desproporcionado. Cuatro clases útiles son pequeñas correcciones de errores, funciones que abarcan varios archivos, cambios de dependencias o configuración y refactorizaciones guiadas por pruebas.

Compara primero la opción actual de Kiro del equipo con un candidato GPT-5.6. Mantén constantes la versión de Kiro, el commit del repositorio, el prompt de la tarea, los documentos de especificación, las reglas de orientación, los permisos, las herramientas, el tiempo de espera, el máximo de pasos del agente, la política de reintentos, el entorno de pruebas y el evaluador de aceptación. Si la primera comparación justifica otro nivel, añádelo en una segunda ronda. Cambiar a la vez el modelo, el prompt, los permisos y la descomposición de la tarea produce un piloto de producto, no una comparación de modelos.

Alterna el orden de las ejecuciones para que una ralentización del proveedor o una interrupción del servicio del repositorio no afecte solo a un candidato. Mantén los intentos fallidos en el denominador. Si interviene una persona, registra los minutos y el tipo de corrección en vez de convertir silenciosamente un intento fallido en aprobado.

Medida	Registrar para cada candidato	Por qué cambia la decisión
Cambios aceptados	Recuento bruto y total intentado	Proporciona el denominador; un porcentaje sin recuentos oculta la incertidumbre
Créditos de Kiro	Total y por cambio intentado	Muestra el consumo del producto con el multiplicador actual
Tiempo transcurrido del agente	Mediana y p95 desde el inicio hasta el parche enviado	Expone las colas lentas ocultas por las medias
Revisión y reparación	Minutos humanos, rondas de revisión, cambios solicitados	Convierte el trabajo de los mantenedores en parte del coste
Fallos de validación	Pruebas objetivo fallidas, regresiones del conjunto completo y fallos de lint/tipos/seguridad	Separa una salida pulida de la aptitud del repositorio
Fallos de alcance	Archivos no solicitados, deriva de dependencias, pruebas eliminadas y ediciones de rutas protegidas	Captura riesgos que una puntuación de éxito de la tarea puede omitir
Fallos operativos	Reversiones, rollbacks, incidentes y seguimientos urgentes	Evita que una fusión rápida parezca más barata que un cambio estable

Nuestro análisis del nivel de razonamiento de Gemini (en español) muestra cómo interactúan el precio de la llamada al modelo, los reintentos y los costes de fallback cuando se conocen las tarifas de tokens del proveedor. En Kiro, los créditos son la medida nativa del producto. El análisis de la retirada de modelos de GitHub Copilot (en español) muestra por qué el modelo nombrado puede cambiar más rápido que el producto que lo rodea.

El coste solo aparece cuando se cierra la ventana de observación

Usa la tarifa laboral imputada por la organización para la revisión y la reparación. Añade el precio marginal de los créditos de Kiro consumidos, la computación de CI o sandbox y cualquier gasto medido de reversión o incidente. Si para una decisión tratas los créditos incluidos en la suscripción como un coste en efectivo cero, comunica el resultado dos veces: una con gasto marginal cero en créditos y otra con la tarifa actual de créditos adicionales. Así queda visible el supuesto de capacidad.

total evaluated cost =
  Kiro credit expense
  + CI and sandbox expense
  + reviewer and repair minutes × loaded cost per minute
  + measured rollback and incident expense

cost per completed change =
  total evaluated cost / changes that cleared the full acceptance gate

Nunca dividas entre cambios aceptados cuando el recuento sea cero. Informa de que el candidato no superó el umbral, junto con el gasto total y las categorías de fallo. Un infinito numérico es impecable desde el punto de vista matemático y poco útil operativamente.

El mejor resultado podría ser una política de enrutamiento y no un único valor predeterminado. Luna puede ganar en cambios pequeños y bien probados mientras Terra gana en trabajos que abarcan varios archivos; Sol quizá solo sea económico cuando una tarea más difícil requeriría de otro modo varios intentos fallidos. Auto puede seguir siendo útil para el trabajo general, pero su ruta cambiante lo convierte en una línea base experimental más débil cuando importa la reproducibilidad exacta del modelo.

La cifra del 82 % da a GPT-5.6 Terra un lugar en un piloto controlado de Kiro. No resuelve la decisión de contratación ni la del modelo predeterminado. Esa decisión solo está completa cuando un equipo puede señalar parches aceptados, ejecuciones fallidas, minutos de revisión, consumo de créditos y evidencia de reversión de los mismos repositorios bajo el mismo umbral.

Fuentes

1. OpenAI: Advancing price-performance for developers with GPT-5.6 in Kiro
2. Kiro models and current credit multipliers
3. Kiro GPT-5.6 launch changelog
4. Kiro GPT-5.6 Terra and Luna credit multiplier update
5. Kiro pricing and included credits
6. Terminal-Bench 2.1 repository and submission protocol
7. Fathom analysis of GPT-5.6 in Kiro