GPT-6 Sol et Luna : choisir le bon modèle et maîtriser le coût de l’API en 2026

Salut HaWkers, OpenAI a présenté GPT-6 Sol et GPT-6 Luna le 22 septembre 2026 et les a mis à disposition dans son API sous les noms gpt-6-sol et gpt-6-luna. Après GPT-6 Astra, ils posent une question aux équipes produit : quelle capacité payer pour chaque tâche ? La note officielle de lancement évoque des tarifs API inférieurs de 50 % aux tarifs promotionnels des modèles GPT-5.6 correspondants.

Faut-il tout migrer, ou réserver chaque modèle à une étape précise ? Dans ce guide, nous distinguerons le prix par jeton du coût par tâche, construirons une méthode d’évaluation reproductible et définirons une règle simple de choix. Vous déciderez avec vos données, tout en prévoyant un repli si la qualité baisse.

Ce Qui Change Avec Sol et Luna

La famille GPT-6 propose désormais Astra, Sol et Luna, avec des objectifs distincts. La documentation officielle des modèles présente Astra comme l’option la plus puissante, Sol pour les flux exigeants de code et d’agents, et Luna pour les tâches ciblées à grand volume. Les identifiants API comptent : gpt-6-astra, gpt-6-sol et gpt-6-luna. Utilisez ces noms et vérifiez leur disponibilité avant toute migration générale.

Cette distinction ne réserve pas chaque modèle à un seul usage. Une classification courte peut exiger Sol si les cas ambigus sont coûteux. Une recherche peut employer Luna pour le premier tri, puis Sol pour la synthèse finale. La répartition dépend du coût d’une erreur, de la fréquence et de la vérifiabilité. Une démonstration réussie ne révèle pas comment le modèle traitera les exceptions que vos clients envoient réellement.

Le journal des modifications de l’API indique que les deux modèles ont été lancés le 22 septembre. Il précise qu’ils acceptent du texte et des images en entrée, produisent du texte en sortie et sont accessibles par Responses et Chat Completions. Pour les flux dotés d’outils et de raisonnement, le guide des modèles recommande Responses. Si votre agent interroge des systèmes externes, ce détail est essentiel : recopier un ancien appel sans revoir ses paramètres peut entraîner un comportement inattendu.

Le blog a déjà présenté cette famille dans l’article consacré à GPT-6 Astra et à ses applications en robotique. Ici, nous examinons une décision de produit : quand payer davantage pour améliorer la réponse et quand une option économique suffit. Elle touche aussi à l’expérience utilisateur, à la marge et à la fiabilité.

Le Prix Par Jeton N’est Pas le Coût Par Tâche

Au lancement, OpenAI a annoncé, pour le palier standard allant jusqu’à 272 000 jetons en entrée, 2 dollars par million de jetons en entrée et 10 dollars par million en sortie pour Sol. Pour Luna, les montants sont respectivement de 0,10 et 0,50 dollar. Le journal des modifications donne également un tarif d’entrée mise en cache de 0,20 dollar pour Sol et de 0,01 dollar pour Luna. Ces montants correspondent au périmètre documenté ; chaque requête ne sera pas nécessairement facturée ainsi. La page des tarifs distingue aussi la taille du contexte et le mode de traitement. Consultez la grille en vigueur avant de valider un budget.

Imaginez une tâche avec beaucoup d’instructions et une réponse brève : le prix de l’entrée pèsera davantage. Dans un autre cas, la réponse sera longue et le prix de sortie dominera. Les outils, les nouvelles tentatives, le contexte étendu, la mise en cache et les services associés modifient aussi le total. Comparer uniquement les « dollars par million » conduit donc souvent à une mauvaise conclusion : un modèle bon marché qui nécessite trois essais peut coûter plus cher qu’un modèle qui réussit du premier coup.

La fonction suivante estime uniquement le coût du texte avec les tarifs que vous lui fournissez. Les valeurs d’exemple viennent du journal des modifications publié au lancement pour le périmètre indiqué. Elle n’ajoute ni outils, ni contexte étendu, ni taxes, ni remises supplémentaires. Des tarifs explicites facilitent les mises à jour.

const rates = {
  sol: { input: 2, cachedInput: 0.20, output: 10 },
  luna: { input: 0.10, cachedInput: 0.01, output: 0.50 },
}

function textCost({ input, cachedInput = 0, output }, rate) {
  // Séparez l’entrée mise en cache pour éviter de la compter deux fois.
  const freshInput = Math.max(0, input - cachedInput)
  return (
    freshInput * rate.input +
    cachedInput * rate.cachedInput +
    output * rate.output
  ) / 1_000_000
}

const usage = { input: 12_000, cachedInput: 8_000, output: 1_000 }
console.log({ sol: textCost(usage, rates.sol), luna: textCost(usage, rates.luna) })

Ce calcul reste une estimation. Le montant facturé dépend de l’utilisation réelle, du niveau de service et des règles de la grille applicable. Conservez, pour chaque tâche terminée, le nombre de jetons en entrée, celui des jetons mis en cache et en sortie, le nombre d’essais et le coût des outils. Vous mesurerez le coût d’une réponse acceptable, au-delà du simple appel API.

