Sol, Terra, Luna : comment choisir et optimiser les coûts dans la famille GPT-5.6
Avec GPT-5.6, OpenAI ne vous vend plus un modèle mais une échelle de prix-performance : un facteur 5× entre Luna et Sol. Bien exploitée, cette échelle divise votre facture d'inférence ; mal exploitée, elle la multiplie. Cet article est le guide de décision, propre à la famille GPT-5.6, pour choisir le bon tier et optimiser le prompt caching.
Une précision de cadrage d'emblée : nous ne réexpliquons pas ici pourquoi le routing multi-modèles s'impose (c'est le sujet de notre guide du un modèle par tâche) ni pourquoi le prix par token est le mauvais indicateur, que nous démontrons dans l'illusion du prix par token. Ces principes sont acquis. Ce que nous faisons ici, c'est les appliquer concrètement à Sol, Terra et Luna : quel tier pour quelle tâche, et comment tirer parti des spécificités de facturation de GPT-5.6.
Le problème : un tier unique pour tout, c'est le pire des deux mondes
Choisir un seul tier pour l'ensemble de vos workflows vous condamne à un arbitrage perdant. Prenez Sol partout, et vous payez le tarif du flagship pour résumer un ticket. Prenez Luna partout, et vous sacrifiez la qualité sur une migration critique. Dans les deux cas, vous laissez de l'argent (ou de la fiabilité) sur la table. La famille GPT-5.6 a précisément été conçue pour éviter ce piège : trois tiers pensés pour être routés, pas pour être choisis une fois pour toutes.
Et l'écart n'est pas théorique. Un run par lot de 1 000 résumés d'actualités (environ 2 millions de tokens en entrée, 300 000 en sortie) coûte de l'ordre de 3,80 $ sur Luna, contre environ 19 $ sur Sol. Multipliez par le volume quotidien d'une application temps réel, et l'écart devient une ligne budgétaire à part entière. Pire : un défaut de configuration fréquent dans les outils agentiques envoie chaque sous-agent vers le modèle le plus cher : un simple correctif de config peut réduire l'usage de moitié.
La grille Sol / Terra / Luna, et ce qu'elle vous dit
| Tier | Entrée (/M) | Sortie (/M) | À utiliser pour |
|---|---|---|---|
| Luna | 1 $ | 6 $ | Haut volume : classification, résumé, routing, autocomplétion, temps réel |
| Terra | 2,50 $ | 15 $ | Défaut production : boucles de dev, coding scopé, review de première passe, extraction structurée |
| Sol | 5 $ | 30 $ | Cas durs : coding long-horizon, debug critique, migrations, cyber, mode ultra |
Grille valable au 16 juillet 2026, à revérifier sur les pages tarifaires officielles avant toute décision d'achat. Ce tableau n'est pas une liste de prix : c'est une carte de routage. Chaque tier a une zone d'usage où son rapport capacité-coût domine. La discipline gagnante consiste à faire correspondre la profondeur de la tâche au tier, et non à retenir un tier par confort.
Router par profondeur de tâche : Luna → Terra → Sol
La règle est simple à énoncer : Luna en première passe, Terra par défaut, Sol pour les cas durs. On n'escalade que lorsque la tâche l'exige vraiment. Voici comment chaque tier se justifie.
Luna, le tier de première passe. Là où un premier jet a de la valeur en soi, ou réduit la charge avant une escalade. Idéal quand la tâche consiste surtout à résumer, étiqueter, extraire ou générer un squelette de code. Sur Terminal-Bench 2.1, Luna dépasse même la génération précédente : c'est un cheval de trait sérieux, pas un jouet. Sa limite à connaître : Luna chute nettement sur le rappel en très long contexte (autour de 41 % sur les tests de récupération multi-aiguilles), à ne pas utiliser pour de l'analyse documentaire massive.
Terra, le défaut de production. Il tient tête à la génération précédente sur presque tous les benchmarks à moitié prix, et se place à 87,4 % sur Terminal-Bench 2.1, à un cheveu de Sol (88,8 %). Pour une majorité de tâches CI/CD et de boucles de développement scopées, c'est le candidat naturel au statut de modèle par défaut, avec une escalade vers Sol disponible quand la précision manque sur un cas complexe.
Sol, le spécialiste. À réserver aux tâches où le coût d'une erreur dépasse le coût des tokens : debug difficile, migrations, review de sécurité en environnement autorisé, décisions d'architecture. Le mode ultra (agents parallèles) n'est à activer que ponctuellement, sur des tâches vraiment dures et décomposables : il triple environ la facture d'un run pour quelques points de score.
| Si la tâche est… | Alors utilisez… | Escalade si… |
|---|---|---|
| Volume, latence critique, contexte court | Luna | La qualité ne converge pas |
| Dev courant, review de PR, contexte modéré | Terra | Précision insuffisante sur cas complexe |
| Long-horizon, critique, cyber, migration | Sol | Tâche dure et décomposable → ultra (ponctuel) |
Prompt caching GPT-5.6 : le premier levier d'économie
GPT-5.6 rend le prompt caching plus prévisible, et c'est le levier le plus rentable pour un agent qui relit le même dépôt ou le même prompt système pendant des heures. Trois paramètres à connaître, propres à cette génération :
- Lectures de cache à −90 %. Un contexte déjà vu se relit à environ un dixième du tarif d'entrée. Comme la facture d'un cycle agentique suit l'ingestion (ce que le modèle relit sans cesse), c'est le premier poste sur lequel agir.
- Écritures de cache à 1,25×. Nouveauté à budgéter : le cache n'est plus « gratuit ». Écrire dans le cache coûte désormais 1,25× le tarif d'entrée non caché. La conséquence pratique : ne cachez que ce qui est réellement réutilisé, avec des points de rupture explicites, et exploitez la durée de vie minimale de 30 minutes.
- Seuil long contexte à 272 k tokens. Au-delà de 272 000 tokens en entrée, Sol bascule sur un tarif plus élevé et son avantage prix face à Claude Fable 5 s'érode. Si vos requêtes dépassent ce seuil, envisagez de scinder le contexte ou de router différemment plutôt que d'absorber le surcoût.
Ces trois réglages transforment un avantage tarifaire théorique en gain réel, ou en piège. C'est le cœur du travail d'ingénierie du contexte : décider précisément ce que le modèle voit, et ce qu'il relit.
Raisonner en coût par tâche résolue, pas en prix par token
Le piège serait de comparer les grilles tarifaires. La bonne métrique est le coût par tâche menée à terme, qui intègre le nombre d'étapes, les tokens de sortie et les reprises, un raisonnement que nous développons en détail dans l'illusion du prix par token. GPT-5.6 gagne beaucoup ici : moins d'étapes, moins de tokens de sortie, moins de stuck runs. Un tier plus cher au token qui termine en trois étapes au lieu de dix est, in fine, moins cher, et plus rapide. C'est pourquoi le débat « Luna ou Sol ? » ne se tranche jamais sur la grille de prix, mais sur la mesure : instrumentez le coût par phase, et le bon tier se révèle de lui-même.
La recommandation SFEIR
Démarrez avec Terra comme défaut, basculez le haut volume sur Luna dès aujourd'hui (les économies sont immédiates et la « taxe qualité » est faible), et n'escaladez vers Sol que là où l'écart de précision justifie le surcoût. Instrumentez le prompt caching (−90 % sur les relectures) avant toute autre optimisation : c'est le levier le plus rentable, et le plus souvent négligé.
Enfin, ne réduisez pas la question à un seul fournisseur. Gardez Claude (Fable 5 pour l'architecture et la planification, Sonnet 5 pour la génération équilibrée) dans votre boîte à outils : sur les tâches longues et réalistes, il conserve un avantage que la famille GPT-5.6 ne comble pas encore, comme le montre notre analyse Terminal-Bench. Le multi-modèle bat le mono-fournisseur, et l'échelle Sol / Terra / Luna n'est qu'un chapitre d'une stratégie de choix plus large. La vraie compétence n'est pas de choisir un tier : c'est de router, et de le prouver sur vos propres mesures.
Sources
- OpenAI — grille tarifaire et caractéristiques de GPT-5.6 (Sol / Terra / Luna), 9 juillet 2026 : prix par million de tokens, tarification du prompt caching (lectures −90 %, écritures 1,25×), seuil long contexte 272 k. Tarifs auto-reportés, valables au 16 juillet 2026, à revérifier sur les pages officielles avant décision d'achat. openai.com
- Artificial Analysis — indices de performance et coûts par tâche de la famille GPT-5.6 (Terminal-Bench, rappel long contexte, DeepSWE). Données produites avec le soutien d'OpenAI en pré-lancement, à traiter comme indicatives. artificialanalysis.ai
- Analyse first-party SFEIR de la consommation d'un cycle de développement piloté par agents (matière interne « Tokens & SDLC v3 »), d'après Bai et al., arXiv 2604.22750 (2026) : la facture suit l'ingestion (ratio 153:1), prompt caching jusqu'à −90 % sur l'entrée, routage « un modèle par phase », coût-par-résultat comme bonne métrique. arXiv 2604.22750
Articles similaires
GPT-5.6 Sol, Terra, Luna : comment OpenAI rebat les cartes du coding agentique et du pricing
Le 9 juillet 2026, OpenAI a rendu GPT-5.6 généralement disponible, non pas un modèle mais trois : Sol, Terra, Luna. Lecture d'ingénieurs, chiffrée et sans parti pris : ce que la famille change pour le coût d'inférence, le routing entre modèles et l'équilibre concurrentiel avec Claude.
Terminal-Bench et Coding Agent Index : pourquoi GPT-5.6 prend l'avantage sur les agents de coding en production
En production, un agent de coding ne se juge pas à un score mais à sa capacité à terminer le travail : en un minimum d'étapes, d'appels d'outils et de tokens. Sur ce terrain, Terminal-Bench 2.1 et Coding Agent Index, GPT-5.6 prend l'avantage. Voici pourquoi, et où passe la limite.
Un modèle par tâche : le guide du routing multi-modèles
Faire tourner toute une usine logicielle sur un seul modèle frontier, c'est payer le tarif du raisonnement pour lire des logs. La mécanique du routage multi-modèles : un modèle par phase, une passerelle unique, l'isolation des sous-agents et la règle qui dit quand le multi-agents mérite son coût.
Le prix par token est une illusion : mesurer le coût par résultat
Comparer les grilles tarifaires ne dit presque rien de la facture réelle. Sur un cycle agentique, la dépense suit l'ingestion, pas la génération : 153 pour 1. Un modèle « moins cher au token » qui relit plus n'économise rien. Le seul indicateur qui compte est le coût par résultat.