Token counter : compteur et calculateur de tokens IA (2026)

Ce qu'est un token

Le compteur compte des tokens. Voici ce que c'est et pourquoi le même texte n'en fait pas le même nombre partout.

Un modèle d'IA ne lit pas un texte lettre par lettre. Avant de lui donner ton texte, un programme le découpe en morceaux. Ce programme s'appelle un tokenizer et chaque morceau s'appelle un token. Le tokenizer prend ses morceaux dans une liste fixe. Chaque tokenizer a sa liste. Un même fournisseur peut en avoir plusieurs : Mistral AI en a un par modèle.

Un mot fréquent est un seul morceau, en général avec l'espace qui le précède. Un mot moins fréquent se coupe en plusieurs morceaux. Les chiffres et la ponctuation ont aussi leurs morceaux.

Voici comment le tokenizer d'OpenAI découpe une courte demande. Une barre marque chaque coupure :

R|éd|ige| une| réponse| courte| à| la| demande| de| remboursement| de| ce| client|.

Cette demande de 12 mots fait 15 tokens. La plupart des mots font un seul token, avec l'espace qui les précède. Le point final fait un token à lui seul. Le mot « Rédige », lui, se coupe en trois tokens, alors que « remboursement », plus long, n'en fait qu'un. Ce n'est pas la longueur du mot qui compte : la liste garde en un seul morceau les mots qui revenaient souvent dans les textes ayant servi à la construire. « Rédige » y revenait moins souvent.

Un modèle voit donc des tokens, jamais les lettres qu'ils contiennent. Andrej Karpathy, l'un des fondateurs d'OpenAI, en tire une conséquence dans un cours de 2025 sur le fonctionnement de ChatGPT : c'est pour cela que les modèles se trompent souvent quand on leur demande d'épeler un mot ou d'en compter les lettres.

La liste qu'OpenAI publie pour ses modèles depuis GPT-4o s'appelle o200k, pour les quelque 200 000 morceaux qu'elle contient. Le mot anglais « template » y est un seul token. Avec deux lettres inversées, « tempalte » en fait deux : une faute de frappe coûte en général des tokens en plus.

En mai 2026, Pankaj Pipada, qui conçoit des logiciels, a mesuré ce que coûtent les fautes de frappe avec le tokenizer d'OpenAI. Un message de cinq mots avec deux fautes faisait 13 tokens. Une fois les fautes corrigées, le même message n'en faisait plus que 6.

D'où vient la liste de morceaux ? Le savoir aide à comprendre pourquoi un même texte ne coûte pas pareil partout. La plupart des listes sont construites avec une méthode appelée l'encodage par paires (byte-pair encoding en anglais) : elle assemble en morceaux plus longs les lettres qui reviennent souvent ensemble. L'informaticien Philip Gage l'a publiée en 1994, pour réduire la taille des fichiers de données. En 2016, Rico Sennrich et ses coauteurs, chercheurs en traduction automatique, l'ont reprise pour que leurs modèles de traduction sachent lire des mots qu'ils n'avaient jamais vus.

La méthode part des lettres seules. Elle repère dans un grand ensemble de textes les deux morceaux qui se suivent le plus souvent et les réunit en un seul morceau. Elle recommence jusqu'à ce que la liste atteigne la taille voulue. Un mot jamais vu se découpe alors en morceaux plus petits, au besoin jusqu'aux lettres : le modèle peut tout lire, mais un mot rare coûte plusieurs tokens.

Chaque fournisseur construit sa liste à partir de ses propres textes. C'est pour cela que le même texte ne fait pas le même nombre de tokens d'un fournisseur à l'autre. Plus la liste est grande, plus elle contient de morceaux longs. Il faut alors moins de morceaux pour écrire le même texte.

Les modèles récents ont des listes plus grandes que les anciens. Est-ce que cela fait baisser la facture ? Pour le vérifier, on peut compter le même texte avec une ancienne et une nouvelle liste d'OpenAI. Le faire en anglais et en français montre en plus si l'effet dépend de la langue. Il faut pour cela un texte publié dans les deux langues : le gouvernement du Canada publie ainsi son guide sur l'IA générative en anglais et en français.

Le 29 octobre 2026, un test fait pour cette page a compté le début du guide canadien avec deux listes d'OpenAI. La première est celle de GPT-4, un modèle d'OpenAI sorti en 2023 : elle contient 100 277 morceaux. La seconde est o200k, qui en contient deux fois plus. En anglais, les deux listes donnaient presque le même nombre de tokens : 1 315 avec celle de GPT-4, 1 306 avec o200k. L'ancienne liste gardait déjà presque tous les mots anglais en un seul morceau.

En français, la liste de GPT-4 donnait 2 229 tokens et o200k 1 807, soit 19 % de moins. La réponse à la question est donc : pour un texte anglais, presque rien ne change. Pour un texte français, la facture baisse d'environ 19 %.

Combien de tokens fait un texte ? Avec le tokenizer d'OpenAI, 1 000 mots anglais font environ 1 190 à 1 250 tokens. Pour 1 000 mots français, il en faut environ 1 380 à 1 480. Ces chiffres viennent des textes comptés pour cette page le 29 octobre 2026 : le guide canadien, la Déclaration universelle des droits de l'homme et un passage d'un guide de ce site. Dans les textes anglais, chaque token faisait en moyenne environ cinq caractères, espaces compris.

On lit souvent une autre règle : 0,75 mot par token, soit 75 mots pour 100 tokens. Cette règle date de tokenizers plus anciens que celui de GPT-4, comme celui de GPT-3. Elle compte donc trop de tokens pour les tokenizers d'aujourd'hui. Pour 1 000 mots anglais, elle en donne environ 1 333 (1 000 ÷ 0,75). C'est 7 à 12 % de plus que ce que compte o200k. Anthropic donnait d'ailleurs cette même règle pour Claude jusqu'en avril 2026. Selon sa documentation, 1 000 mots anglais font désormais environ 1 800 tokens chez Claude.

Pourquoi le français et le code coûtent plus de tokens

Un même message ne fait pas le même nombre de tokens en français et en anglais, ni en prose et en code. Ce chapitre dit de combien et pourquoi.

Écrite en anglais, la demande « Rédige une réponse courte… » se découpe ainsi :

Write| a| short| reply| to| this| customer's| refund| request|.

En anglais, la demande fait 10 tokens pour 9 mots : chaque mot y est un seul token. En français, elle en faisait 15 pour 12 mots. La raison tient aux textes qui servent à construire la liste : chez la plupart des fournisseurs, ils sont surtout en anglais. Une langue que la liste a moins vue se coupe en morceaux plus petits, si bien que le même message coûte plus de tokens en français qu'en anglais.

Andrej Karpathy prend l'exemple du japonais dans un autre cours, de deux heures, sur la construction d'un tokenizer : si les textes qui servent à construire la liste contiennent beaucoup de japonais, la liste garde des morceaux japonais plus longs et une phrase japonaise demande moins de tokens. Le coût d'une langue dépend donc des textes avec lesquels la liste a été construite.

De combien le français coûte-t-il plus cher ? Pour le mesurer, il faut compter le même contenu dans les deux langues. Le 29 octobre 2026, pour cette page, deux textes publiés officiellement en anglais et en français ont été comptés : le guide canadien et la Déclaration universelle des droits de l'homme, que l'ONU publie aussi dans les deux langues.

Avec le tokenizer d'OpenAI, la version française demandait 1,38 fois plus de tokens que l'anglaise pour le guide canadien et 1,29 fois plus pour la Déclaration.

Une partie de cet écart vient de la langue elle-même : pour dire la même chose, les versions françaises utilisaient 11 à 21 % de mots en plus. Le reste vient du tokenizer. Comme chaque fournisseur a le sien, le surcoût du français change d'un fournisseur à l'autre.

