Un même texte, soumis à deux modèles, est découpé en 766 tokens par l'un et en 1170 par l'autre.
Celui qui a partagé ces chiffres est Tibo, responsable d'OpenAI Codex.
Sa déclaration est la suivante : un token d'OpenAI n'est pas égal à un token d'un autre modèle. Un prix unitaire plus bas par token ne signifie pas nécessairement une facture plus basse.
Tout le monde compare les prix en « dollars par million de tokens », comme si le token était une unité standard telle que le gramme ou le kilowattheure, mais ce n'est pas le cas.
Pour rendre cela plus compréhensible, il a raconté une histoire de pizza.
Deux pizzas identiques.
La première est coupée en 8 parts, chacune à 2 dollars. La seconde en 16 parts, chacune à 1,25 dollar. La seconde affiche un prix au morceau plus bas, mais la pizza entière coûte 20 dollars, alors que la première n'en coûte que 16.
Il a ajouté : votre estomac ne se soucie pas du nombre de parts que vous venez de manger.
Chaque part est moins chère, mais la pizza entière est plus coûteuse. La méthode de découpe étant différente, le prix unitaire perd toute comparabilité.
Le token est l'unité minimale de facturation pour un modèle, on peut le comprendre comme la « technique de découpe » du texte par le modèle.
Pour un même passage, des techniques de découpe différentes produisent un nombre de morceaux différent. On facture en fonction du nombre de morceaux découpés. Plus il y a de morceaux, plus la facture est élevée.
Cette comparaison couvre l'anglais, les textes techniques, le multilinguisme et le contenu numérique.
Le tokenizer de GPT-5.6 Sol utilise 766 tokens, tandis que l'estimation de Claude Opus 5 donne 1170 tokens.
Pour le même texte, la technique de découpe de GPT-5.6 Sol produit 34,5 % de morceaux en moins.
Et le prix d'entrée des deux modèles est de 5 dollars par million de tokens.
Le prix unitaire est identique, le nombre de morceaux est inférieur de 30 %, donc les frais d'entrée sont également inférieurs de 30 %.
Et c'est là que réside le problème.
Si même la définition de « la taille d'un token » n'est pas alignée entre les différentes entreprises, alors ce fameux tableau comparatif des prix d'API que tout le monde partage quotidiennement, a-t-il encore une quelconque validité ?
Pourquoi deux comptes différents pour le même texte ?
C'est parce que l'unité « token » n'a tout simplement pas d'unité de mesure uniforme.
Chaque fournisseur entraîne son propre tokenizer et décide lui-même de la taille des fragments dans lesquels le texte est découpé.
Pour les mots courants, le tokenizer les avale entiers ; pour les mots rares, un seul mot peut être divisé en trois ou quatre morceaux.
Prenons l'anglais pour un exemple plus intuitif. Des mots comme *the*, *and*, *is* apparaissent tous les jours, le tokenizer leur attribue un identifiant dédié, chaque mot est un token.
Pour un mot long comme *unbelievable*, il faut le diviser en *un*, *believ*, *able*, un seul mot occupe ainsi trois tokens.
Le principe est simple : le tokenizer est déduit statistiquement du corpus d'entraînement. Les combinaisons fréquentes obtiennent une place individuelle. Le reste doit être assemblé à partir de fragments.
Donc, « combien de tokens contient un passage » revient essentiellement à demander « les éléments de ce passage sont-ils courants dans le corpus de cette entreprise ? ».
Et la prose anglaise est précisément la catégorie de contenu où les différences sont les plus faibles. Pour du code, du JSON, de longues séries de chiffres, l'écart entre les découpages des deux entreprises ne fera que s'accroître.
Même les anciens et nouveaux modèles d'une même entreprise ne peuvent partager le comptage
Ce n'est pas un problème propre à une entreprise.
La documentation d'Anthropic le précise clairement : le comptage de tokens est une estimation, le nombre réel de tokens d'entrée utilisés lors de la création d'un message peut varier légèrement.
Elle donne même un chiffre concret.
Les modèles Claude 4.7 et ultérieurs utilisent un nouveau tokenizer. Pour le même texte d'entrée, ils produisent environ 30 % de tokens en plus que les modèles antérieurs, l'augmentation précise dépendant du contenu et de la forme de la charge de travail.
Documentation officielle d'Anthropic : Les modèles Claude 4.7 et suivants utilisent un nouveau tokenizer. Pour le même texte, le nombre de tokens est environ 30 % plus élevé. Ne réutilisez pas les comptages mesurés sur les anciens modèles.
Une même entreprise, un même texte, et après une génération, le compte augmente de 30 %.
C'est pourquoi la recommandation officielle est la suivante : pour connaître la différence pour votre charge de travail, comptez le même requête une fois pour chaque modèle et comparez les *input_tokens* retournés.
N'utilisez pas les chiffres mesurés sur les anciens modèles pour estimer les coûts.
Même entre deux générations de modèles d'une même entreprise, les comptages ne sont pas réutilisables. Comparer directement les prix « par million de tokens » entre différents fournisseurs est donc encore moins standardisé.
À 5 dollars chacun, les factures diffèrent en quatre points
Même prix unitaire, même entrée, où se situent les différences sur la facture ?
Premier point, l'efficacité du tokenizer, déjà évoquée. Un même texte, découpé en un nombre de tokens différent, multiplié par le même prix unitaire, donne naturellement un montant payé différent.
Deuxième point, le cache.
Le prix d'entrée en cache pour GPT-5.6 Sol est de 0,50 dollar par million de tokens, seulement un dixième du prix d'entrée standard. Pour les charges de travail avec de nombreux préfixes répétés, cet élément peut modifier toute la structure de la facture.
Troisième point, la sortie.
La sortie de GPT-5.6 Sol coûte 30 dollars par million de tokens, celle de Claude Opus 5 démarre à 25 dollars.
Et dans les flux de travail réels d'agents intelligents, le poids des tokens de sortie est souvent plus important que celui des tokens d'entrée.
Cela signifie que les 34,5 % économisés précédemment pourraient facilement être reperdus ici.
Quatrième point, le plus facilement négligé, il est pourtant écrit sur la page du modèle OpenAI lui-même. Lorsque l'entrée de GPT-5.6 Sol dépasse 272K tokens, l'entrée de l'ensemble de la requête est facturée au double, et la sortie à 1,5 fois le tarif.
Page officielle du modèle GPT-5.6 Sol : Entrée 5 dollars, Entrée cache 0,50 dollar, Sortie 30 dollars. La petite ligne en bas indique les règles de majoration au-delà de 272K.
Il ne s'agit pas d'une majoration sur la partie dépassante, mais de l'application d'un taux plus élevé à l'ensemble de la requête.
Un même code, si vous l'interrogez dans un contexte de 270 000 tokens ou dans un contexte de 280 000 tokens, le prix unitaire change de palier.
Cette limite provient de la page tarifaire officielle de l'entreprise elle-même : plus le contexte est long, plus les coûts d'attention et de mémoire vive augmentent rapidement. Une fenêtre contextuelle longue n'a jamais été gratuite.
La fenêtre du million est ouverte, l'argent s'écoule lentement
Tibo a ensuite publié un second message, expliquant comment ouvrir manuellement la fenêtre contextuelle au maximum dans Codex.
Ouvrez ~/.codex/config.toml, ajoutez trois lignes avant tous les titres de section :
model = "gpt-5.6-sol"
model_context_window = 1000000
model_auto_compact_token_limit = 900000
La première ligne sélectionne le modèle, la deuxième étend le budget de contexte à 1 million de tokens, la troisième déclenche la compression automatique autour de 900 000 tokens, laissant une petite marge.
Sauvegardez, redémarrez le client, ouvrez une nouvelle session, la configuration prendra alors effet.
Pour ceux qui ne veulent pas modifier les valeurs par défaut, il est également possible de les remplacer temporairement pour une seule session CLI :
codex -m gpt-5.6-sol
-c model_context_window=1000000
-c model_auto_compact_token_limit=900000
Ces deux clés sont documentées dans la référence de configuration officielle de Codex, leur fonction correspond à ce qu'il a écrit.
model_context_window, le nombre de tokens de la fenêtre contextuelle disponible pour le modèle actuel.
model_auto_compact_token_limit, le seuil de déclenchement de la compression automatique de l'historique.
Mais la documentation ne fait que définir la signification des clés, elle ne liste pas les valeurs « 1 million/900 000 » comme recommandation générale.
Tibo lui-même a ajouté à la fin de son message : les valeurs par défaut ont été soigneusement ajustées par eux.
Alors pourquoi tant de gens veulent-ils les modifier manuellement ?
Un rapport d'utilisateur sur GitHub en explique la raison.
Ce rapport de test dans le dépôt openai/codex : Le répertoire Codex limite la fenêtre à 372K, effective à 353,4K, alors que les spécifications du modèle indiquent 1,05M
Avec une version spécifique du client Codex et un compte ChatGPT Pro, la fenêtre indiquée pour gpt-5.6-sol dans le répertoire des modèles est de 372K, avec 95 % d'utilisation effective, soit 353,4K réellement disponibles. Alors que la page officielle du modèle annonce 1,05M.
On paie pour une fenêtre d'un million, on n'en utilise qu'un tiers.
Ce rapport est limité à des versions et comptes spécifiques, il ne peut être considéré comme l'état actuel pour tous les utilisateurs, et le message de configuration de Tibo a été publié plus tard.
Il faut également clarifier un point : modifier la configuration à 1 million ne génère pas immédiatement des frais pour 1 million de tokens. Ce qui est facturé, c'est toujours le volume réel traité.
Cependant, pousser le seuil de compression jusqu'à 900 000 signifie qu'une longue session va porter un historique de plus en plus long à chaque tour, chaque requête devant repasser par cet historique.
Plus la fenêtre est grande, plus la compression est tardive, plus la requête risque de franchir le seuil des 272K mentionné précédemment.
Dans des dialogues courts, les différences de tokenizer sont négligeables. Mais lorsque la session atteint des centaines de milliers de tokens, que l'historique est retraité à chaque fois, multiplié par un taux majoré, la différence passe après la virgule à avant la virgule.
L'argent n'est pas dépensé d'un coup, il augmente tour après tour.
La prochaine unité, c'est le « coût par réussite »
Dans le message de Tibo, il y avait aussi une phrase, éclipsée par les chiffres : ce qui compte vraiment, c'est le coût par résultat réussi (*price per successful outcome*).
Il a également donné la méthode. Les benchmarks peuvent servir de point de départ, mais pour savoir vraiment si c'est cher, il faut exécuter sa propre tâche.
Cette phrase change le point d'ancrage de la comparaison. On passe de « combien coûte un million de tokens » à « combien coûte au total l'exécution de la même tâche ».
Pour savoir lequel des deux modèles est vraiment moins cher pour votre usage, il suffit de les tester vous-même.
Prenez le même texte source, la même répartition linguistique, les mêmes définitions d'outils, appelez les interfaces de comptage officielles des deux entreprises pour obtenir le nombre réel de tokens, ajoutez le cache, la longueur de sortie, la longueur d'inférence et les majorations de contexte long, et comparez enfin lequel permet d'accomplir la tâche pour moins cher.
L'efficacité du tokenizer n'est que le premier maillon de cette chaîne. Un modèle qui tokenise plus efficacement peut tout de même voir sa facture dépasser celle d'un autre s'il est verbeux en inférence ou nécessite de nombreuses réitérations.
À l'avenir, la question ne devrait plus être « combien coûte un million de tokens », mais « combien coûte la correction de ce bug ».
Références :
https://x.com/thsottiaux/status/2089082893804896524?s=20
https://x.com/thsottiaux/status/2088866513008873560?s=20 https://github.com/openai/codex/issues/31860
Cet article provient du compte public WeChat « New Zhiyuan », auteur : ASI Apocalypse
