Tarifs de l'API Anthropic en 2026 : tous les tarifs et les vrais leviers de coût

La grille tarifaire complète de l'API Anthropic

Tout ce qui suit provient de la documentation tarifaire détaillée d'Anthropic elle-même, vérifiée le 13 août 2026. Les prix sont en USD par million de tokens, que la documentation abrège en MTok. À savoir avant de copier une URL : platform.claude.com/docs/en/pricing est un stub de redirection qui ne renvoie rien, et la vraie page se trouve sous /about-claude/pricing.

Trois choses dans ce tableau méritent qu'on s'y attarde.

Cinq générations d'Opus ont un prix identique. Opus 5, 4.8, 4.7, 4.6 et 4.5 sont tous facturés à 5 $ en entrée et 25 $ en sortie. Si vous êtes encore accroché à un ancien Opus pour des raisons de reproductibilité, vous n'économisez pas d'argent en faisant cela, et l'Opus 4.1 retiré est le seul encore sur l'ancienne grille à 15 $ et 75 $.

Sonnet est devenu moins cher, ce qui n'arrive généralement pas. Sonnet 5 se situe à 2 $ et 10 $ contre 3 $ et 15 $ pour Sonnet 4.6, une baisse de 33 % sur les deux compteurs en une génération. Pour la plupart des trafics de production, cela fait de Sonnet 5 le choix par défaut évident plutôt qu'un compromis.

Fable 5, à 10 $ et 50 $, coûte exactement 2 fois Opus 5. Retenez ce chiffre, il revient quand on aborde le mode rapide.

Si vous voulez le contexte de capacités des modèles Claude en plus des prix, voici les spécifications :

La recommandation d'Anthropic elle-même est de commencer avec Claude Opus 5 pour les tâches agentiques complexes et d'entreprise, et de traiter Fable 5 comme le modèle de dernier recours plutôt que le défaut.

Calculez votre propre chiffre

La grille tarifaire ne devient un budget que lorsque vous y passez votre propre trafic. Réglez les quatre valeurs ci-dessous, elle calculera le mois, puis vous montrera ce que la même charge de travail aurait coûté sans mise en cache ni réduction batch.

Déplacez le curseur de cache et observez le total, car ce seul réglage fait bouger le chiffre plus que ne le ferait un changement de niveau de modèle sur une charge de travail à forte composante d'entrée. C'est tout l'argument de la section suivante.

Quatre multiplicateurs décident de la facture, pas la grille tarifaire

Anthropic publie le prix par token bien en évidence et les multiplicateurs discrètement. C'est dans les multiplicateurs qu'est l'argent.

Le prompt caching est le levier le plus important, et le cache court est le moins cher

La mise en cache a trois prix, tous exprimés par rapport au tarif d'entrée de base du modèle : une écriture de cache de 5 minutes coûte 1,25x, une écriture d'1 heure coûte 2x, et un hit de cache coûte 0,1x. Définir les breakpoints eux-mêmes est gratuit. Le plafond en régime permanent est une réduction de 90 % sur tout préfixe que vous réutilisez.

L'arithmétique du seuil de rentabilité est là où les gens se trompent. Chaque hit économise 0,9x de la base, donc le cache de 5 minutes se rentabilise après un hit, et le cache d'1 heure en a besoin de deux. Écriture plus un hit sur le TTL d'1 heure revient à 2,1x contre 2,0x sans aucune mise en cache, donc un prompt à réutilisation unique sur le cache long est réellement pire que de laisser le cache désactivé.

La recommandation d'Anthropic elle-même est de rester sur le cache de 5 minutes pour tout ce qui est sollicité plus souvent que toutes les cinq minutes, car il se rafraîchit sans coût supplémentaire à chaque utilisation. Le TTL d'1 heure est fait pour les intervalles : une longue exécution d'un agent secondaire, ou un utilisateur qui ne répondra peut-être pas pendant dix minutes.