Sur ces deux textes, le tokenizer d'OpenAI demandait 1,29 à 1,38 fois plus de tokens en français qu'en anglais. Chaque tokenizer donne un écart un peu différent. Le plus faible est celui de Mistral Large 4, un modèle de l'entreprise française Mistral AI, avec 1,24 à 1,33 fois plus de tokens en français. Celui de Mistral Small 4, compté le 2 novembre 2026, donnait 1,29 à 1,41. Le plus fort est celui de DeepSeek, un laboratoire d'IA chinois : 1,47 à 1,62.

Google ne publie pas le tokenizer de Gemini. Il publie celui de Gemma, un modèle en accès libre. Sur ces deux textes, le tokenizer de Gemma demandait 1,33 à 1,43 fois plus de tokens en français qu'en anglais.

Gemini lui-même a été compté avec le service de Google le 2 novembre 2026. Il fait environ 1,05 fois le nombre de tokens d'OpenAI en anglais et environ 1,06 fois en français. Les deux chiffres sont presque égaux : le français coûte donc à Gemini le même supplément qu'à OpenAI, à peu de chose près.

Ce surcoût du français était plus fort avec les anciens tokenizers. En 2023, une étude d'Aleksandar Petrov et de ses coauteurs, présentée à NeurIPS, l'une des principales conférences de recherche en IA, trouvait que le français demandait 1,60 fois plus de tokens que l'anglais avec le tokenizer de GPT-4. Avec celui de GPT-2, un modèle d'OpenAI sorti en 2019, c'était 2,00 fois plus.

La même année, une autre étude, menée par Orevaoghene Ahia et ses coauteurs, trouvait des langues qui demandaient cinq fois plus de tokens que d'autres pour le même contenu. Ceux qui parlent les langues les plus coûteuses « paient plus cher pour de moins bons résultats », concluaient les auteurs, puisque les modèles traitent aussi moins bien ces langues. Dans cette étude, le français faisait partie des langues les moins chères, mais il restait plus cher que l'anglais.

Chez Claude, l'écart entre français et anglais est plus grand que chez OpenAI. TextKit, un éditeur d'outils pour le texte, a compté un passage anglais de 94 mots et sa traduction française, chez OpenAI puis chez Claude. Chez OpenAI, la version française faisait 1,39 fois plus de tokens que l'anglaise. Chez Claude, elle en faisait environ 1,55 fois plus, un chiffre calculé à partir de ceux de TextKit.

Sur la version anglaise, Claude comptait 1,61 fois plus de tokens qu'OpenAI. Sur la version française, il en comptait 1,80 fois plus. Le surcoût de Claude est donc plus fort en français qu'en anglais. Pour obtenir le 1,55, on part de l'écart d'OpenAI entre français et anglais, 1,39. On le multiplie par le surcoût de Claude en français, puis on le divise par son surcoût en anglais : 1,39 × 1,80 ÷ 1,61 = 1,55.

Les rapports entre français et anglais disent combien un texte français coûte de plus que le même texte en anglais.

Pour choisir un fournisseur, une autre comparaison compte : le même texte français chez Claude et chez OpenAI. D'après les mesures faites pour cette page, Claude compte environ 1,75 fois plus de tokens qu'OpenAI sur un texte français, contre 1,5 fois sur un texte anglais. Ce sont les multiplicateurs qu'utilise le compteur pour Claude.

Noxcod, une agence française qui construit des agents IA, trouve presque le même écart en français. En octobre 2026, elle a compté 2,5 tokens Claude par mot français, contre 1,44 tokens OpenAI : Claude en compte donc 1,74 fois plus (2,5 ÷ 1,44).

Cet écart compte, parce que deux modèles comparables peuvent avoir le même prix par token. Le 29 octobre 2026, Claude Sonnet 5.5 (un modèle d'Anthropic) et GPT-6.1 Sol (un modèle d'OpenAI) avaient le même prix affiché, c'est-à-dire le même prix par token sur la page du fournisseur : 2 $ le million de tokens envoyés au modèle et 10 $ le million de tokens qu'il écrit en réponse.

Pour un assistant de service client en français, Noxcod en tirait cette conclusion : « À tarif affiché égal, le même assistant en français coûte donc 75 % de plus chez Anthropic. » Ces 75 % viennent de l'écart que Noxcod a mesuré : 1,74 fois plus de tokens, c'est-à-dire 74 % de plus, arrondis à 75 %.

Un détail de la typographie française compte aussi. En français, on met une espace insécable avant les deux-points et à l'intérieur des guillemets : c'est une espace qui empêche de couper la ligne à cet endroit. Une espace ordinaire ne coûte rien de plus : elle fait partie du token du mot qui la suit.

Une espace insécable, elle, coûte des tokens. Dans un paragraphe français compté le 29 octobre 2026, chacune des onze espaces insécables coûtait un token chez OpenAI et deux chez Gemma. Si ton appli envoie des textes mis en forme pour le français, demande à ton agent : « Remplace les espaces insécables par des espaces ordinaires dans ce que l'appli envoie au modèle. »

Le code et les données structurées ont leur propre surcoût : ils sont pleins de symboles et d'espaces de mise en page. Les données structurées, ce sont les informations que les applis s'échangent dans un format fixe, comme le JSON. Pour être lisibles, le code et le JSON s'écrivent souvent sur plusieurs lignes, avec des espaces en début de ligne. Ces espaces en début de ligne n'ont pas de mot à accompagner : ils coûtent des tokens, comme chaque accolade et chaque guillemet.

Le test du 29 octobre 2026 sur le guide canadien et la Déclaration comprenait aussi un fichier JSON de 43 lignes, écrit pour ce test. Avec le tokenizer d'OpenAI, ce fichier écrit sur plusieurs lignes coûtait 56 % de tokens de plus que le même contenu écrit sur une seule ligne.

Les fournisseurs ne découpent pas non plus le code de la même façon les uns que les autres : d'après le décompte de Google sur les textes de cette page, Gemini fait environ 1,15 fois le nombre de tokens d'OpenAI sur du code, contre 1,05 sur de la prose anglaise.

Si ton appli envoie des données à un modèle, demande à ton agent : « Envoie les données au modèle sur une seule ligne, sans espaces en début de ligne, avec seulement les informations dont il a besoin. »

Comment un appel est facturé

Savoir combien de tokens fait un texte ne suffit pas : il faut encore savoir comment ces tokens deviennent un prix. Ce chapitre suit le prix d'un appel, puis tout ce qui le fait varier.

Le prix d'un appel

Une fois connu le nombre de tokens, le prix suit une règle simple. Un appel a deux parties facturées séparément : le prompt et la réponse. Le prompt, c'est tout ce que ton appli envoie au modèle. La réponse, c'est ce que le modèle écrit. Les fournisseurs appellent aussi les tokens du prompt « tokens d'entrée » et ceux de la réponse « tokens de sortie ». Chaque partie a son prix, donné pour un million de tokens. Un appel coûte donc :

tokens du prompt ÷ 1 000 000 × prix du prompt + tokens de la réponse ÷ 1 000 000 × prix de la réponse

Prends GPT-6.1 Sol, un modèle d'OpenAI. Le 29 octobre 2026, il coûtait 2 $ le million de tokens de prompt et 10 $ le million de tokens de réponse. Un prompt anglais de 2 000 tokens et une réponse de 500 tokens coûtent 2 000 ÷ 1 000 000 × 2 $ = 0,004 $, plus 500 ÷ 1 000 000 × 10 $ = 0,005 $, soit 0,009 $ l'appel et 9 $ par mois pour 1 000 appels par mois.

Claude Sonnet 5.5, un modèle d'Anthropic, avait exactement le même prix ce jour-là. Mais il découpe le même texte anglais en environ 1,5 fois plus de tokens. Le même prompt y fait donc environ 3 000 tokens au lieu de 2 000. Une réponse de la même longueur en mots y fait environ 750 tokens au lieu de 500. Cet appel coûte 3 000 ÷ 1 000 000 × 2 $ + 750 ÷ 1 000 000 × 10 $ = 0,0135 $ l'appel, soit 13,50 $ pour 1 000 appels par mois.

