Générer des tests API avec GPT-6 Luna : le coût réel d’une spécification OpenAPI complète

Générer des tests à partir d'une spec OpenAPI n'est plus un problème technique depuis un moment. Les modèles capables de lire un path item et de produire une requête plausible existent depuis deux ans. Le problème, c'était la facture. La génération de tests coûtait assez cher par exécution pour que les équipes la traitent comme une migration ponctuelle : générer une suite une fois, la committer, puis la maintenir à la main pour toujours, parce que régénérer à chaque modification de la spec aurait fait apparaître une ligne budgétaire sur laquelle quelqu'un aurait posé des questions.

GPT-6 Luna, annoncé le 22 septembre 2026 à 0,10 $ par million de tokens d'entrée et 0,50 $ par million de tokens de sortie, fait basculer la tâche de l'autre côté de cette ligne. Une passe complète sur une spec de 42 endpoints revient à environ 0,29 $ sans cache et à moins de 0,10 $ avec. C'est assez bon marché pour arrêter de maintenir une suite générée et simplement la régénérer à chaque merge.

Voici le calcul, la forme de la requête, la latence à anticiper, et les deux choses que le modèle rate encore.

Le prix qui a changé

GPT-6 Luna est un nouveau modèle de la famille GPT-6, pas un palier GPT-5.6 rebaptisé. OpenAI indique que Sol et Luna ont été entraînés avec des méthodes similaires à GPT-6 Astra, et que les deux sont 50 % moins chers que les tarifs promotionnels de GPT-5.6. Cette nuance est d'OpenAI lui-même et elle compte : la comparaison se fait par rapport à un tarif promotionnel, pas à un tarif catalogue. La généalogie complète dans notre récapitulatif de la guerre des prix des modèles d'IA.

Pour cette tâche, la fenêtre de contexte compte plus que le prix affiché. Un million de tokens signifie que toute la spec, vos conventions de test maison et un jeu de requêtes d'exemple tiennent dans un seul prompt, avec de la marge. Vous ne découpez pas en morceaux, et vous n'écrivez pas de logique de récupération pour déterminer de quels schémas dépend une opération. Plus de détails sur le modèle dans qu'est-ce que GPT-6 Luna.

Cadrez la tâche avant de la chiffrer

Deux formes, des coûts très différents.

La version en un seul coup place toute la spec en contexte et demande toute la suite en une seule complétion. Moins cher en entrée, pire en sortie : une complétion couvrant 42 opérations s'appauvrit gravement dès la vingtième, où les premiers endpoints reçoivent cinq cas chacun et la fin se contente d'un happy path et d'un haussement d'épaules. Une seule unité de reprise pour toute l'exécution, aussi.

La version par opération envoie le contexte de spec partagé plus une opération, 42 fois. L'entrée augmente parce que le contexte partagé se répète, mais la qualité de sortie tient, chaque appel peut être repris indépendamment, et chaque fichier produit un diff propre par rapport à l'exécution précédente. Le cache récupère l'essentiel du surcoût d'entrée, ce qui en fait la forme à chiffrer.

Budget pour un appel, avec une spec de taille moyenne :

Les deux premières lignes sont identiques octet pour octet à chaque appel. C'est sur ce préfixe de 52 000 tokens que le cache agit, et placer le matériel invariant en premier est la décision la plus déterminante de la mise en place.

Ce que coûte une passe

Avec 42 opérations à ce budget, l'exécution totalise 2 247 000 tokens d'entrée et 126 000 tokens de sortie.

Aux tarifs de Luna, cela représente 0,2247 $ d'entrée et 0,0630 $ de sortie, soit 0,2877 $ pour la passe, un peu moins de sept dixièmes de centime par endpoint. Le même profil de tokens face aux autres modèles sortis ou réévalués dans la même quinzaine :

Astra est exactement 100 fois le tarif de Luna en entrée comme en sortie, il coûte donc exactement 100 fois plus cher sur cette tâche. Claude Opus 5.5, c'est 40 fois.

Cet écart, c'est toute la décision. À 28,77 $ la passe, vous construisez une logique incrémentale : suivre quelles opérations ont changé, hasher chaque path item, ne régénérer que le diff, puis déboguer cette mécanique quand elle se désynchronise de la spec. À 0,29 $, vous supprimez la logique incrémentale. Vingt merges par mois, c'est 5,75 $, moins que les minutes de CI passées à exécuter les tests écrits par le modèle. Pour donner l'échelle, OpenAI rapporte que son chercheur médian dépense plus de 600 $ par jour en agents de codage, le 90e percentile dépassant 7 000 $.

Ce que le cache de prompt y change

GPT-6 s'est accompagné d'une vraie livraison de cache en même temps que le changement de prix : 90 % de réduction sur les lectures d'entrée mises en cache, des taux de succès plus élevés par défaut, un tableau de bord et un outil de diagnostic, des points de rupture explicites pour choisir où se termine le préfixe mis en cache, et la survie du cache aux changements d'effort de raisonnement et de disponibilité des outils. GitHub a rapporté plus de 50 % de tokens de prompt en moins nécessitant un traitement à neuf sur des milliards de requêtes. Détails dans le cache de prompt de GPT-6.

Appliqué à l'exécution ci-dessus, en retirant 90 % au tarif d'entrée de 0,10 $, soit 0,01 $ par million pour les lectures mises en cache :

Environ un tiers du coût sans cache, un cheveu sous le quart de centime par endpoint. Deux choses à ne pas présumer. OpenAI annonce les 90 % de réduction mais, dans nos sources, ne publie pas de tarif en dollars pour la lecture mise en cache chez Luna ; le 0,01 $ ci-dessus est donc de l'arithmétique, pas un tarif publié. Et rien de ce dont nous disposons ne cite de durée de vie du cache : lancez donc les 42 appels coup sur coup plutôt que de les étaler sur une file CI lente, et vérifiez le taux de succès dans le tableau de bord.