Il y a ensuite la partie que presque personne ne budgétise. Les lectures de cache ne sont pas déduites de votre limite de débit de tokens d'entrée. L'exemple chiffré d'Anthropic est une limite de 2 000 000 ITPM associée à un taux de hit de cache de 80 %, ce qui permet de faire passer 10 000 000 de tokens d'entrée par minute sur le même compte. La mise en cache n'est pas seulement une réduction, c'est un multiplicateur de débit de 5x, et c'est le moyen le moins cher de relever un plafond que vous devriez sinon demander à Anthropic de relever pour vous.

Haiku 3.5 est l'exception documentée où les lectures de cache comptent bien dans la limite, et il est de toute façon retiré sur l'API de premier niveau.

C'est aussi pourquoi les chiffres de tokens qui font la une trompent autant. Un praticien qui corrigeait l'estimation de coût de quelqu'un d'autre sur Hacker News l'a formulé aussi clairement que possible :

"i run a bunch of claude agents for automation and like 85% of input tokens end up being cached reads -which cost 1/10th of the sticker price. so your $200k number is probably closer to $25-30k in real cost"

tcbrah, Hacker News

Plusieurs personnes exploitant de l'automatisation en production rapportent indépendamment que 85 % à 92 % des tokens d'entrée finissent en lectures de cache. Si vous valorisez un nombre de tokens au tarif affiché, vous surestimez une facture réelle d'environ 10x.

Le préfixe minimum cachable est le piège caché derrière tout cela, car il n'évolue pas de manière linéaire d'une génération à l'autre :

Opus 5 met en cache dès 512 tokens. Haiku 4.5 en a besoin de huit fois plus. Si vous restez en dessous du seuil, la mise en cache ne fait tout simplement rien et ne renvoie aucune erreur, c'est pourquoi une facture qui refuse de baisser après avoir « activé la mise en cache » vient généralement d'un prompt qui n'a jamais rempli la condition. Voir cache_creation_input_tokens et cache_read_input_tokens à zéro dans la réponse est le signe qui ne trompe pas.

Quelques autres mécaniques qui coûtent discrètement de l'argent. La fenêtre de lookback en lecture est de 20 blocs, donc un tour qui en ajoute plus de 20 dépasse votre dernière écriture et rate le hit. Modifier les définitions d'outils invalide tout le cache, puisque la hiérarchie parcourt les outils, puis le système, puis les messages. Et l'erreur courante documentée est de placer le breakpoint sur un bloc contenant un horodatage ou le message entrant de l'utilisateur, ce qui achète une écriture neuve à chaque requête et jamais une lecture.

Le batch retire 50 % à plat, avec deux exclusions

La Batch API retire 50 % à la fois sur l'entrée et la sortie pour chaque modèle actif, et elle se cumule avec la mise en cache. Les limites sont de 100 000 requêtes ou 256 Mo par batch, la plupart se terminent en moins d'une heure, et le plafond absolu est de 24 heures.

Le détail de facturation que j'apprécie : les requêtes errored, canceled et expired ne sont pas facturées du tout. Seuls les succès coûtent de l'argent, ce qui fait du batch un endroit à faible risque pour exécuter un gros travail de classification. Le contrepoids est qu'un batch peut légèrement dépasser votre limite de dépense configurée à cause du traitement concurrent, ce n'est donc pas une barrière budgétaire absolue.

Deux exclusions à prévoir : le batch ne se combine pas avec le mode rapide, et la réduction ne s'applique pas aux sessions Managed Agents.

Effort est le réglage par défaut que personne ne configure

output_config.effort contrôle combien de tokens Claude dépense, et cela couvre le texte, les appels d'outils et la réflexion de la même manière, donc cela s'applique même avec la réflexion désactivée. Les niveaux sont low, medium, high, xhigh, max.

Le défaut est high sur tous les modèles documentés par Anthropic, le deuxième réglage le plus cher de l'échelle. La propre liste de bonnes pratiques d'Anthropic commence par « définir effort explicitement », ce qui est une façon polie de dire que le comportement par défaut n'est pas celui que vous voulez pour du travail en volume.