Quand Choisir Luna, Sol ou Astra

Commencez par évaluer le risque lié au résultat. Luna est un candidat naturel pour la classification, l’extraction de champs, les courts brouillons et les autres tâches fréquentes assorties d’un critère d’acceptation objectif. La description officielle de Luna le destine aux tâches ciblées et volumineuses. Mais « simple » n’exclut pas une évaluation : mal classer une résiliation peut retarder la réponse et nuire au client.

Sol est plus pertinent lorsqu’il faut respecter plusieurs contraintes, traiter un contexte étendu, utiliser des outils ou prendre des décisions aux conséquences plus importantes. Le guide officiel le recommande pour un raisonnement solide face aux tâches exigeantes. Une revue de contrat, une correction de code ou un plan de support s’appuyant sur un long historique méritent une comparaison directe avec Luna. Si la différence de qualité reste faible sur vos cas, l’option économique peut suffire. Si Sol évite des reprises, son surcoût peut être justifié.

Selon OpenAI, Astra demeure la référence de la famille pour les travaux les plus difficiles. Cela ne signifie pas qu’il faut l’utiliser pour toute demande complexe. Définissez d’abord la réussite : réponse exacte, source traçable, format valide, action sûre et délai acceptable. Comparez ensuite les trois modèles sur des exemples tirés de votre parcours. Votre choix reposera sur la valeur apportée à l’utilisateur plutôt que sur le nom du modèle.

Une première règle pourrait envoyer les tâches courantes vers Luna, les exceptions vers Sol et les cas critiques vers Astra ou vers une personne. Testez cette hypothèse. Les données sensibles peuvent exiger une validation humaine à tous les niveaux. Si une action est irréversible, demandez la confirmation du système responsable avant de l’exécuter, quelle que soit la confiance affichée par le texte généré.

Construire une Évaluation Fidèle à Votre Produit

Une évaluation utile commence par des exemples réels et une autorisation appropriée pour les utiliser. Retirez si possible les données personnelles, incluez des cas faciles et difficiles, puis notez le résultat attendu ou un critère vérifiable. Ne choisissez pas seulement les démonstrations qui ont déjà réussi. Les échecs rares demandent une attention particulière lorsqu’ils entraînent une perte financière, une publication erronée ou un mauvais service client.

Répartissez les tâches par type : extraction, décision, explication, génération et utilisation d’outils. Dans chaque groupe, mesurez la justesse, le format, le temps, le nombre de tentatives et les interventions humaines. Un pourcentage global unique masquerait qu’un modèle peut bien rédiger des brouillons tout en échouant sur des décisions. L’article officiel publie ses propres résultats de référence ; ils indiquent une capacité générale, mais ne remplacent pas une évaluation faite avec vos données et vos règles.

Utilisez les mêmes entrées, les mêmes instructions et les mêmes critères pour chaque modèle. Si vous modifiez le prompt d’un modèle seulement, vous comparez deux systèmes différents. Consignez la version du prompt, le modèle, le niveau d’effort et la date du test. Après une mise à jour, vous pourrez détecter progrès et régressions.

L’exemple suivant regroupe des résultats déjà revus par des personnes. Ne définissez passed sur vrai qu’après avoir appliqué un critère rédigé à l’avance. La fonction ne demande pas à une autre IA de juger les réponses ; elle calcule les indicateurs d’un jeu de tests pour éclairer votre décision.

function summarize(results) {
  const total = results.length
  if (total === 0) throw new Error("Ajoutez des cas évalués")
  const passed = results.filter(item => item.passed).length
  const cost = results.reduce((sum, item) => sum + item.costUsd, 0)
  const latency = results.reduce((sum, item) => sum + item.latencyMs, 0)
  return {
    passRate: passed / total,
    costPerAcceptedTask: passed ? cost / passed : Infinity,
    meanLatencyMs: latency / total,
  }
}

// Chaque ligne représente une tâche complète, tentatives comprises.
const lunaResults = [
  { passed: true, costUsd: 0.002, latencyMs: 800 },
  { passed: false, costUsd: 0.003, latencyMs: 900 },
]
console.log(summarize(lunaResults))

Les nombres de ce code sont fictifs : ils illustrent le calcul et ne sont pas des mesures d’OpenAI ou du blog. En pratique, examinez aussi la distribution des résultats. Une latence moyenne peut cacher de longs retards précisément dans les cas importants. Lisez des exemples d’erreurs et repérez les tendances avant de changer de modèle partout. Une bonne règle d’orientation peut résoudre le problème à moindre coût.

Définir l’Orientation et une Issue de Secours

Après l’évaluation, transformez les résultats en une règle courte que toute l’équipe peut vérifier. Fondez-la sur la tâche, le risque et les outils requis, plutôt que sur des mots magiques. Rendez la logique déterministe chaque fois que possible afin de pouvoir expliquer pourquoi une requête a été envoyée à un modèle plus coûteux.

