Genera pruebas de API con GPT-6 Luna: cuánto cuesta realmente una especificación OpenAPI completa

Generar pruebas a partir de una especificación OpenAPI dejó de ser un problema técnico hace tiempo. Los modelos capaces de leer un path item y emitir una petición plausible existen desde hace dos años. El problema era la factura. La generación de pruebas costaba lo suficiente por ejecución como para que los equipos la trataran como una migración puntual: generar una suite una vez, confirmarla en el repositorio y luego mantenerla a mano para siempre, porque regenerarla en cada cambio de la especificación habría aparecido como una partida que alguien cuestionaría.

GPT-6 Luna, anunciado el 22 de septiembre de 2026 a $0.10 por millón de tokens de entrada y $0.50 por millón de salida, traslada la tarea al otro lado de esa línea. Una pasada completa sobre una especificación de 42 endpoints sale por unos $0.29 sin caché y por menos de $0.10 con ella. Eso es lo bastante barato como para dejar de mantener una suite generada y simplemente regenerarla en cada merge.

Aquí están la aritmética, la forma de la petición, la latencia con la que hay que contar y las dos cosas que el modelo todavía hace mal.

El precio que se movió

GPT-6 Luna es un modelo nuevo de la familia GPT-6, no un GPT-5.6 renombrado de un nivel inferior. OpenAI dice que Sol y Luna se entrenaron con métodos similares a los de GPT-6 Astra, y que ambos son un 50% más baratos que el precio promocional de GPT-5.6. Ese matiz es de la propia OpenAI y es importante: la comparación es contra una tarifa promocional, no contra una tarifa de lista. El linaje completo está en nuestro resumen de la guerra de precios de modelos de IA.

Para esta tarea, la ventana de contexto importa más que el precio de titular. Un millón de tokens significa que toda la especificación, las convenciones de pruebas de tu casa y un conjunto de peticiones de ejemplo caben en un solo prompt con espacio de sobra. No estás troceando, y no estás escribiendo lógica de recuperación para averiguar de qué esquemas depende una operación. Más sobre el modelo en qué es GPT-6 Luna.

Da forma a la tarea antes de ponerle precio

Dos formas, costes muy distintos.

La versión de un solo disparo pone toda la especificación en contexto y pide toda la suite en una única completion. Más barata en entrada, peor en salida: una completion que abarca 42 operaciones se diluye mucho hacia la vigésima, donde los primeros endpoints reciben cinco casos cada uno y la cola recibe un camino feliz y un encogimiento de hombros. Además, hay una sola unidad de reintento para toda la ejecución.

La versión por operación envía el contexto compartido de la especificación más una operación, 42 veces. La entrada sube porque el contexto compartido se repite, pero la calidad de la salida se mantiene, cada llamada se puede reintentar de forma independiente y cada archivo produce un diff limpio respecto a la ejecución anterior. El almacenamiento en caché recupera la mayor parte del coste de entrada adicional, lo que convierte esta en la forma a la que poner precio.

Presupuesta una llamada, usando una especificación de tamaño medio:

Las dos primeras filas son idénticas byte a byte en cada llamada. Ese prefijo de 52.000 tokens es sobre lo que actúa el caché, y poner primero el material invariante es la decisión de mayor impacto en toda la configuración.

Cuánto cuesta una pasada

Con 42 operaciones con ese presupuesto, la ejecución llega a 2.247.000 tokens de entrada y 126.000 tokens de salida.

A las tarifas de Luna eso son $0.2247 de entrada y $0.0630 de salida, así que $0.2877 por la pasada, un poco por debajo de siete décimas de céntimo por endpoint. El mismo perfil de tokens contra los otros modelos que se lanzaron o cambiaron de precio en la misma quincena:

Astra es exactamente 100 veces la tarifa de Luna tanto en entrada como en salida, así que cuesta exactamente 100 veces más en esta tarea. Claude Opus 5.5 es 40 veces más.

Esa diferencia es toda la decisión. A $28.77 la pasada, construyes lógica incremental: rastrear qué operaciones cambiaron, hacer un hash de cada path item, regenerar solo el diff y luego depurar esa maquinaria cuando se desincroniza con la especificación. A $0.29 eliminas la lógica incremental. Veinte merges al mes son $5.75, menos que los minutos de CI empleados en ejecutar las pruebas que escribió el modelo. Como referencia de escala, OpenAI informa de que su investigador mediano gasta más de $600 al día en agentes de programación, con el percentil 90 por encima de $7.000.

Hasta dónde lo lleva el almacenamiento en caché de prompts

GPT-6 trajo un lanzamiento real de caché junto con el cambio de precio: un 90% de descuento en lecturas de entrada en caché, tasas de acierto más altas por defecto, un panel y una herramienta de diagnóstico, puntos de interrupción explícitos para que tú elijas dónde termina el prefijo almacenado en caché, y supervivencia de la caché ante cambios en el esfuerzo de razonamiento y la disponibilidad de herramientas. GitHub informó de más de un 50% menos de tokens de prompt que necesitaban procesamiento nuevo en miles de millones de peticiones. Los detalles están en almacenamiento en caché de prompts de GPT-6.

Aplicado a la ejecución anterior, quitando un 90% a la tarifa de entrada de $0.10, es decir, $0.01 por millón para lecturas en caché:

Alrededor de un tercio del coste sin caché, un pelín por debajo de un cuarto de céntimo por endpoint. Dos cosas que no hay que dar por sentadas. OpenAI indica el descuento del 90% pero no, en nuestras fuentes, publica una tarifa en dólares de lectura en caché para Luna, así que el $0.01 de arriba es aritmética, no una tarifa publicada. Y nada de lo que tenemos cita una vida útil del caché, así que dispara las 42 llamadas seguidas en lugar de repartirlas por una cola de CI lenta, y confirma la tasa de acierto en el panel.