Aucun multiplicateur de tokens n'est publié pour un niveau quelconque, traitez-le donc comme un cadran à mesurer plutôt qu'une réduction à réclamer. Le seul repère comparable donné par Anthropic est que Sonnet 5 en medium équivaut à peu près à Sonnet 4.6 en high. Deux pièges à connaître avant de commencer à régler : changer l'effort entre les requêtes invalide vos préfixes en cache, donc les deux leviers se battent entre eux, et sur Opus 5 un effort plus faible raccourcit la réflexion plutôt que la réponse visible, donc demandez explicitement de la longueur si c'est la brièveté que vous visiez.

Les deux majorations cachées dans la documentation

Le mode rapide donne à Opus 5 et Opus 4.8 une sortie jusqu'à 2,5 fois plus rapide à 10 $ en entrée et 50 $ en sortie, exactement 2x le standard. Ce qui produit la décision d'achat que je trouve la plus intéressante de toute la grille : Opus 5 en mode rapide coûte exactement ce que coûte Fable 5 standard. Si vous envisagez le mode rapide pour un problème difficile, chiffrez d'abord le modèle plus capable au même tarif avant de vous engager. Le mode rapide est réservé à l'API de premier niveau, et ne se combine pas avec le batch.

Le plus discret est la résidence des données. Fixer l'inférence aux États-Unis avec inference_geo: "us" sur Claude 4.6 et versions suivantes applique un multiplicateur de 1,1x à chaque catégorie de tokens, y compris les écritures et lectures de cache, pas seulement l'entrée et la sortie. C'est une majoration de 10 % sur toute la facture, facile à régler une fois et à oublier, et le routage global est le réglage par défaut au tarif standard.

Empilez les quatre leviers et l'écart sur un seul modèle devient plus grand que l'écart entre les niveaux de modèles :

Les coûts d'outils et d'agents qui s'ajoutent aux tokens

Les outils côté serveur sont facturés séparément, et ce sont les lignes qui surprennent les gens qui lisent une facture mensuelle pour la première fois.

Cette dernière ligne mérite une remarque, car elle évolue dans le bon sens. Opus 4.7 portait le pire overhead fixe d'outils de la grille à 675 tokens en auto, et Opus 5 l'a réduit à 286. Si vous exploitez une installation lourde d'outils MCP avec des milliers de petites requêtes, c'est une réduction réelle de 58 % sur une ligne de coût que vous n'avez jamais choisie.

Anthropic publie son propre exemple chiffré pour une session de codage d'une heure avec Managed Agents sur Opus 5, et c'est le chiffre de ROI de mise en cache le plus clair disponible dans toute la documentation :

C'est une baisse de 25,5 % sur toute la session grâce à la seule mise en cache, sur une charge de travail où la sortie domine et où la mise en cache ne peut toucher qu'une partie de la facture.

Il n'y a plus de surprime de contexte long

C'est le changement que la plupart des articles tarifaires tiers continuent de mal représenter. Claude 4.6 et versions suivantes incluent la fenêtre complète de 1M de tokens aux tarifs standard, et la documentation tarifaire le dit clairement : une requête de 900k tokens est facturée au même tarif par token qu'une requête de 9k. Les réductions de mise en cache et de batch s'appliquent aussi sur toute la fenêtre.

Deux réserves empêchent que ce soit un vrai repas gratuit. Anthropic elle-même prévient que la précision et le rappel se dégradent à mesure que le nombre de tokens augmente, donc payer pour une fenêtre plus complète peut acheter de moins bonnes réponses. Et le comportement de débordement a changé sur Claude 4.5 et versions suivantes : si l'entrée plus max_tokens dépasse la fenêtre, la requête est acceptée et s'arrête avec stop_reason: "model_context_window_exceeded" en cours de route, et vous payez pour tout ce qui a été généré avant l'arrêt.

Comment se compare la tarification de l'API Anthropic