Pour voir ces deux modèles côte à côte dans le compteur, laisse « Compter en tokens de » sur OpenAI : les nombres que tu tapes sont alors des tokens OpenAI. Sans coller de texte, tape 2 000 dans « Prompt » et choisis « Anglais » dans « Langue du texte » : le compteur en a besoin pour convertir ces tokens OpenAI en tokens de chaque autre modèle. La réponse est déjà réglée sur 500 et les appels sur 1 000 par mois.

Farmadupe, un utilisateur de Hacker News, un forum où les développeurs parlent de leur travail, a vu cet écart entre Claude et OpenAI sur une tâche réelle en octobre 2026 : il fallait classer des textes par catégorie. Pour les mêmes textes, GPT-6 Luna, d'OpenAI, a compté 7,90 millions de tokens de prompt et Claude Haiku 5.5 en a compté 11,89 millions, soit 1,5 fois plus (11,89 ÷ 7,90). Les deux modèles avaient le même prix affiché.

Farmadupe a trouvé GPT-6 Luna nettement moins cher, pour deux raisons : le même texte y faisait moins de tokens et les réponses de GPT-6 Luna étaient plus courtes.

La réponse coûte plus cher que le prompt

Sur chaque modèle du compteur, un token de réponse coûte plus cher qu'un token de prompt. C'est important pour une appli qui écrit de longues réponses à des prompts courts : sa facture vient surtout des réponses. L'écart varie beaucoup d'un modèle à l'autre. Le 29 octobre 2026, parmi les 16 modèles du tableau des prix, plus bas sur cette page :

Chez Gemini 3.5 Flash-Lite, une longue réponse pèse donc plus lourd, par rapport au prompt, que chez tous les autres modèles.

Les modèles qui réfléchissent

Certains modèles réfléchissent avant de répondre. Ils écrivent d'abord leur raisonnement, un brouillon que l'utilisateur ne voit pas, puis la réponse. Ce brouillon est facturé comme des tokens de réponse, donc au prix le plus cher.

OpenAI appelle ces modèles des modèles de raisonnement. Dans un exemple de son guide, la réponse facturée fait 1 186 tokens, dont 1 024 tokens de raisonnement. La réponse visible ne fait donc que 162 tokens (1 186 − 1 024). La réponse facturée est donc 7,3 fois plus longue que la réponse visible (1 186 ÷ 162 = 7,3).

Le guide d'OpenAI prévient qu'on peut même payer « les tokens d'entrée et de raisonnement sans recevoir de réponse visible ». Une appli fixe en général, pour chaque appel, un nombre maximal de tokens de réponse. Si la réflexion atteint ce maximum avant que la réponse ne commence, l'appel est payé sans réponse. La documentation de Google dit que chez Gemini aussi, le prix se calcule sur toute la réflexion, même quand le modèle n'en montre qu'un résumé.

Le 29 octobre 2026, la réflexion ne pouvait pas être désactivée sur Claude Opus 5.5, Grok 4.7 et Claude Fable 5.1, le modèle le plus cher d'Anthropic. Sur beaucoup d'autres modèles, le niveau de réflexion est un réglage. Tu peux demander à ton agent : « Règle le niveau de réflexion du modèle au plus bas qui donne encore de bonnes réponses. »

Le compteur n'a qu'un champ « Réponse » pour tous les modèles. Pour un modèle qui réfléchit, tape dans ce champ le nombre de tokens de la réponse plus celui de la réflexion. Lis ensuite seulement la ligne de ce modèle. Les autres lignes comptent elles aussi cette réflexion, alors que leurs modèles n'en écrivent peut-être pas.

Dans l'exemple d'OpenAI, la réponse facturée faisait 7,3 fois la réponse visible. Pour connaître cet écart dans ton appli, demande à ton agent : « Montre-moi les tokens de réponse facturés sur quelques appels réels, à côté de la longueur des réponses visibles. » Si ces tokens ne sont pas ceux d'OpenAI, choisis leur fournisseur dans « Compter en tokens de » avant de taper le chiffre.

La taille maximale et les prompts très longs

Chaque modèle accepte un prompt d'une taille maximale par appel. Cette limite vient de sa fenêtre de contexte, la quantité de texte que le modèle peut prendre en compte d'un coup. Le 29 octobre 2026, la limite était de 922 000 tokens pour les modèles GPT-6, 500 000 pour Grok 4.7, 256 000 pour Mistral Small 4 et environ un million pour les autres modèles. Au-delà, le fournisseur refuse l'appel et le compteur l'indique : « Trop long pour ce modèle ».

Chez certains modèles, un prompt très long fait aussi payer plus cher tout l'appel, au-delà d'un seuil. Le 29 octobre 2026, chez Claude Haiku 5.5, un appel dont le prompt dépassait 100 000 tokens payait cinq fois le prix normal sur tous ses tokens.

Chez les modèles GPT-6, un appel dont le prompt dépassait 272 000 tokens payait deux fois le prix normal du prompt et 1,5 fois celui de la réponse. Chez les modèles Grok, xAI doublait le prix du prompt et celui de la réponse dès 200 000 tokens de prompt. Le compteur applique ces prix plus élevés dès que le seuil est dépassé.

Ces limites et ces seuils se comptent dans les tokens de chaque fournisseur. Le compteur compare donc chacun à son décompte des tokens de ce fournisseur : pour Claude, à son estimation des tokens Claude. Prenons Claude Haiku 5.5, dont le prix plus élevé commence à 100 000 tokens Claude. Pour un texte anglais, cela fait environ 67 000 tokens OpenAI, car Claude compte environ 1,5 tokens pour chaque token OpenAI (100 000 ÷ 1,5).

Les promotions, le tableau des prix et les remises

Les prix promotionnels ont une date de fin. Le 29 octobre 2026, Gemini 4 Argon était à moitié prix jusqu'au 30 novembre 2026 et Gemini 3.8 Flash jusqu'au 31 décembre 2026. Le compteur passe au prix normal le lendemain de chaque date de fin, d'après la date de ton appareil. Pour prévoir les mois suivants, prends le prix normal indiqué dans le tableau des prix : Gemini 4 Argon et Gemini 3.8 Flash coûtent alors deux fois plus cher.

Les prix qu'utilise le compteur, vérifiés le 29 octobre 2026 :

Dollars par million de tokens, tarifs standard de chaque fournisseur, vérifiés le 29 octobre 2026.

Le cache, c'est le début d'un prompt que le fournisseur a déjà reçu lors d'un appel récent et qu'il garde un moment. Si l'appel suivant commence par le même texte, le fournisseur facture ce début à un prix réduit : c'est celui de la colonne « Prompt en cache » du tableau. Un tiret veut dire que le fournisseur n'affiche pas de prix réduit pour ce modèle.

Le 29 octobre 2026, tous les fournisseurs du tableau sauf DeepSeek faisaient aussi une remise sur les appels envoyés par lots et traités dans les 24 heures. Un lot, c'est un grand nombre d'appels envoyés d'un coup, pour un travail qui peut attendre. La remise était de moitié chez OpenAI, Anthropic, Google et Mistral AI. Elle était de 20 % chez xAI.

DeepSeek, lui, divisait ses prix par deux en dehors des heures de pointe. Le compteur n'applique aucune de ces remises, ni le prix du cache : il donne le prix normal et, pour DeepSeek, celui des heures de pointe. Avec le cache ou une remise, chaque modèle peut donc coûter moins que ce qu'affiche le compteur.

Ce qu'un appel envoie vraiment : toute la conversation

Dans les exemples précédents, le prompt était un seul bloc de 2 000 tokens. Dans une vraie appli, ce bloc contient bien plus qu'un message. Un modèle ne garde aucun souvenir d'un appel à l'autre : pour continuer une conversation, ton appli doit lui renvoyer toute la conversation à chaque appel, c'est-à-dire chaque message précédent, chaque réponse précédente, puis le nouveau message.

