GPT-6.1 Sol vs GPT-6 Sol : mêmes tarifs d’entrée/sortie, cache moins cher et migration
none et impose Responses pour les appels d’outils. Un agent qui utilisait des outils via Chat Completions exige davantage qu’un changement d’identifiant.GPT-6.1 Sol vs GPT-6 Sol : les différences essentielles
| Variable de décision | GPT-6 Sol | GPT-6.1 Sol | Conséquence pour un agent existant |
|---|---|---|---|
| Identifiant officiel | gpt-6-sol | gpt-6.1-sol | Fixer la version ; ne pas dépendre d’un alias Sol générique |
| Entrée / sortie | Texte et images / texte | Texte et images / texte | Aucune nouvelle modalité de sortie à prévoir |
| Contexte / sortie maximale | 1,050,000 / 128,000 tokens | Mêmes limites | Aucune fenêtre de contexte plus grande |
| Limite des connaissances | 20 avril 2026 | 30 avril 2026 | Une date plus récente n’est pas un résultat de qualité sur vos tâches |
| Effort de raisonnement | none, low, medium, high, xhigh, max | low, medium, high, xhigh, max ; sans none ni minimal | Retirer les réglages non pris en charge de la configuration candidate |
| Appel de fonctions Chat Completions | Uniquement avec effort none | Non pris en charge | Déplacer les tâches à outils vers une route Responses vérifiée |
| Appel d’outils Responses | Pris en charge | Pris en charge | Vérifier encore la boucle d’outils et la passerelle |
| Streaming / sorties structurées | Indiqués par OpenAI | Indiqués par OpenAI | Le support du fournisseur ne prouve pas celui d’une route précise |
medium par défaut. Avec des limites inchangées, la compatibilité et le coût par tâche acceptée sont plus utiles pour décider que la taille du contexte.Ce que montrent les évaluations officielles
| Évaluation | Écart annoncé par rapport à GPT-6 Sol | Conditions et limites d’interprétation |
|---|---|---|
| DeepSWE v1.1 | +6.4 points de pourcentage par rapport au meilleur score de l’ancien modèle | Le candidat utilisait un effort et un coût moindres ; ce n’est pas une comparaison à effort identique |
| AutomationBench 1.0.6 | +4.8 points de pourcentage | Même réglage medium ; pertinent pour les processus d’outils en plusieurs étapes |
| OSWorld 2.0 | +7 points de pourcentage, pour moins de la moitié du coût par tâche | Effort maximal ; récompense partielle sur le jeu hors ligne v2026.08.08 |
Ces résultats justifient des essais sur les modifications de code complexes et les processus métier avec outils. La récompense partielle d’OSWorld mesure la progression vers une tâche ; elle ne remplace pas votre taux d’acceptation binaire. OpenAI précise aussi que son environnement de recherche/API peut différer de ChatGPT en production. Conservez le protocole, le niveau d’effort et le périmètre des coûts lorsque vous citez un résultat.
L’annonce justifie moins un remplacement général pour les tâches courantes que votre modèle réussit déjà. Utilisez les tâches appariées ci-dessous pour voir quelles améliorations se transfèrent à votre charge. Ne déduisez pas votre latence, vos nouvelles tentatives ou votre facture EvoLink de ces résultats.
Choisir l’endpoint avant de juger les performances
Trois migrations sont réellement différentes. Les regrouper dans un seul essai rend les échecs difficiles à interpréter.
| Fonctionnement actuel | Voie candidate | Première vérification d’acceptation |
|---|---|---|
| Chat Completions sans outils, avec un niveau de raisonnement pris en charge | Tester les règles documentées de 6.1 Sol sans outils | Analyse de réponse, format de sortie et usage réellement facturé |
Outils Chat Completions avec none | Migrer les outils vers Responses et choisir un effort pris en charge | Requêtes d’outils, association des résultats, reprise et nouvelles tentatives |
| Responses avec outils | Conserver le processus, fixer le nouvel ID et un effort pris en charge | Boucle complète d’outils, résultats structurés, streaming et annulation lorsqu’ils sont utilisés |
none peut également modifier la latence, le volume de sortie et le comportement même si l’endpoint reste identique.Pour migrer un processus dépendant d’outils, commencez par inventorier l’endpoint, l’effort, les définitions d’outils, les identifiants de résultats et la gestion des reprises. Adaptez ensuite la boucle à Responses, notamment l’association d’un résultat à l’appel qui l’a demandé. Rejouez une action réussie, une action échouée et une exécution annulée dans un bac à sable ; inspectez les enregistrements produits autant que le texte final. Vérifiez l’analyse des sorties structurées et le streaming si votre client les utilise. Commencez seulement ensuite la comparaison de qualité.
Séparez les échecs de compatibilité des tâches refusées. Vérifiez les règles et la facturation de la route exacte avant un pilote, et conservez ensemble l’ancien modèle, l’endpoint et l’analyseur pour le retour arrière.
Une réduction du prix du cache n’est pas celle de toute la tâche
| Catégorie de tokens | GPT-6 Sol, entrée jusqu’à 272K | GPT-6.1 Sol, entrée jusqu’à 272K | GPT-6.1 Sol, entrée au-delà de 272K |
|---|---|---|---|
| Entrée sans cache | $2.00 | $2.00 | $4.00 |
| Lecture du cache | $0.20 | $0.10 | $0.20 |
| Écriture du cache | $2.50 | $2.50 | $5.00 |
| Sortie | $10.00 | $10.00 | $15.00 |
Par rapport à 6 Sol, la lecture du cache coûte directement 50% de moins. Par rapport au tarif d’entrée ordinaire de 6.1 Sol lui-même, une lecture du cache coûte 95% de moins. Aucune de ces comparaisons ne signifie que l’ensemble d’une tâche coûte 50% ou 95% de moins. Les sorties, entrées sans cache et écritures du cache n’ont pas reçu la même réduction.
| Part en cache du million de tokens d’entrée | Entrée + sortie GPT-6 Sol | Entrée + sortie GPT-6.1 Sol | Économie directe |
|---|---|---|---|
| 40% | $1.20 sans cache + $0.08 cache + $1.00 sortie = $2.28 | $1.20 + $0.04 + $1.00 = $2.24 | $0.04 |
| 90% | $0.20 sans cache + $0.18 cache + $1.00 sortie = $1.38 | $0.20 + $0.09 + $1.00 = $1.29 | $0.09 |
Ces parts sont des hypothèses, pas des taux de cache mesurés ni la promesse qu’un prompt réutilisé sera admissible au cache. Une sortie de raisonnement plus longue ou une tentative supplémentaire peut absorber l’économie illustrée. À l’inverse, un meilleur taux de tâches acceptées peut apporter une valeur bien supérieure à l’écart de prix du cache. Mesurez les deux effets plutôt que de conclure à partir du tableau de prix des tokens.
Une évaluation appariée autour de six tâches réelles
Figez des tâches récentes, les versions des dépôts et les règles d’acceptation avant de lancer les modèles. Incluez des cas où l’ancien agent a échoué ou exigé une intervention humaine, ainsi que des tâches courantes. Gardez les permissions d’outils et les limites de nouvelles tentatives identiques ; signalez les adaptations nécessaires d’endpoint ou de protocole au lieu de présenter l’essai comme parfaitement contrôlé.
| Tâche | Entrée et résultat attendu | Signal d’acceptation | Signal de coût ou d’échec | Priorité d’essai |
|---|---|---|---|---|
| Correction de bug multi-fichiers | Dépôt et problème figés → correctif | Tests requis réussis sans changements sans rapport | Nouvelles tentatives, reprises et intervention du relecteur | Commencer par les échecs et les changements exigeant beaucoup de revue |
| Revue de PR | Diff et conventions figés → observations | Défauts confirmés avec faux positifs tolérables | Temps de vérification des fausses alertes | Garder la référence si les nouvelles observations ajoutent du bruit |
| Agent à contexte réutilisé | Contexte enregistré et outils autorisés → tâche terminée | Contraintes conservées ; aucun effet secondaire en double | Lectures/écritures du cache et sortie de raisonnement | Tester si l’usage confirme des lectures importantes du cache |
| Questions documentaires | Documents et questions figés → réponses étayées | Champs corrects et preuves traçables | Conclusions sans fondement et temps de revue | Tester tableaux et preuves contradictoires, pas seulement la recherche simple |
| Processus métier avec outils | Objectif et outils isolés → enregistrements finaux attendus | Séquence et état des enregistrements corrects | Écritures en double ou résultats d’outils mal associés | Vérifier la boucle d’outils avant la qualité du modèle |
| Escalade de tâches difficiles | File de tâches figée → résultats acceptés | Seuil de qualité atteint sur la file | Coûts cumulés du candidat, de l’escalade et du repli | Tester d’abord une route dédiée aux tâches difficiles |
Choisissez les règles de rejet avant l’essai. Un processus métier peut refuser toute écriture en double même si la réponse finale semble correcte. Un correctif peut exiger des tests cachés en plus de ceux visibles par l’agent. Un JSON valide ne démontre pas l’exactitude des champs extraits.
Consignez pour chaque tentative l’ID de tâche, l’identité du modèle, l’endpoint, l’effort, les appels d’outils, l’usage, les nouvelles tentatives, l’acceptation et le temps de revue. Résumez la taille de l’échantillon et les désaccords entre résultats appariés ; un petit ensemble peut révéler un blocage, pas une amélioration fiable sur toute la population. Inspectez les échecs individuels autant que les moyennes, surtout lorsqu’une tâche longue domine la facture.
Comparer le coût par tâche acceptée, puis migrer par étapes
Utilisez cette définition comptable :
Rendez explicite le coût de revue humaine : appliquez un taux documenté ou indiquez les minutes de revue avec le coût API. Ne l’omettez pas discrètement pour un modèle. Sans tâche acceptée, le ratio est indéfini ; notez un essai échoué plutôt qu’un résultat bon marché.
Exemple complet de comptabilité sur 100 tâches
| Mesure | Référence 6 Sol | 6.1 : Cache | 6.1 : Moins de reprise | 6.1 : Sortie/reprises |
|---|---|---|---|---|
| Entrée sans cache / lectures, millions de tokens | 4 / 6 | 4 / 6 | 3.6 / 5.4 | 4.8 / 7.2 |
| Écritures du cache / sortie, millions de tokens | 0.4 / 1 | 0.4 / 1 | 0.36 / 0.9 | 0.48 / 1.8 |
| Tentatives supplémentaires | 20 | 20 | 10 | 30 |
| Frais de tokens | $20.20 | $19.60 | $17.64 | $29.52 |
| Frais d’outils supposés | $3.00 | $3.00 | $2.70 | $3.60 |
| Minutes / coût de revue | 240 / $120 | 240 / $120 | 180 / $90 | 300 / $150 |
| Coût total de l’essai | $143.20 | $142.60 | $110.34 | $183.12 |
| Tâches acceptées sur 100 | 80 | 80 | 90 | 75 |
| Coût par tâche acceptée | $1.79 | $1.78 | $1.23 | $2.44 |
4 × $2 + 6 × $0.20 + 0.4 × $2.50 + 1 × $10 = $20.20. Avec outils et revue, le coût par tâche acceptée est $143.20 ÷ 80 = $1.79. Le scénario avec moins de reprise donne $110.34 ÷ 90 ≈ $1.23.À comportement identique, le cache n’économise que $0.60 sur cette file. Moins de reprises peut apporter un bénéfice supérieur ; davantage de sortie, de nouvelles tentatives et de revue peut l’annuler. L’exemple ne prédit pas le comportement de 6.1 Sol. Remplacez chaque hypothèse par des relevés appariés d’usage, d’acceptation et de revue, puis utilisez les tarifs de passerelle vérifiés pour une décision EvoLink.
Fixer les critères du pilote avant l’essai
Copiez cette grille et remplacez ses exemples par les exigences de service de votre équipe. Ce sont des propositions éditoriales, pas des recommandations d’OpenAI ni une garantie statistique.
| Mesure | À relever pour les deux modèles | Critère d’exemple |
|---|---|---|
| Tâches acceptées | Tâches acceptées/attribuées et désaccords appariés | Candidat au moins au niveau de la référence ; examiner séparément les régressions critiques |
| Coût effectif | Coût de toutes les tentatives / tâches acceptées | Pas supérieur à la référence, sauf surcoût de qualité convenu à l’avance |
| Latence | p95 de bout en bout, outils et nouvelles tentatives inclus | Dans un budget de 75 secondes défini par l’équipe dans cet exemple |
| Exactitude des outils | Actions erronées, écritures en double et état final | Zéro écriture en double ou non autorisée ; tout incident bloque le pilote |
| Règles et facturation | Identité renvoyée, fonctions, usage et frais réels | Vérifiés pour la route candidate avant le trafic de production |
Les décisions suivantes prolongent l’exemple fictif des 100 tâches ; latence et résultats d’actions sont des hypothèses supplémentaires.
| Résultat | Preuves d’exemple | Étape suivante |
|---|---|---|
| Lancer un pilote limité | 90 acceptées contre 80 ; $1.23 contre $1.79 ; p95 70s ; aucune écriture erronée ; route/facturation vérifiées | Envoyer une petite cohorte choisie, par exemple 5%, puis revérifier les mêmes critères avant d’élargir |
| Continuer hors ligne | Aucun critère impératif violé, mais les désaccords de revue empêchent de conclure sur la qualité | Réévaluer les tâches contestées et étendre l’ensemble apparié ; conserver la référence en production |
| Refuser ou revenir en arrière | 75 acceptées et $2.44, ou toute écriture en double/non autorisée | Restaurer la configuration de référence et diagnostiquer la couche défaillante |
Le retour arrière restaure ensemble modèle, endpoint, effort, schéma d’outils et analyseur. Vérifiez l’état des actions avant de retenter avec un autre modèle pour éviter les effets secondaires en double. Une passerelle unifiée conserve des choix de modèles ; les règles des routes et la sémantique de nouvelles tentatives nécessitent encore leurs propres contrôles.
Quand conserver GPT-6 Sol est préférable
Gardez la référence tant qu’un client dépendant d’outils ne peut pas utiliser une route Responses vérifiée, que les fonctions ou la facture de la nouvelle route restent non vérifiées, ou que l’essai échoue aux seuils de qualité et de latence. Une charge avec peu de cache et beaucoup de sortie peut peu gagner sur les tarifs directs. Si le modèle actuel réussit déjà les tâches courantes avec peu de reprises, privilégiez un essai ciblé sur les tâches difficiles plutôt qu’une migration générale.
Ne déclarez pas 6 Sol obsolète simplement parce que 6.1 Sol est plus récent. Les documentations distinguent les modèles ; cet article ne dispose d’aucune consigne confirmée d’arrêt de l’ancienne route. Gardez l’identifiant exact disponible jusqu’à ce qu’un motif documenté justifie le changement.
FAQ
GPT-6.1 Sol coûte-t-il moins cher que GPT-6 Sol ?
Aux tarifs catalogue OpenAI Standard pour entrées courtes, entrées ordinaires et sorties sont inchangées ; les lectures du cache coûtent moitié moins. Le coût total dépend du cache, des sorties, des nouvelles tentatives et des résultats acceptés. Les tarifs EvoLink doivent être vérifiés séparément.
Peut-on migrer en changeant seulement l’identifiant ?
none exige une migration d’endpoint et de raisonnement.GPT-6.1 Sol prend-il en charge le raisonnement none ?
low, medium, high, xhigh et max, avec medium par défaut. Ni none ni minimal ne sont pris en charge.Le nouveau Sol a-t-il un contexte plus grand ?
Non. Les deux références indiquent 1,050,000 tokens de contexte et 128,000 de sortie maximale. Ne confondez pas budget partagé et entrée maximale.
GPT-6.1 Sol est-il disponible via EvoLink ?
Au 29 septembre, cet article n’a vérifié ni cette route, ni ses fonctions, ni ses tarifs de vente. Consultez le catalogue et la documentation avant une configuration propre à la passerelle.
Quel indicateur de migration est le plus utile ?
Le coût par tâche acceptée, avec qualité, latence et règles de rejet des actions dangereuses. Incluez échecs et coûts de repli, et gardez visible le temps de revue. Une réponse réussie moins chère ne suffit pas si elle ne résout pas la tâche.
Sources
- Documentation GPT-6.1 Sol — nouvelles règles et limites.
- Documentation GPT-6 Sol — règles et limites de référence.
- Tarification API OpenAI — tarifs Standard, cache et conditions des entrées longues.
- Annonce de GPT-6.1 Sol — présentation du lancement et évaluations du fournisseur ; pas une reproduction EvoLink.
Sources officielles vérifiées le 29 septembre 2026. Les exemples sont des calculs illustratifs et des méthodes de test, pas des usages mesurés ni une garantie d’économies.