Voici la comparaison honnête face aux autres API de pointe, tirée de la page de chaque fournisseur le même jour. Si vous voulez la version plus approfondie, nous avons une décomposition complète des trois fournisseurs d'API et une comparaison directe avec l'API Anthropic.

En lisant ce tableau honnêtement, Claude n'est le moins cher nulle part. Les tarifs de Gemini sous-cotent Sonnet 5 en entrée au niveau intermédiaire, grok-4.6 est nettement moins cher en sortie au niveau de pointe, et deepseek-v4-flash est dans un univers totalement différent à $0.14 et $0.28, avec un tarif de lecture de cache environ 50 fois inférieur au tarif sans hit.

Là où Anthropic gagne, c'est la prévisibilité, et à grande échelle, cela vaut de l'argent réel.

Commençons par le contexte long, puisqu'aucun modèle Claude actuel n'y applique de surprime, alors que Gemini 3 publie un tarif doublé au-delà de 200K. La version de xAI est plus dure : son tarif de contexte long s'applique à tous les tokens de la requête dès que le prompt dépasse 200K, donc un token de trop retarife tout l'appel. Comparez ensuite la forme de la facture. Anthropic mesure quatre choses : entrée, sortie, écritures de cache et lectures de cache, plus un petit ensemble d'outils nommés. La page de xAI liste cinq types de tokens facturés séparément, six invocations d'outils tarifées, le stockage de fichiers et de collections, l'egress, et des frais de 0,05 $ sur toute requête enfreignant ses directives d'usage. La parité batch est aussi un mythe : OpenAI réduit chaque compteur, Google maintient le context caching au tarif standard sur ses lignes batch Pro, et xAI ne donne aucune réduction batch à grok-4.6.

Il y a aussi une subtilité à connaître si vous magasinez sur le prix. DeepSeek publie une URL de base au format Anthropic sous api.deepseek.com/anthropic, ce qui signifie que le SDK que vous avez écrit pour Claude pointera surtout vers un modèle bien moins cher avec un simple changement d'URL de base. La propre page de DeepSeek prévient aussi d'une augmentation de prix significative à venir, considérez donc le chiffre d'aujourd'hui comme un plancher plutôt qu'un plan. Si la facture est la raison pour laquelle vous lisez ceci, notre sélection d'alternatives à Claude est le point de départ. Le segment moins cher des poids ouverts est couvert séparément, avec des tarifs par modèle pour Qwen et pour Kimi K2.5.

Pourquoi les factures publiques de l'API Claude diffèrent de quatre ordres de grandeur

Si vous cherchez ce que coûte l'API Anthropic en pratique, vous trouverez des chiffres qui ne peuvent tout simplement pas décrire le même produit. Cela vaut la peine de comprendre pourquoi avant d'en prendre un comme référence.

Presque tous les chiffres tapageurs viennent de développeurs qui pointent un agent de codage directement sur une clé API brute. Voici à quoi cela ressemble :

"At API prices it's incredibly easy to burn cash. I ran through my Claude Max 20x last week and had $100 credit from when Anthropic banned OpenClaw, so I decided to use it to get some chores done. Three hours of very light work on Sonnet cost me $55."

u/satansxlittlexhelper, Reddit

Notez que c'est Sonnet, pas Opus, et il décrit le travail comme très léger. Dans le même fil, un autre développeur rapporte un taux de combustion maximal d'environ 50 $ de l'heure, et quelqu'un d'autre a perdu 300 $ en douze heures avec une exécution nocturne sans surveillance. Un commentateur nomme le mode de défaillance précis qui produit ces chiffres : 20 $ perdus à cause d'un agent coincé dans une boucle d'appels d'outils, ce qui est un argument pour les plafonds de dépense et les garde-fous anti-boucle, pas un argument sur le prix.

Maintenant la même API, dans le même fil, faisant un travail borné :

"I'm using the API to relevance classify hundreds of articles a day. Been running for 2 ish weeks, I think I'm almost up to $2 in cost"

u/warnerbr0, Reddit