La documentation de DeepSeek le dit sans détour : il faut « concaténer tout l'historique de la conversation », c'est-à-dire le recoller en entier, puis l'envoyer à chaque appel. Les documentations d'OpenAI et d'Anthropic disent la même chose : chaque message précédent est facturé de nouveau comme tokens de prompt.

Une conversation fait donc payer bien plus de tokens qu'elle n'en contient. Imagine un chat où chaque tour, un message et sa réponse, ajoute 1 000 tokens. Le premier appel envoie environ 1 000 tokens, le deuxième 2 000 et le vingtième 20 000. En moyenne, chacun des vingt appels envoie donc 10 500 tokens ((1 000 + 20 000) ÷ 2), soit 210 000 tokens de prompt pour une conversation de 20 000 tokens (20 × 10 500).

Le texte fixe, celui qui ne change pas d'un appel à l'autre, est lui aussi renvoyé à chaque appel. Le prompt système, ce sont les instructions que ton appli donne au modèle avant chaque message de l'utilisateur : il est facturé à chaque appel. La description des outils l'est aussi. Les outils sont les actions que le modèle peut lancer, comme retrouver la commande d'un client ou chercher dans ton aide en ligne. Ton appli décrit chacun d'eux dans le prompt. Cette description se paie à chaque appel.

Certains fournisseurs ajoutent aussi leur propre texte. Le 29 octobre 2026, Anthropic ajoutait une consigne de 286 tokens à chaque appel de Claude Opus 5.5 qui utilisait des outils.

Ces tokens sont facturés comme le reste du prompt, sans que tu les aies écrits. Le compteur ne les ajoute pas. Si ton appli utilise des outils avec ce modèle, choisis Claude dans « Compter en tokens de » : « Prompt » est alors en tokens Claude. Lis le nombre de tokens Claude de ton texte dans « Tokens », puis tape dans « Prompt » ce nombre plus 286.

Le texte fixe peut peser bien plus que les réponses. Noxcod, l'agence qui a mesuré le surcoût de Claude en français, a construit un agent vocal, un assistant qui répond aux clients par téléphone. Chaque fois qu'il répond, cet agent fait un appel au modèle et envoie un prompt système de 11 000 tokens. Ses réponses sont environ 200 fois plus courtes que ce prompt. « Plus de 99 % des jetons facturés sont donc des jetons d'entrée », écrit Noxcod, jetons étant un autre mot pour tokens.

Pour chiffrer une fonctionnalité de ton appli, colle donc dans le compteur tout ce qu'un appel envoie, tel qu'il est au milieu d'une conversation typique : le prompt système, la description des outils et la conversation en cours. Si tu ne sais pas ce que ton appli envoie, demande à ton agent : « Montre-moi le texte complet qu'envoie un appel au modèle au milieu d'une conversation, avec le prompt système et les outils. »

Une fonctionnalité qui fait un seul appel à chaque demande de l'utilisateur, comme résumer un document, n'a pas d'historique à renvoyer. Pour elle, colle dans le compteur le document avec les instructions qui l'accompagnent.

Avec un agent IA, le texte fixe et la conversation sont renvoyés à chaque étape. Un agent IA est un programme qui mène seul une tâche en plusieurs étapes : un agent que ton appli fait tourner pour ses utilisateurs, ou un agent de code comme Claude Code, qui écrit le code d'un projet. Chaque étape (lire un fichier, lancer une commande, écrire une modification) est un appel. Chaque appel renvoie au modèle tout le contexte : les instructions, les fichiers déjà lus et la conversation.

Ce renvoi pèse lourd sur un mois. En mai 2026, Hitesh Jain, qui conçoit des outils IA chez Coral Bricks AI, a publié l'analyse d'un mois de son propre usage de Claude Code. À chaque étape, Claude Code envoyait au modèle un contexte d'environ 173 000 tokens en moyenne.

Sur le mois, le texte vraiment nouveau, ajouté au fil des étapes, faisait 29 millions de tokens. Mais 4,35 milliards de tokens avaient été envoyés au modèle : chaque token avait été renvoyé environ 150 fois en moyenne (4,35 milliards ÷ 29 millions = 150).

Ces tokens renvoyés faisaient presque tous les tokens du mois. Pourtant, ils ne pesaient que 64 % de la facture du mois, au prix de l'API. La raison : la plupart passaient par le cache, facturé à une fraction du prix normal. Le reste de la facture payait les réponses et le texte nouveau. Au prix affiché de Claude Opus 4.7, cache compris, le mois revenait à 3 371 $. Le résumé d'Hitesh Jain : « On ne paie pas pour générer, on paie pour relire. »

Ces coûts sont ceux de l'API. Ils disent ce que paie ton appli quand elle fait tourner un agent. Ils disent aussi ce que coûte un agent de code qui tourne avec une clé d'API plutôt qu'avec un abonnement. Une clé d'API, c'est le mot de passe qui permet à une appli d'appeler un modèle et de payer à l'usage.

Isabelle Lafont, développeuse à Paris, a vu ce que coûtent ces renvois quand ils passent au prix de l'API. Elle faisait tourner cinq agents IA personnels sur son propre serveur avec OpenClaw, un logiciel open source pour faire tourner des agents IA. Ces agents accomplissaient en tout 60 tâches automatiques, lancées à heure fixe jour et nuit, comme des résumés chaque matin. Tous utilisaient Claude Sonnet.

Son abonnement Claude couvrait ces agents jusqu'à un vendredi soir de début avril 2026. Ce jour-là, les abonnements d'Anthropic ont cessé de couvrir les logiciels d'agents faits par d'autres, comme OpenClaw. Dès lors, elle a payé chaque appel au prix de l'API.

Pour Owly, l'un de ses agents, chaque message chargeait en moyenne les notes d'Isabelle Lafont, la mémoire de l'agent et ses outils, soit 92 000 tokens de prompt. Au prix de Claude Sonnet 4.6 à l'époque, 3 $ le million de tokens de prompt, cela faisait 0,28 $ par message (92 000 × 3 $ ÷ 1 000 000 = 0,276 $).

Le lundi matin, son tableau de bord affichait 37 € déjà dépensés : « Pas sur deux semaines. Sur deux jours de week-end », écrit-elle.

À ce rythme, ses agents lui auraient coûté environ 555 € par mois (37 ÷ 2 × 30). Elle a alors fait trois changements : elle a activé le cache, confié les tâches courantes à des modèles moins chers et raccourci les résumés que ses agents lui préparaient chaque matin. Ensuite, elle estimait le coût de ses agents à environ 28 $ par mois. Elle donne ce chiffre en dollars et celui du week-end en euros, mais dans les deux cas c'est une petite fraction des 555 € par mois.

Ce que te coûtera un client

Tu sais maintenant ce que coûte un appel. Pour fixer ton prix, il faut passer à ce que coûte un client sur un mois.

Faire tourner un logiciel classique coûte à peine plus cher quand le nombre de clients augmente. Une fonctionnalité IA, elle, ajoute un coût pour chaque client. Ce coût grandit avec l'usage que ce client en fait. Additionnés sur un mois, les appels d'un client donnent ce que ce client te coûte.

Rob Walling investit dans de petits éditeurs de logiciels avec TinySeed, un fonds qui leur est destiné. En août 2026, dans le podcast Startups For the Rest of Us, Rob Walling prévenait qu'un produit construit sur un agent IA peut se vendre bien plus cher qu'un abonnement logiciel sans laisser plus de bénéfice, une fois payé ce que coûtent les modèles.

Pour estimer ce que te coûte un client, prends son mois type. Il te faut trois éléments : ce qu'un appel envoie vraiment (prompt système, outils, conversation en cours), la longueur de la réponse et le nombre d'appels que ce client fait dans le mois. Entre-les dans le compteur. Le coût mensuel qu'il affiche, multiplié par ton nombre de clients, donne ta facture du mois.