La requête

Rien d'exotique. C'est l'ordre qui rapporte :

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>" }
    ]
  }'

Le prompt système et le bloc de spec partagé sont identiques octet pour octet sur les 42 appels et viennent en premier. L'opération varie et vient en dernier. Inversez les deux et vous ne mettez rien en cache : l'exécution coûte alors 0,29 $ au lieu de 0,096 $. Toute la mécanique est là.

Le réglage d'effort high est délibéré. Les gains publiés de Luna par rapport à son prédécesseur sont mesurés à effort plus élevé, et comme le cache de GPT-6 survit à un changement d'effort, vous pouvez le régler par opération sans reconstruire le préfixe. Réservez les réglages les plus élevés aux endpoints qui touchent à l'argent ou à l'authentification.

Budgétez le temps, pas l'argent

Bon marché ne veut pas dire rapide. Artificial Analysis, un tiers, mesure la variante de raisonnement max de Luna à 153,9 tokens de sortie par seconde, avec un temps jusqu'au premier token de 124,23 secondes. Ces deux chiffres sont les leurs, pas ceux d'OpenAI, ils s'appliquent spécifiquement à la variante max, et AA renote en continu : considérez-les comme indicatifs.

Pris au pied de la lettre, un appel à effort max représente environ 124 secondes d'attente plus une vingtaine de secondes pour streamer 3 000 tokens, disons 144 secondes. Quarante-deux en séquence, c'est environ 101 minutes. Huit en parallèle, environ 13 minutes, une étape CI ordinaire.

Cela joue dans le sens inverse de la plupart des arguments de sélection de modèle, et c'est pourquoi l'association fonctionne : le temps jusqu'au premier token est une catastrophe pour un assistant interactif et quasi sans importance pour une tâche par lots qui écrit des fichiers. Le même compromis sur le grand frère dans le temps jusqu'au premier token de GPT-6 Sol.

Ce qu'il réussit, et les deux choses qu'il rate

Les résultats publiés par OpenAI pour Luna sont plus solides que le prix ne le suggère. Sur DeepSWE 1.1, il atteint 66,6 % à effort max, ce qu'OpenAI place au niveau de Claude Opus 5 et Fable 5 à effort moyen, tout en coûtant 93 % de moins par tâche qu'Opus 5 et 96 % de moins que Fable 5. Sur AutomationBench, il bat son prédécesseur de 5,4 points de pourcentage pour un coût par tâche inférieur de 58 %. Tous sont des exécutions OpenAI sur des harnais OpenAI, et aucun ne mesure la génération de tests à partir d'une spec.

Deux modes de défaillance comptent ici plus que n'importe quel benchmark.

Le modèle ne peut tester que ce que la spec dit. Si votre spec documente un 200 et un 400 pour POST /orders mais que le service renvoie aussi un 409 sur une clé d'idempotence en double, vous n'obtenez aucun test de conflit et la suite a toujours l'air complète. La qualité de génération est bornée par la qualité de la spec, ce qui fait de la spec l'artefact dans lequel investir, pas le prompt.

La génération bon marché échoue en ayant l'air correcte. L'erreur caractéristique n'est pas un test cassé, c'est un test qui passe en assertant sur un champ que la réponse ne contient jamais, ou un code de statut que l'endpoint n'émet jamais. Ceux-là passent la revue parce qu'ils se lisent comme des tests. Validez mécaniquement chaque assertion générée par rapport au schéma avant de la merger, en rejetant toute assertion qui référence un champ absent de components. Ce contrôle ne coûte rien et élimine la catégorie d'emblée.

Rendre la sortie exécutable

Les fichiers de test générés valent exactement ce que vaut le harnais dans lequel ils s'exécutent. Gardez la spec comme source de vérité, générez à partir d'elle, puis faites atterrir les cas quelque part où ils s'exécutent à chaque push.

Apidog couvre la seconde moitié de cette boucle. Il importe la spec à partir de laquelle vous générez, de sorte que le contexte partagé de votre prompt et les définitions de requêtes de votre runner proviennent d'un seul document et ne peuvent pas diverger. Les cas générés deviennent des scénarios de test dont les assertions se valident contre le schéma importé, transformant le contrôle ci-dessus en une barrière mécanique plutôt qu'en une corvée de revue. Smart mock sert la spec pendant que le backend est encore en cours d'écriture, de sorte qu'une suite générée peut échouer honnêtement avant qu'il n'y ait quoi que ce soit de réel à atteindre. Et les scénarios s'exécutent en CI, le seul endroit où un workflow de régénération à chaque merge est rentable.

Cela vaut-il la peine de router vers Luna ?

Oui, avec une réserve. Le coût n'est plus une raison de s'en passer : 0,29 $ la passe, ou moins de 0,10 $ avec le cache, c'est moins que la réunion où vous débattez de l'opportunité de régénérer. La latence est réelle mais tombe dans une fenêtre où personne n'attend. Et les résultats publiés de Luna le placent près de modèles coûtant 40 à 100 fois plus cher sur le travail de codage agentique.

Rien de tout cela ne rend la sortie digne de confiance à l'arrivée. Dépensez ce que vous avez économisé dans une barrière de validation de schéma et une relecture humaine de la première exécution, et traitez le résultat comme un premier jet qui couvre complètement la surface documentée et pas du tout la surface non documentée. Cela reste une meilleure position de départ que la suite écrite à la main qui a cessé de suivre la spec il y a quatre releases.