Cinquante dollars de l'heure et deux dollars en deux semaines, sur la même grille tarifaire. La variable n'est pas la liste de prix, c'est de savoir si la charge de travail a un prompt borné et une sortie bornée, ou une boucle d'agent qui décide elle-même combien dépenser. Presque toutes les affirmations « l'API Claude est chère » que vous lirez mesurent la seconde chose, et presque toute intégration produit côté serveur mesure la première.

La lecture pratique : ignorez complètement les chiffres à l'heure quand vous dimensionnez une intégration normale, et modélisez plutôt la forme de vos propres tokens.

À quoi ressemble la facture pour trois charges de travail réelles

Les prix affichés ne disent pas grand-chose tant qu'on ne les applique pas à une tâche concrète. Les trois exemples ci-dessous utilisent des tarifs publiés, et l'arithmétique est la même que celle exécutée par le widget ci-dessus.

Un classificateur de triage de support. 50 000 tickets par mois, Haiku 4.5, un bloc d'instructions de 3 000 tokens réutilisé à chaque appel plus 400 tokens de texte de ticket, et 150 tokens en sortie. Cela fait 170 $ d'entrée et 37,50 $ de sortie, soit environ 208 $ par mois, ou quatre dixièmes de cent par ticket. Avec le batch, on divise encore par deux. C'est la charge de travail où l'API brute est vraiment presque gratuite, et c'est pourquoi une tarification au ticket sur un outil de support doit se justifier face à quelque chose d'aussi bon marché.

Un agent de codage. 2 000 sessions par mois sur Opus 5, 60 000 tokens d'entrée par session avec 80 % servis depuis le cache, et 12 000 tokens de sortie. L'entrée revient à 120 $ non mis en cache plus 48 $ de lectures de cache, et la sortie à 600 $. Cela fait environ 768 $, la sortie représentant 78 % du total. Sur les charges de travail agentiques, le compteur de sortie est la facture, donc la mise en cache aide bien moins que ne le suggère le titre de la réduction. C'est la chose la plus utile à savoir avant de modéliser le coût d'un agent.

Un rattrapage documentaire ponctuel. 200 000 documents, Sonnet 5, 5 000 tokens en entrée et 800 en sortie, passés en batch. L'entrée revient à 1 000 $ au tarif batch de 1 $ et la sortie à 800 $ à 5 $, soit 1 800 $ pour l'exécution contre 3 600 $ en synchrone. Rien à mettre en cache ici, puisque chaque document est différent, et c'est exactement la forme pour laquelle le batch existe.

Le schéma commun aux trois : la mise en cache gagne sur un trafic répétitif à forte entrée, le batch gagne sur tout ce qu'on peut attendre, et aucun des deux n'apporte grand-chose à un agent qui écrit beaucoup. Faites correspondre le levier à la forme du travail.

Où l'API brute cesse d'être l'option bon marché

Tout ce qui précède tarife les tokens. Cela ne tarife pas le système autour d'eux, et c'est là que la plupart des calculs de build-versus-buy s'effondrent en silence.

J'ai passé les dernières années à mettre des agents IA sur des files de support réelles, et le schéma des appels commerciaux est assez constant pour être prévisible. Un prospect fait un test d'un après-midi, regarde le compteur d'appels bouger, et ne peut pas extrapoler. Une entreprise de sécurité e-mail sur Freshdesk, en route vers 20 000 tickets par an, a brûlé 200 appels API en une seule journée de test et est revenue entièrement préoccupée par ce que 9 000 interactions par mois feraient au chiffre, pas par la qualité des réponses. Un autre opérateur visant 150 000 tickets par mois a fait le calcul à environ 20 cents par ticket, est arrivé à environ 30 000 $ par mois, et s'est arrêté là.

Aucun des deux n'est un problème de prix des tokens. Les deux sont des problèmes d'unité. Personne ne prévoit en millions de tokens, et un compteur par token transforme chaque conversation de capacité en exercice de modélisation plutôt qu'en ligne budgétaire.

