Claude Sonnet 5.5 ou GPT-6 Sol : le même tarif ne paie pas le même travail

Pour choisir entre Claude Sonnet 5.5 et GPT-6 Sol sur des tâches de code, comparez le coût des correctifs acceptés plutôt que le seul prix par jeton. Sur des demandes courtes, la qualité du résultat et l’intégration de l’agent peuvent départager les deux modèles. Quand chaque appel transporte une grande partie du dépôt, le barème du contexte long peut faire pencher la facture vers Sonnet.

La fiche de Claude Sonnet 5.5 indique 2 dollars par million de jetons en entrée et 10 dollars en sortie, avec un contexte d’un million de jetons et une sortie maximale de 128 000 jetons. La fiche de GPT-6 Sol affiche les mêmes tarifs de base, un contexte de 1 050 000 jetons et une sortie maximale de 128 000 jetons ; au-delà de 272 000 jetons d’entrée, elle double les tarifs de l’entrée et du cache et multiplie celui de la sortie par 1,5 pour toute la requête.

Le seuil de contexte long change le calcul

Le supplément de Sol porte sur l’ensemble de l’appel dès que son entrée dépasse le seuil, et pas uniquement sur les jetons supplémentaires. Dans un agent de code, l’entrée facturée peut comprendre les consignes, les fichiers sélectionnés, l’historique et les résultats d’outils renvoyés au modèle. La taille du dépôt, prise isolément, ne donne donc pas le prix d’une requête : seule compte la quantité effectivement transmise à chaque tour.

Voici un exemple conditionnel, sans cache ni frais d’outils : avec 300 000 jetons d’entrée et 5 000 jetons de sortie, les tarifs publiés donnent 0,65 dollar pour Sonnet et 1,275 dollar pour Sol. Le second montant additionne 1,20 dollar d’entrée et 0,075 dollar de sortie, puisque les multiplicateurs s’appliquent à la requête entière. Ce calcul maintient artificiellement les mêmes volumes de jetons pour isoler l’effet du tarif ; les deux modèles peuvent consommer des quantités différentes pour accomplir le travail.

Avec une entrée conditionnelle de 50 000 jetons et une sortie de 3 000 jetons, le même calcul sans cache donne 0,13 dollar pour chacun. L’écart dépend donc de la répartition réelle des appels, particulièrement près du seuil de Sol. Une requête initiale courte peut aussi être suivie d’appels plus longs si l’agent réinjecte des fichiers ou conserve un historique devenu volumineux.

Le cache et l’effort modifient la facture d’une session

Les tarifs de lecture du cache sont égaux à 0,20 dollar par million de jetons pour les deux modèles, mais leur application dépend de ce qui est effectivement réutilisé. Sonnet affiche une écriture à 2,50 dollars pour une conservation de cinq minutes et à 4 dollars pour une heure ; Sol affiche une écriture à 2,50 dollars, soumise elle aussi au multiplicateur si l’appel franchit son seuil de contexte long. Une session avec des consignes stables et des fichiers répétés n’a donc pas le même profil qu’une succession de requêtes entièrement nouvelles.

Pour comprendre ce profil, il faut séparer, à chaque appel, l’entrée ordinaire, l’écriture du cache, sa lecture et la sortie. Un cache fréquent peut alléger l’entrée répétée ; un préfixe qui change souvent limite ce bénéfice et peut entraîner de nouvelles écritures. Le prix affiché pour les jetons mis en cache n’est pas une réduction automatique de tous les fichiers transmis à l’agent.

L’effort de raisonnement ajoute une autre variable. Un réglage plus élevé peut aider sur une modification difficile, tout en augmentant les jetons produits et la latence. Les niveaux portant le même nom chez Anthropic et OpenAI ne représentent pas une quantité commune de calcul : une comparaison sérieuse conserve pour chaque configuration son usage mesuré et le résultat obtenu, au lieu de supposer que deux réglages « high » sont équivalents.

La qualité se juge sur le correctif accepté