La petición

Nada exótico. El orden es lo que se gana el sueldo:

curl https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-luna",
    "reasoning_effort": "high",
    "messages": [
      { "role": "system",
        "content": "You write API tests. Emit one test file. Assert on status, response schema and error shape. Never assert on a field absent from the supplied schema." },
      { "role": "user",
        "content": "Shared spec context:\n<components, securitySchemes, servers>" },
      { "role": "user",
        "content": "Operation under test:\nPOST /orders\n<path item and examples>" }
    ]
  }'

El prompt de sistema y el bloque de especificación compartida son idénticos byte a byte en las 42 llamadas y van primero. La operación varía y va al final. Intercambia los dos y no almacenas nada en caché, así que la ejecución cuesta $0.29 en lugar de $0.096. Esa es toda la mecánica.

El ajuste de esfuerzo high es deliberado. Las mejoras publicadas de Luna sobre su predecesor se miden con un esfuerzo mayor, y como el caché de GPT-6 sobrevive a un cambio de esfuerzo, puedes ajustarlo por operación sin reconstruir el prefijo. Reserva los ajustes más altos para endpoints que manejen dinero o autenticación.

Presupuesta tiempo, no dinero

Barato no es rápido. Artificial Analysis, un tercero, mide la variante de razonamiento máximo de Luna en 153,9 tokens de salida por segundo con un tiempo hasta el primer token de 124,23 segundos. Ambas cifras son suyas, no de OpenAI, ambas se aplican específicamente a la variante máxima, y AA vuelve a puntuar continuamente, así que trátalas como orientativas.

Tomadas al pie de la letra, una llamada con esfuerzo máximo es aproximadamente 124 segundos de espera más unos 20 segundos para transmitir 3.000 tokens, pongamos 144 segundos. Cuarenta y dos en secuencia son unos 101 minutos. Ocho en paralelo son unos 13 minutos, una etapa de CI corriente.

Esto corta en la dirección opuesta a la mayoría de los argumentos de selección de modelos, que es por lo que el emparejamiento funciona: el tiempo hasta el primer token es un desastre para un asistente interactivo y casi irrelevante para un trabajo por lotes que escribe archivos. El mismo equilibrio con el hermano mayor en el tiempo hasta el primer token de GPT-6 Sol.

Lo que hace bien, y las dos cosas que no

Los resultados publicados por OpenAI para Luna son más fuertes de lo que sugiere el precio. En DeepSWE 1.1 alcanza un 66,6% con esfuerzo máximo, lo que OpenAI pone a la par de Claude Opus 5 y Fable 5 con esfuerzo medio, costando un 93% menos por tarea que Opus 5 y un 96% menos que Fable 5. En AutomationBench supera a su predecesor en 5,4 puntos porcentuales con un 58% menos de coste por tarea. Todos son ejecuciones de OpenAI sobre harnesses de OpenAI, y ninguno mide la generación de pruebas a partir de una especificación.

Dos modos de fallo importan aquí más que cualquier benchmark.

El modelo solo puede probar lo que dice la especificación. Si tu especificación documenta un 200 y un 400 para POST /orders pero el servicio también devuelve 409 ante una clave de idempotencia duplicada, no obtienes ninguna prueba de conflicto y la suite sigue pareciendo completa. La calidad de la generación está limitada por la calidad de la especificación, lo que convierte la especificación en el artefacto en el que merece la pena invertir, no el prompt.

La generación barata falla pareciendo correcta. El error característico no es una prueba rota, sino una prueba que pasa y que verifica un campo que la respuesta nunca contiene, o un código de estado que el endpoint nunca emite. Esos pasan la revisión porque se leen como pruebas. Valida cada aserción generada contra el esquema de forma mecánica antes de que entre, rechazando cualquiera que haga referencia a un campo ausente de components. Esa comprobación no cuesta nada y mata la clase entera.

Hacer que la salida sea ejecutable

Los archivos de pruebas generados valen exactamente tanto como el harness en el que se ejecutan. Mantén la especificación como fuente de verdad, genera contra ella y luego lleva los casos a algún sitio donde se ejecuten en cada push.

Apidog cubre la segunda mitad de ese bucle. Importa la especificación desde la que estás generando, así que el contexto compartido de tu prompt y las definiciones de peticiones de tu runner provienen de un único documento y no pueden divergir. Los casos generados se convierten en escenarios de prueba cuyas aserciones se validan contra el esquema importado, lo que convierte la comprobación anterior en una puerta mecánica en lugar de una tarea de revisión. Smart mock sirve la especificación mientras el backend todavía se está escribiendo, así que una suite generada puede fallar con honestidad antes de que haya algo real contra lo que golpear. Y los escenarios se ejecutan en CI, el único lugar donde un flujo de trabajo de regenerar en cada merge rentabiliza.

¿Merece la pena enrutar esto a Luna?

Sí, con una advertencia. El coste ya no es una razón para saltárselo: $0.29 la pasada, o menos de $0.10 con caché, es menos que la reunión en la que debatís si regenerar. La latencia es real, pero cae en una ventana en la que nadie está esperando. Y los resultados publicados de Luna lo sitúan cerca de modelos que cuestan entre 40 y 100 veces más en trabajo de programación agéntica.

Nada de eso hace que la salida sea fiable al llegar. Gasta lo que te has ahorrado en una puerta de validación de esquema y en una lectura humana de la primera ejecución, y trata el resultado como un primer borrador que cubre por completo la superficie documentada y no cubre en absoluto la no documentada. Aun así, es un punto de partida mejor que la suite escrita a mano que dejó de seguir la especificación hace cuatro versiones.