Prends un assistant qui répond aux questions de tes clients dans ton appli, en français. Chacun de tes clients lui pose 100 questions par mois, avec un appel par question. Chaque appel envoie un prompt système de 2 000 tokens OpenAI et, en moyenne, 500 tokens de conversation. Chaque appel reçoit une réponse de 300 tokens OpenAI.

Dans le compteur, laisse « Compter en tokens de » sur OpenAI et tape 2 500 dans « Prompt », 300 dans « Réponse » et 100 dans « Appels par mois ». Choisis ensuite « Français ou autre langue européenne » dans « Langue du texte ».

Aux prix du 29 octobre 2026 et sans cache, cet assistant coûte environ 1,40 $ par client et par mois avec Claude Sonnet 5.5, 0,80 $ avec GPT-6.1 Sol et 0,04 $ avec GPT-6 Luna. Chez GPT-6.1 Sol, un appel coûte (2 500 × 2 $ + 300 × 10 $) ÷ 1 000 000 = 0,008 $, soit 0,80 $ pour les 100 appels du mois.

Claude Sonnet 5.5 et GPT-6.1 Sol ont le même prix affiché. L'écart de coût vient seulement de la façon dont Claude découpe le texte. Pour un texte français, Claude compte environ 1,75 tokens pour chaque token OpenAI. Chez Claude, un appel porte donc 2 500 × 1,75 = 4 375 tokens de prompt et 300 × 1,75 = 525 tokens de réponse, soit (4 375 × 2 $ + 525 × 10 $) ÷ 1 000 000 = 0,014 $.

Chez GPT-6 Luna, un appel coûte (2 500 × 0,10 $ + 300 × 0,50 $) ÷ 1 000 000 = 0,0004 $.

Pour vérifier ton prix de vente, refais le calcul pour les clients qui se servent le plus de la fonctionnalité plutôt que pour la moyenne : ton prix doit encore te laisser une marge sur eux, une fois les modèles payés.

Deux questions décident si ce coût pèse sur ta marge. Quelle part de ce que te paie un client part dans les modèles ? Cette part baisse-t-elle quand tes ventes montent ? Deux fondateurs français montrent chacun un cas. Sacha Delcourt dirige une agence qui construit des agents IA pour des entreprises. En février 2026, Sacha Delcourt expliquait que cette agence paie les modèles qu'utilisent ces agents et que le forfait mensuel de ses clients couvre largement ce coût : les modèles n'y prennent qu'une petite part de chaque paiement.

Thibault Besson-Magdelain a cofondé Sorank, un service qui rédige avec des modèles d'IA des articles pour le référencement sur Google. En octobre 2026, Thibault Besson-Magdelain expliquait que si le chiffre d'affaires mensuel de Sorank doublait, ses coûts doubleraient presque aussi. Chez Sorank, chaque article vendu est rédigé par des modèles d'IA : chaque vente ajoute des appels. Avoir plus de clients ne fait donc presque pas baisser le coût de chaque vente : la marge de chaque vente ne grandit pas avec l'entreprise.

Avant de fixer ton prix, pose-toi donc ces deux questions pour ta propre appli. Pour fixer ce prix et trouver tes premiers clients, lis le guide créer un SaaS : il reprend chaque étape, jusqu'au calcul de ta marge.

Comment payer moins

Une fois connu ce que te coûte un client, reste à faire baisser ce coût. La facture peut baisser par plusieurs moyens. Le premier ne change rien à ce que ton appli fait pour ses utilisateurs.

Mets en premier ce qui ne change jamais et laisse le fournisseur le garder en cache

Chez la plupart des fournisseurs, le début d'un prompt peut être gardé un moment après un appel : c'est la mise en cache. Si l'appel suivant commence par le même texte, le fournisseur facture ce début au prix de la colonne « Prompt en cache » du tableau des prix, une fraction du prix normal. Le 29 octobre 2026, cette fraction allait de 2 % du prix normal du prompt chez DeepSeek V4.1 Flash à 25 % chez Grok 4.7.

Elle était de 5 % chez Claude Opus 5.5, Claude Sonnet 5.5, GPT-6.1 Sol et Gemini 4 Argon.

Le cache ne sert que si le nouvel appel commence exactement par le même texte, mot pour mot, depuis le tout premier token. Si un seul mot change au début, une date par exemple, rien de ce qui suit n'est repris du cache. Ce qui ne change jamais doit donc venir en premier : le prompt système, la description des outils, les documents de référence. Le message de l'utilisateur vient en dernier.

Demande à ton agent : « Mets au début du prompt les parties qui ne changent jamais et le message de l'utilisateur à la fin. Active aussi la mise en cache du prompt, avec une clé de cache si le modèle en demande une. » Une clé de cache est une étiquette jointe à chaque appel : elle indique au fournisseur quels appels commencent par le même texte.

Le cache a une condition et un coût. La condition, c'est une longueur minimale : le 29 octobre 2026, le début répété devait faire au moins 512 tokens chez les modèles Claude de la série 5. Il en fallait 1 024 chez les GPT-6 du compteur et 4 096 chez Gemini 4 Argon. En dessous, rien n'était mis en cache.

Le coût se paie quand un début est mis en cache, la première fois qu'il est envoyé : à cette date, cette mise en cache coûtait 1,25 fois le prix normal du prompt chez Claude pour un cache gardé 5 minutes. Anthropic propose aussi un cache gardé une heure, plus cher à remplir. Chez les modèles récents d'OpenAI, la première mise en cache coûtait aussi 1,25 fois le prix normal, pour un cache gardé 30 minutes.

Le cache est rentable dès le deuxième appel, celui qui reprend le même début, à condition qu'il arrive pendant que le cache est gardé. Chez Claude Sonnet 5.5, envoyer deux fois le même début coûte 1,25 + 0,05 = 1,30 fois son prix normal avec le cache, contre 2 fois sans.

Sur un vrai mois d'usage, le cache peut diviser la facture par cinq. Hitesh Jain, cité plus haut pour son mois de Claude Code, a publié l'outil qui lui avait servi pour cette analyse, gratuit et open source. En mai 2026, sibidharan, un utilisateur de Hacker News, l'a fait tourner sur un mois de son propre usage de Claude Code sur un serveur, soit 933 sessions de travail.

sibidharan paie des abonnements, mais l'outil calcule ce que l'API aurait facturé, au prix affiché de Claude Opus 4.7 à cette date. Ce mois aurait coûté 22 720 $ avec le cache et 113 418 $ sans (113 418 ÷ 22 720 = 5,0).

En avril 2026, le nouveau tokenizer de Claude a fait monter le nombre de tokens. Les factures, elles, ont moins monté. Le cache explique en partie pourquoi. En juin 2026, OpenRouter, un service qui transmet les demandes à de nombreux modèles, a comparé les mêmes prompts avant et après ce changement. Le nouveau tokenizer ajoutait 32 à 45 % de tokens, mais les coûts réels ne montaient que de 12 à 27 % sur les prompts de plus de 2 000 tokens.

Selon OpenRouter, deux choses ont freiné la hausse. Sur les longs prompts, la plupart des tokens en plus tombaient dans la partie reprise du cache, facturée à une fraction du prix normal. La longueur des réponses a aussi changé avec le nouveau modèle. Cette mesure compare Claude à son ancien tokenizer, pas à OpenAI.

Un mauvais réglage du cache peut faire perdre l'économie qu'il apporte. Ploy est une entreprise dont l'agent construit des sites web. En juillet 2026, Ploy a comparé deux modèles d'avant ceux du compteur : GPT-5.6 (OpenAI) et Claude Opus 4.8 (Anthropic). Pour le même travail, GPT-5.6 semblait d'abord « environ 50 % plus cher ». Ploy a ensuite découvert la raison : ses conversations commençaient toutes par le même texte de 29 000 tokens, mais GPT-5.6 ne le reprenait jamais du cache.

GPT-5.6 ne mettait en cache que les prompts marqués pour la mise en cache, avec une clé de cache dans chaque appel. Une fois les clés en place, la comparaison s'est inversée : 2,22 $ par site terminé avec GPT-5.6, contre 3,06 $ avec Claude Opus 4.8. Pour ton modèle, demande à ton agent : « Faut-il une clé de cache dans nos appels ? »