function chooseModel(task) {
  // Cette règle appartient au produit ; ajustez-la selon vos tests réels.
  if (task.irreversibleAction || task.highImpact) return "gpt-6-astra"
  if (task.requiresTools || task.longContext || task.ambiguous) return "gpt-6-sol"
  return "gpt-6-luna"
}

const tasks = [
  { kind: "classify", highImpact: false },
  { kind: "research", requiresTools: true },
  { kind: "approve-transfer", irreversibleAction: true },
]
console.log(tasks.map(task => ({ kind: task.kind, model: chooseModel(task) })))

Le résultat de chooseModel propose un modèle ; il n’autorise aucune action. Pour le virement de l’exemple, une personne ou un service d’approbation doit encore confirmer l’effet attendu. Séparez le choix du modèle, la génération du texte, la validation du résultat et l’exécution de l’action. Cela limite les erreurs et facilite l’analyse des incidents.

Prévoyez aussi une issue de secours. Si la réponse ne respecte pas le schéma, si la source requise manque ou si la durée dépasse une limite, réessayez avec un modèle adapté ou demandez une revue. Consignez la raison de ce changement. Sans historique, un système économique peut progressivement envoyer presque tout vers l’option la plus chère.

Fixez une limite aux nouvelles tentatives. Répéter indéfiniment une mauvaise requête consomme le budget et peut amplifier l’erreur. Un nouvel essai après correction d’un format peut être raisonnable ; plusieurs tentatives sans diagnostic exigent une enquête. Suivez le taux de recours à une solution de secours, le coût par tâche acceptée et la satisfaction des utilisateurs. Réduire la facture en dégradant leur expérience n’est qu’une économie apparente.

Cache, Contexte et Outils Dans la Facture Finale

L’annonce officielle souligne des améliorations de la mise en cache pour les conversations et les agents. Réutiliser un début d’instructions peut réduire le coût de lecture et le délai, mais ne présumez pas que chaque appel bénéficiera d’une remise. Le taux de réutilisation dépend de la structure des entrées. Si vous placez des données variables au début du prompt, une petite modification peut empêcher la réutilisation attendue. Observez le nombre réel de jetons mis en cache avant de prévoir vos économies.

Le contexte étendu demande lui aussi de la prudence. Une grande fenêtre n’impose pas d’envoyer tout l’historique. Supprimez les doublons, ne récupérez que les documents pertinents et résumez ce qui peut l’être, avec vérification. Une entrée plus longue risque davantage de contenir des informations obsolètes ou contradictoires. Le problème de qualité peut venir du choix du contexte plutôt que du modèle.

Les outils changent l’économie d’un agent. Une recherche, une requête à une base de données ou une opération dans un autre service peut coûter davantage que les jetons et augmenter le délai. Si l’agent appelle plusieurs fois le même outil pour répondre à une question simple, revoyez le parcours. Distinguez les étapes qui exigent des informations récentes de celles que vos données disponibles permettent de résoudre, et gardez une trace de la provenance des réponses.

Dans l’API, vérifiez les paramètres acceptés par le modèle choisi. Le guide officiel indique que Sol et Luna acceptent le niveau d’effort de raisonnement none, contrairement à Astra. Il recommande aussi Responses pour les outils associés au raisonnement. Une migration sûre teste ensemble le format, les outils, la latence et le coût. Changer seulement la chaîne du nom du modèle peut modifier une étape critique sans que cela apparaisse dans une comparaison superficielle.

Perspectives : Choisir un Modèle Relève de la Gestion de Produit

L’arrivée de Sol et de Luna ouvre davantage de possibilités, mais n’élimine pas la nécessité de mesurer. Le prix par jeton indique le coût de la ressource consommée. Le coût par tâche acceptée indique ce qu’il faut dépenser pour apporter une valeur réelle. L’écart comprend les échecs, les corrections, le temps, les outils et les dommages qu’une mauvaise réponse peut causer. En suivant ces éléments séparément, l’équipe peut investir dans la capacité là où elle améliore réellement l’expérience.

Commencez par un petit ensemble de cas représentatifs. Comparez Luna et Sol, puis ajoutez Astra uniquement lorsque le risque ou la qualité le justifie. Consignez votre règle d’orientation et réévaluez-la après tout changement du produit ou du modèle. Le meilleur réglage aujourd’hui peut cesser de l’être lorsque le volume, les tarifs ou la nature des demandes évoluent. Pour la disponibilité et les prix actuels, consultez la documentation officielle.

Allez, on y va! 🦅

📚 Vous Voulez Suivre Ce Qui Arrive ?

Cet article présentait GPT-6 Sol et Luna, mais cet écosystème évolue chaque semaine et toutes les nouveautés ne font pas l’objet d’un billet ici.

Sur X, je partage mes essais, les coulisses de mes projets et les nouveautés que je découvre avant qu’elles ne deviennent des articles.

Suivez-Moi Là-Bas

👉 Suivre @jeffbruchado sur X

💡 Du contenu quotidien sur le développement, la carrière et les outils que j’utilise réellement