Le contre-argument est réel lui aussi, et je préfère le citer que de tourner autour :

"We switched to a system that is working well at half the cost. But long term we will just build our own, which is so possible now with AI. I think you have a decent system for now, but we are probably too large of a customer for this."

Une marque canadienne d'accessoires pour armes à feu utilisant Zendesk avec 2 190 documents synchronisés, tirée des enregistrements internes d'appels commerciaux d'eesel

Ce lecteur a raison de dire que les modèles sont désormais assez bon marché pour rendre la construction en interne tentante, et des frameworks comme AgentKit ont aussi rendu l'échafaudage moins cher. Ce que la facture de tokens laisse de côté, c'est la recherche documentaire sur votre centre d'aide, une intégration au helpdesk qui survit à un changement d'API, des règles d'escalade, un moyen de tester face à des tickets historiques avant de l'exposer aux clients, et quelqu'un dont le travail est de maintenir tout cela en fonctionnement. Nous avons vu un bot au ton confiant donner de mauvaises réponses en production, c'est pourquoi chaque déploiement est désormais d'abord simulé face à de vrais tickets passés, et la simulation n'est pas une ligne qu'on peut acheter sur une grille tarifaire.

La version honnête du compromis : si vous avez besoin d'un classificateur ou d'un résumeur, construisez-le sur l'API et profitez d'une facture mesurée en centimes. Si vous avez besoin de quelque chose qui répond aux clients, chiffrez le coût de l'agent IA de bout en bout, y compris le risque d'hallucinations IA et la maintenance que personne ne budgétise.

Comparez ensuite cela au coût par résolution sur quelque chose déjà construit. Notre décomposition du coût d'un chatbot refait la même arithmétique, et la sélection des logiciels de helpdesk IA couvre ce à quoi vous compareriez.

Une dernière remarque pratique sur la gouvernance, car c'est ce que les gens demandent après leur première facture surprenante. Les plafonds de dépense sont de 500 $ sur Start, 1 000 $ sur Build, et 200 000 $ sur Scale, Custom supprimant complètement le plafond. Les niveaux sont attribués selon l'historique d'usage plutôt qu'achetés, et les nouvelles organisations peuvent démarrer dans un niveau Évaluation en dessous des limites publiées. Atteindre le plafond met l'usage en pause jusqu'au mois civil suivant, ce qui fonctionne de la même manière que les limites de débit d'OpenAI si vous les avez déjà rencontrées.

La page d'usage de la Console affiche directement votre taux de hit de cache, c'est le chiffre à regarder en premier, et cela vaut la peine de bien l'instrumenter avec des outils de suivi LLM si la facture compte. Une remarque structurelle pour quiconque compare les options : sur le plan entreprise, les sièges coûtent 20 $ par mois chacun en plus de l'usage à ces mêmes tarifs API, donc cette grille tarifaire est la facture d'usage entreprise. C'est un calcul différent de celui de Claude Pro, où un abonnement forfaitaire absorbe l'usage à la place.

Essayer eesel pour l'automatisation du support

Si la raison pour laquelle vous chiffrez l'API Anthropic est une file de support, l'unité est ce qu'il faut corriger avant le tarif. eesel facture 0,40 $ par ticket, sans sièges et sans frais de plateforme, un chiffre que vous pouvez intégrer à une prévision sans modéliser le nombre de tokens par conversation. Il se connecte à Zendesk, Freshdesk ou Gorgias en quelques minutes, s'entraîne sur votre centre d'aide existant et vos tickets passés, et simule sur votre historique de tickets avant de jamais répondre à un client, afin que vous voyiez le taux de résolution et le coût projetés avant la mise en production.

Vous conservez malgré tout la visibilité par action qu'une construction sur API brute vous forcerait à monter vous-même, ce qui est généralement la première chose que les équipes oublient en estimant la construction. Gratuit à essayer, et vous pouvez voir les chiffres projetés avant de vous engager sur quoi que ce soit.