La durée du cache compte aussi. Claude Code, l'agent de code d'Anthropic, choisit combien de temps il demande au fournisseur de garder le cache. Sean Swanson, qui développe des logiciels, a analysé 119 866 appels faits par Claude Code. Cette analyse montre qu'en mars 2026, Claude Code demandait de garder le cache cinq minutes, contre une heure auparavant. Quand le cache expire entre deux appels, l'appel suivant paie de nouveau le prix de la mise en cache.

Sean Swanson a calculé qu'au prix de l'API, ce changement augmentait de 17,1 % sa facture sur Claude Sonnet 4.6. Demande à ton agent : « Combien de temps le cache de notre modèle est-il gardé ? Nos appels reviennent-ils assez souvent pour en profiter ? »

Prends le modèle le moins cher qui fait bien le travail

Chaque fournisseur vend des modèles de plusieurs tailles : les grands sont plus capables et plus chers, les petits plus rapides et moins chers. Le 29 octobre 2026, les moins chers par token du tableau étaient GPT-6 Luna et Claude Haiku 5.5, à 0,10 $ le million de tokens de prompt. Les plus chers étaient GPT-6 Astra et Claude Fable 5.1, à 10 $.

Trier des messages, extraire des informations d'un e-mail ou écrire une réponse d'une ligne demande rarement le modèle le plus puissant. Avant de changer de modèle, demande à ton agent : « Essaie le modèle moins cher sur vingt vraies demandes et montre-moi ses réponses à côté de celles du modèle actuel. »

L'écart de prix entre modèles peut être énorme. En septembre 2026, k9294, un utilisateur de Hacker News, a publié les tokens d'une tâche de code de 447 étapes : environ 37,7 millions de tokens, dont 36,6 millions lus dans le cache.

Le message de k9294 ne dit pas quel modèle a fait la tâche. Il prend les nombres de tokens de la tâche et calcule ce qu'ils coûteraient aux prix de GPT-6 Astra, puis à ceux de DeepSeek V4.1 Flash.

Recalculé pour cette page aux prix du tableau, cela donne 55,06 $ chez GPT-6 Astra et 0,725 $ chez DeepSeek V4.1 Flash, soit environ 76 fois moins. Les deux modèles ne comptent pas les tokens de la même façon : garder les mêmes nombres pour les deux demande une vérification. Sur du code, le tokenizer de DeepSeek compte à peu près comme celui d'OpenAI, avec 1,02 token pour chaque token OpenAI : la comparaison tient donc. Le message de k9294 ne dit pas si le modèle le moins cher aurait aussi bien fait le travail.

Isabelle Lafont, citée plus haut pour ses agents, n'a gardé Claude Sonnet que pour écrire en français, car « le ton et la nuance en français restent la chasse gardée d'Anthropic ». Elle a confié tout le reste à des modèles moins chers.

Juge une économie au coût de la tâche terminée

Payer moins de tokens par appel ne veut pas dire payer moins pour le travail fini. En septembre 2026, Quesma, une entreprise qui teste et compare les outils IA, a mesuré RTK. RTK est un outil qui raccourcit ce qu'un agent de code relit après chaque commande, par exemple le résultat d'un test. Sur les tâches de Quesma, RTK annonçait 349 millions de tokens économisés. Pourtant, le coût par tâche a augmenté de 17 %, parce que l'agent a eu besoin de 18 % d'étapes en plus pour finir les mêmes tâches.

Nicolas Martignole est un développeur français qui a mesuré l'usage de Claude Code dans son entreprise, Back Market, la marketplace d'appareils reconditionnés. Nicolas Martignole défend la même idée dans une conférence de juillet 2026 intitulée « Le vrai coût de l'IA : pourquoi le prix au token est faux ». Nicolas Martignole y explique que le prix au token n'est qu'un chiffre sur une page web. Le coût réel dépend de l'agent, du contexte que cet agent envoie et de ses erreurs.

Le compteur donne le coût des appels que tu décris. Pour savoir combien d'appels une tâche demande vraiment, reprises après une erreur comprises, demande à ton agent : « Lance cette tâche trois fois et dis-moi combien d'appels au modèle chacune a faits et combien de tokens elles ont consommés. »

Mets des plafonds de dépense et vérifie ce que tu tapes dans les pages de facturation

Une erreur de réglage peut coûter cher en quelques jours. ppcvote, qui développe sans associé depuis Taïwan, fait tourner son entreprise avec des agents IA sur l'offre gratuite de Gemini, qui permet d'utiliser certains modèles sans payer, dans certaines limites. En mars 2026, ppcvote a raconté sur Hacker News avoir pourtant reçu une facture de 127 $ en sept jours.

En mars 2026, l'offre gratuite ne valait que pour une clé d'API créée dans Google AI Studio, le site de Google pour essayer Gemini. La clé de ppcvote avait été créée dans un projet Google Cloud, l'espace où Google gère la facturation. La facturation y était activée. Chaque appel était donc facturé. Rien ne limitait non plus les tokens de réflexion du modèle, facturés au prix des réponses. La leçon de ppcvote : créer ses clés depuis Google AI Studio.

En octobre 2026, un avocat du Costa Rica a voulu ajouter 5,04 $ de crédit prépayé dans la console d'Anthropic, le site où l'on paie l'API. La somme a été tapée « 5,04 », avec une virgule, comme on écrit les décimales en espagnol et en français. La carte a été débitée de 504 $ au lieu de 5,04 $. L'avocat l'a signalé sur Hacker News, où un salarié d'Anthropic a confirmé le bug.

Un plafond de dépense aurait arrêté la facture de ppcvote avant les 127 $. Demande à ton agent : « Quel plafond de dépense le compte de chacun de nos fournisseurs propose-t-il ? Comment le régler ? » Et dans les pages de facturation, tape les montants avec un point plutôt qu'une virgule, pour éviter l'erreur de l'avocat du Costa Rica.

Comment le compteur estime chaque fournisseur

Pourquoi certains chiffres du compteur sont-ils comptés et d'autres estimés ? Le compteur tourne dans ton navigateur, pour que ton texte reste sur ton appareil. Il ne peut donc pas l'envoyer aux services de comptage des fournisseurs : il compte lui-même. Pour compter exactement comme un fournisseur, il lui faut le tokenizer de ce fournisseur, c'est-à-dire sa liste de morceaux et sa façon de découper. Il ne peut s'en servir que si le fournisseur le publie.

OpenAI, DeepSeek et Mistral AI publient les leurs : le compteur en fait tourner quatre. Le premier est o200k, qu'OpenAI publie pour ses modèles depuis GPT-4o. Le deuxième est celui de DeepSeek, commun à ses modèles V4 Pro et V4.1 Flash. Les deux derniers sont ceux de Mistral Large 4 et de Mistral Small 4.

Pour garder la page légère, les tokenizers de DeepSeek et de Mistral ne se téléchargent qu'une fois que le tableau « Ce que ça coûte sur chaque modèle » apparaît à l'écran : leurs lignes peuvent attendre une seconde avant de s'afficher.

Anthropic, Google et xAI, l'entreprise qui fait Grok, ne publient aucun tokenizer pour les modèles du compteur. Pour Claude et Gemini, le compteur part donc du nombre de tokens d'OpenAI et le multiplie par le multiplicateur de ce fournisseur pour ce type de texte. Pour Grok, il reprend tel quel le décompte d'OpenAI. Ces chiffres sont des estimations, que le compteur marque du signe ≈. Les parties qui suivent disent, fournisseur par fournisseur, d'où vient chaque chiffre.

OpenAI

Les modèles d'OpenAI du compteur sont des modèles GPT-6. OpenAI n'a pas dit si GPT-6 utilise aussi o200k. tiktoken, le logiciel qu'OpenAI publie pour que les développeurs comptent les tokens sur leur propre ordinateur, n'indique aucun tokenizer pour GPT-6.