Dans l’évaluation d’Artificial Analysis, Sonnet 5.5 au niveau d’effort maximal a produit environ 193 000 jetons de sortie par tâche de son indice d’intelligence ; au niveau « high », son rapport entre score et coût par tâche se situe très près de celui de GPT-6 Sol. L’évaluation portait sur une version préliminaire de Sonnet affectée par un défaut touchant les sorties structurées, corrigé pour la version publique. Ces résultats décrivent les tâches et les configurations du banc d’essai, pas le taux de correctifs acceptés dans un dépôt donné.

Pour une équipe qui corrige du code, le dénominateur utile est le nombre de tâches satisfaisant les mêmes critères d’acceptation. Le coût par tâche acceptée inclut les appels des tentatives réussies, les reprises et les échecs, puis divise cette dépense par le nombre de résultats validés. Un appel peu coûteux peut perdre son avantage si la modification doit être régénérée ou largement reprise par un développeur.

La revue humaine mérite une mesure distincte de la facture API. Une correction qui passe les tests mais modifie des fichiers sans rapport avec la demande peut prendre davantage de temps à examiner ; une proposition ciblée peut être plus simple à accepter même si son appel coûte plus cher. Une régression localisée, une modification répartie sur plusieurs fichiers et une revue de code sollicitent aussi des capacités différentes : les réunir dans une moyenne unique masquerait la charge de travail qui fait réellement varier le choix.

L’intégration de l’agent compte dans le choix

Passer à Sonnet 5.5 dans un agent Claude existant demande une vérification de compatibilité. Les changements décrits par Anthropic remplacent notamment « disabled » par « between_tools » pour désactiver le raisonnement initial et rejettent certains choix forcés d’outil. Les blocs de raisonnement sont également liés au modèle et à la conversation, ce qui touche les applications qui reconstruisent ou modifient l’historique avant de le renvoyer.

Du côté de Sol, le point d’accès choisi détermine ce que peut faire la boucle d’agent. La liste de déploiement d’OpenAI recommande la Responses API pour le raisonnement avec outils ; avec GPT-6 Sol, Chat Completions ne prend en charge les appels de fonctions que lorsque l’effort de raisonnement est réglé sur « none ». Comparer un agent doté d’outils dans Responses à une autre configuration sans relever cette différence reviendrait à mesurer aussi l’orchestration.

Les coûts d’intégration sont particulièrement visibles pour un service déjà en production : adapter le client, traiter les réponses d’outils et préserver correctement l’état de la conversation prennent du temps. Ils peuvent justifier de commencer par le modèle déjà relié à l’application, puis de changer si l’autre améliore assez les résultats pour compenser ce travail. Cette préférence initiale relève de l’organisation du service, pas d’un classement général des modèles.

Quel modèle retenir selon la charge de travail ?

Pour des corrections courtes et répétitives, les prix d’entrée et de sortie ordinaires ne désignent aucun gagnant. Le meilleur choix est celui qui fournit le plus régulièrement des modifications acceptées avec peu de reprises dans l’intégration utilisée. Pour les agents qui retransmettent souvent de larges portions d’un dépôt, Sonnet présente un avantage tarifaire possible sur les appels dépassant le seuil de Sol, même si une meilleure réussite de Sol pourrait compenser ce surcoût.

Pour une tâche longue et complexe, la décision dépend davantage de la quantité de raisonnement et de sortie nécessaire pour atteindre un résultat acceptable. Une grille utile regroupe par type de tâche la taille des appels, les lectures et écritures du cache, les reprises, le temps de revue et le nombre de correctifs validés. C’est ce coût par résultat, accompagné de la qualité du correctif et des contraintes de l’agent, qui indique ce que paie réellement chaque tarif identique en apparence.

À lire aussi :

• GPT‑5.6 Sol ou Claude Fable 5 : un point d’écart, deux coûts très différents
• Claude Fable 5.1 baisse le cache de 75 %, pas le tarif des jetons
• Tarif d’un influenceur : l’engagement ne suffit pas à fixer le prix