Sur GitHub, le site où les développeurs partagent leur code et signalent des problèmes, une personne a demandé à OpenAI d'ajouter GPT-6 à tiktoken. Cette personne a refermé sa demande le 17 octobre 2026, sans réponse d'OpenAI. Rien d'officiel ne dit donc qu'o200k est le bon tokenizer pour GPT-6 : ce sont les mesures qui le montrent.

OpenAI propose aussi aux développeurs un service de comptage, qui donne le nombre de tokens qu'un modèle facturera. Pour vérifier o200k, on compare son décompte à celui de ce service sur les mêmes textes.

Une comparaison indépendante a fait ce travail pour GPT-6 : token-count-compare, une comparaison publiée sur GitHub que chacun peut refaire, a essayé 31 textes le 12 octobre 2026. Elle a trouvé que GPT-6 Astra, GPT-6 Sol et GPT-6 Luna comptaient comme o200k.

Le service d'OpenAI compte, en plus du texte, 6 tokens qui encadrent chaque message et indiquent au modèle qui parle. Pour cette page, le 2 novembre 2026, les décomptes que token-count-compare a obtenus du service d'OpenAI ont été comparés à ceux du compteur. Une fois ces 6 tokens retirés, ils étaient identiques sur chacun des 31 textes.

Le modèle testé, GPT-6 Sol, n'est pas dans le compteur. Le compteur contient sa version suivante, GPT-6.1 Sol. Aucun test publié ne couvre encore cette version. Le compteur suppose qu'elle compte comme GPT-6 Sol.

Claude

Anthropic ne publie pas son tokenizer : le compteur estime donc Claude avec des multiplicateurs mesurés pour cette page. Anthropic propose un service de comptage, gratuit le 29 octobre 2026 mais accessible seulement avec un compte et une clé d'API.

Le 2 novembre 2026, 114 textes ont été comptés à la fois avec o200k et avec ce service. Il y avait de la prose en anglais, en français, en allemand, en espagnol et en italien, des prompts, des e-mails, des conversations et du code dans une quinzaine de langages de programmation. Il y avait aussi des tableaux de chiffres et des données : des fichiers JSON et des journaux d'événements d'applis.

Le service d'Anthropic ajoute 7 tokens à chaque demande pour l'encadrer : ils ont été retirés avant de comparer. Anthropic présente son résultat comme « une estimation » qui « peut différer légèrement ». Pour les quatre modèles Claude du compteur, le service d'Anthropic a donné exactement le même nombre de tokens sur chacun des 114 textes : les mêmes multiplicateurs valent donc pour les quatre.

Le multiplicateur de Claude dépend surtout du type de texte : parmi les langues, il est le plus bas en anglais et le plus haut en allemand. Voici, pour chaque type, sa médiane, c'est-à-dire la valeur du milieu : la moitié des textes est au-dessus, l'autre moitié en dessous. Sur 30 textes anglais, Claude comptait 1,49 fois plus de tokens qu'OpenAI. Sur 16 textes français, il en comptait 1,70 fois plus. L'espagnol arrivait à 1,80, l'italien à 1,64 et l'allemand à 2,19.

Hors de la prose, Claude compte moins sur les tableaux que sur le code. Sur 27 extraits de code, il comptait 1,57 fois plus de tokens qu'OpenAI. Sur 16 fichiers de données, 1,45 fois plus. Sur 8 tableaux de chiffres, seulement 1,15 fois plus. Les multiplicateurs du compteur, calculés sur une partie de ces textes, en sont proches.

L'allemand est l'exception parmi les langues européennes : Claude y compte bien plus que dans les autres. Le bouton « Allemand » de « Langue du texte » applique donc son propre multiplicateur. TextKit trouvait lui aussi un chiffre élevé en allemand sur son passage traduit : 2,04.

Le français, l'espagnol et l'italien, eux, partagent un même multiplicateur : celui du bouton « Français ou autre langue européenne ». Les données et les tableaux ont aussi leur bouton, parce que Claude les découpe en moins de morceaux que le code.

Les multiplicateurs du compteur ont été calculés sur 59 des 114 textes, puis vérifiés sur les 55 autres, qui n'avaient pas servi au calcul. C'est la seule façon de savoir comment le compteur se comporte sur un texte qu'il n'a jamais vu. Sur ces 55 textes, l'estimation du compteur s'écartait du décompte d'Anthropic de moins de 3,5 % pour la moitié d'entre eux. Pour neuf textes sur dix, l'écart restait sous 8,8 %. Le plus grand écart, sur un tableau de chiffres, atteignait 18,7 %.

Les boutons « Allemand », « Données » et « Tableau » ont été ajoutés après cette mesure. Avant eux, l'allemand prenait le multiplicateur des autres langues européennes. Les données et les tableaux prenaient celui du code. Avec ces multiplicateurs, l'écart restait sous 24,4 % pour neuf textes sur dix. Le plus grand écart, sur un tableau de chiffres, atteignait 59,5 %. Avec les nouveaux boutons, ces chiffres sont descendus à 8,8 % et 18,7 %.

Comme ils viennent de 59 textes, les multiplicateurs sont proches des médianes des 114 textes sans leur être égaux. Sur les tableaux, mesurés sur peu de textes, la médiane est de 1,15 et le multiplicateur de 1,19. Ces mesures seront refaites. Une nouvelle mesure ne changera un multiplicateur que si elle s'en éloigne assez pour ne pas être due au hasard. Il faut pour cela deux conditions : qu'elle s'en éloigne de plus de 3 % et de plus de deux fois sa propre marge d'erreur. En dessous, l'écart tient au hasard de la mesure.

D'autres ont publié leurs propres mesures, faites elles aussi avec le service de comptage d'Anthropic sur des textes comptés chez Claude et chez OpenAI. Le tableau ci-dessous met ces quatre mesures à côté du test de cette page. Toutes trouvent que Claude compte plus qu'OpenAI, dans des proportions proches : environ 1,5 fois plus en anglais et 1,7 à 1,8 fois plus en français.

Dans le tableau, chaque chiffre est le nombre de tokens de Claude divisé par celui d'OpenAI pour le même texte. Quand une mesure donne plusieurs chiffres, par exemple sur plusieurs textes, le tableau donne la fourchette :

Pourquoi Claude compte-t-il autant de tokens en plus ? Anthropic a changé de tokenizer avec Claude Opus 4.7, le 16 avril 2026. Sa documentation indique que le nouveau « produit environ 30 % de tokens en plus pour le même texte » que le précédent. Son guide de migration vers Claude Opus 5.5 précise que l'écart peut monter jusqu'à environ 35 % selon le contenu.

Anthropic ne dit pas pourquoi le nouveau tokenizer découpe le même texte en plus de morceaux, alors que les modèles récents ont en général des listes plus grandes. Tous les modèles Claude sortis depuis Claude Opus 4.7 l'utilisent, dont les quatre du compteur.

La même documentation compte désormais un million de tokens Claude pour « environ 555 000 mots », contre 750 000 mots avant. Cela fait environ 1,8 token par mot (1 000 000 ÷ 555 000 = 1,8).

Deux autres mesures comparent le nouveau tokenizer de Claude à l'ancien plutôt qu'à OpenAI. Le jour de la sortie de Claude Opus 4.7, Abhishek Ray, qui écrit une newsletter sur Claude Code, a mesuré 1,325 fois plus de tokens qu'avec le modèle précédent, Claude Opus 4.6, sur sept fichiers réels. Quatre jours plus tard, Simon Willison en trouvait 1,46 fois plus sur un prompt système. Ces deux chiffres sont du même ordre que les 30 à 35 % qu'annonce Anthropic.

L'ancien tokenizer de Claude comptait déjà plus qu'OpenAI. TextKit et Simon Willison ont aussi mesuré des modèles Claude plus anciens : l'ancien tokenizer y donnait 5 à 7 % de tokens de plus qu'OpenAI sur du texte anglais courant et 20 % de plus sur l'ensemble des textes de token-count-compare, code compris.

Sur du texte anglais, on peut combiner les deux écarts. L'ancien tokenizer comptait 5 à 7 % de plus qu'OpenAI. Le nouveau compte 30 à 35 % de plus que l'ancien. Ensemble, cela fait environ 1,37 à 1,44 fois le nombre de tokens d'OpenAI (1,05 × 1,30 = 1,37 et 1,07 × 1,35 = 1,44). La plupart des mesures directes du tableau trouvent un peu plus, environ 1,5 : le compteur suit ces mesures.

Beaucoup de compteurs de tokens affichent encore pour Claude 10 à 20 % de plus qu'OpenAI, au lieu d'environ 50 % en anglais. Ces 10 à 20 % correspondent à l'ancien tokenizer, utilisé jusqu'à Claude Opus 4.6 : ces compteurs sous-estiment donc Claude. Claude Haiku 4.5, un modèle plus ancien absent du compteur, l'utilise toujours. Claude Haiku 5.5, qui est dans le compteur, utilise le nouveau.

Gemini

Google ne publie pas le tokenizer des trois modèles Gemini du compteur : Gemini 4 Argon, Gemini 3.8 Flash et Gemini 3.5 Flash-Lite. Son kit de développement, le logiciel qu'il fournit aux développeurs, indique un tokenizer pour les modèles Gemini plus anciens, jusqu'à Gemini 3.5 Flash : celui de Gemma. Gemini 3.5 Flash est un autre modèle que Gemini 3.5 Flash-Lite. Pour les trois modèles du compteur, le kit n'indique aucun tokenizer.

Gemma est un modèle que Google publie avec son tokenizer. Les premiers multiplicateurs de Gemini, calculés le 29 octobre 2026, venaient du tokenizer de Gemma.

Google propose en revanche un service de comptage dans son API Gemini, qui donne le nombre de tokens qu'un modèle Gemini compte pour un texte. Le 2 novembre 2026, les 114 textes déjà comptés pour Claude l'ont été avec ce service, sur les trois modèles. La méthode était la même que pour Claude. Les multiplicateurs ont été calculés sur une partie des textes, puis vérifiés sur les autres textes. Ces textes sont dits « mis de côté », parce qu'ils n'ont pas servi au calcul.

Gemini 3.8 Flash et Gemini 3.5 Flash-Lite ont donné exactement les mêmes décomptes. Gemini 4 Argon comptait presque pareil : environ 0,5 % de moins en médiane. Son plus grand écart était de 6 % de moins, sur un long texte chinois. Les mêmes multiplicateurs valent donc pour les trois. Le service de Google ajoute ses propres tokens à chaque appel, 31 chez Gemini 4 Argon et 1 chez les modèles Flash : ils ont été retirés avant de comparer.

Gemini compte à peu près comme OpenAI sur de la prose. Il compte davantage sur le code, les données et surtout les tableaux. Voici ses médianes par rapport au décompte d'OpenAI : 1,04 en anglais, 1,07 en français et dans les autres langues européennes, 1,04 en allemand. Sur du code, c'est 1,15, sur des données 1,17 et sur des tableaux de chiffres 1,42.

Un seul multiplicateur a bougé : celui du code, passé de 1,2 à 1,15. Pour les autres, l'écart entre la mesure et l'ancien chiffre était trop petit pour ne pas être dû au hasard. Les chiffres tirés de Gemma ont donc été gardés : 1,05 en anglais, 1,06 en français, dans les autres langues européennes et en allemand, 1,2 sur des données. Le décompte de Google les a confirmés.

Les tableaux font exception. Mesurés, ils arrivent à 1,42, bien au-dessus du 1,2 qu'utilise le compteur. Utiliser 1,42 a donc été testé sur les tableaux mis de côté : ça ne faisait pas mieux. Avec 1,42, la moitié de ces tableaux s'écartaient de plus de 17,6 %, contre 12,9 % avec 1,2. Seul le pire tableau s'améliorait, de 34,6 % d'écart à 22,6 %. Les décomptes de Gemini varient beaucoup d'un tableau à l'autre : le compteur garde donc 1,2. Pour Gemini, ses chiffres sur les tableaux sont les moins sûrs.

Avec les multiplicateurs qu'utilise le compteur, l'estimation de Gemini s'écartait du décompte de Google de moins de 3,7 % pour la moitié des textes mis de côté. Pour neuf sur dix, l'écart restait sous 12,8 %. Le plus grand écart, 34,6 %, était celui du même tableau, avec le multiplicateur que garde le compteur.

DeepSeek et Mistral

Pour DeepSeek V4 Pro, DeepSeek V4.1 Flash, Mistral Large 4 et Mistral Small 4, le compteur passe ton texte dans le tokenizer que publie le fournisseur. Pour ces modèles, le nombre de tokens de ton texte est donc compté, pas estimé.

Ces trois tokenizers comptent presque comme celui d'OpenAI. Voici leur médiane, la valeur du milieu, sur les 114 textes comptés le 2 novembre 2026. Celui de DeepSeek comptait à peu près comme OpenAI en anglais et environ 12 % de plus en français. Celui de Mistral Large 4 comptait environ 2 % de plus en anglais et 1 % de moins en français. Celui de Mistral Small 4 comptait environ 4 % de plus qu'OpenAI en anglais comme en français.

Sur les tableaux de chiffres, le tokenizer de Mistral Small 4 comptait 40 % de plus qu'OpenAI, parce qu'il coupe chaque nombre chiffre par chiffre, alors que le tokenizer d'OpenAI garde jusqu'à trois chiffres dans un même morceau.

Le compteur a quand même besoin d'un multiplicateur pour ces modèles dans deux cas : la réponse, que le modèle n'a pas encore écrite, ainsi qu'un nombre que tu tapes dans « Prompt » au lieu de coller un texte. Ces multiplicateurs sont ceux du tableau ci-dessous. Ils ont été calculés sur 59 des textes plutôt que sur les 114 : ils peuvent donc différer un peu des médianes données plus haut.

Grok

xAI, l'entreprise qui fait Grok, ne publie pas le tokenizer de Grok. Les conditions de son API rangent les informations sur les performances de ses services parmi ses informations confidentielles : Grok n'a donc pas été mesuré pour cette page. Aucune autre mesure des décomptes de Grok n'a été jugée assez fiable pour servir.

Le compteur compte donc Grok 4.7 et Grok 4.3 exactement comme OpenAI : leur multiplicateur vaut 1 pour tous les types de texte. Les chiffres de Grok gardent le signe ≈, car ce sont des estimations : on ne sait pas de combien ils s'écartent du vrai décompte de Grok.

Les multiplicateurs du compteur

Voici, pour chaque modèle et chaque type de texte, le nombre de tokens que le compteur compte pour 1 token OpenAI. Pour DeepSeek et Mistral, ces multiplicateurs ne servent qu'à la réponse et aux nombres tapés. Pour Grok, rien n'est mesuré : chaque colonne vaut 1, le décompte d'OpenAI tel quel.

Ce que le compteur ne compte pas

• Les quelques tokens que le fournisseur ajoute pour encadrer chaque message ou chaque appel. Ils indiquent au modèle qui parle : 6 par message chez OpenAI et 7 par appel chez Claude dans les tests plus haut. Le compteur compte ton texte seul.
• L'instruction que certains fournisseurs ajoutent quand ton appli utilise des outils. Anthropic, par exemple, ajoute 286 tokens chez Claude Opus 5.5. Ajoute-les toi-même dans « Prompt », en choisissant Claude dans « Compter en tokens de ».
• Les images et les fichiers. Le fournisseur les compte en plus du texte. Le compteur ne compte que le texte.
• Le nombre exact de tokens de Claude, Gemini et Grok. Pour ces modèles, le compteur donne une estimation. Le chiffre exact ne vient que du fournisseur lui-même : son service de comptage quand il en a un, ou sa facture.