GPT-6 Astra coûte $10.00 en entrée et $50.00 en sortie par 1M de tokens. GPT-5.6 Sol coûte $4.00 et $20.00 en tarif promotionnel, Terra $2.00 et $12.00, et Luna $0.20 et $1.20. Ce sont des tarifs Standard en contexte court, tirés de la page de prix officielle, vérifiés le 8 septembre 2026. Le tarif promotionnel de Sol est disponible au moins jusqu'au 21 novembre 2026.
Pour ces quatre modèles, le niveau de service, la tranche de contexte et l'état du cache influencent le tarif, tandis que le raisonnement influence le nombre de tokens de sortie que vous consommez. Le tarif de sortie de Sol va désormais de $10.00 en Batch avec contexte court à $60.00 en Fast avec contexte long. Comparez la configuration réelle de la requête plutôt que de supposer qu'un modèle moins cher fait toujours baisser la facture.
Pour une file de support, comparez aussi le coût du workflow complet. La tarification par crédits d'eesel (1 crédit par ticket ou chat) utilise des unités différentes d'une facture de l'API OpenAI. Le pas-à-pas de la CLI plus bas montre comment un agent de code peut inspecter la facturation de l'espace de travail et l'activité du teammate sélectionné, y compris le coût des répétitions par chat.
Pourquoi les multiplicateurs m'importent plus que les tarifs
Je construis des intégrations et des API chez eesel. Pour un workflow de support, je veux savoir plus que le prix d'un appel de modèle : combien de contexte chaque requête contient, quels outils elle utilise et comment ce travail est facturé.
Nos notes commerciales de février 2026 décrivent une entreprise de sécurité des e-mails sur Freshdesk qui se dirigeait vers 20,000 tickets par an. L'acheteur disait avoir utilisé 200 appels d'API en une journée de test et s'inquiétait des coûts à 9,000 interactions mensuelles attendues. C'est une inquiétude historique sur le volume de test, pas une facture OpenAI ni la preuve qu'une taille de prompt précise a causé le coût. Je commencerais par établir l'unité de facturation avant d'extrapoler un essai vers un budget de production.
C'est toute la raison pour laquelle cet article est structuré ainsi. La grille tarifaire vient d'abord parce que vous l'avez demandée, puis les quatre éléments qui la font réellement bouger, car c'est ce que je regarderais si vous me tendiez votre facture en demandant pourquoi elle avait doublé le mois dernier.
Prix sélectionnés des modèles de l'API OpenAI
Les tarifs de modèles sélectionnés ci-dessous sont par 1M de tokens en USD, vérifiés sur la page de prix d'OpenAI le 8 septembre 2026. Ce tableau utilise les tarifs Standard en contexte court ; la page officielle liste aussi des modèles plus anciens et des services spécialisés.
| Modèle | Entrée | Entrée en cache | Écriture en cache | Sortie | Fenêtre de contexte | Sortie max. |
|---|---|---|---|---|---|---|
gpt-6-astra | $10.00 | $1.00 | $12.50 | $50.00 | 1,050,000 | 128,000 |
gpt-5.6-sol | $4.00 | $0.40 | $5.00 | $20.00 | 1,050,000 | 128,000 |
gpt-5.6-terra | $2.00 | $0.20 | $2.50 | $12.00 | 1,050,000 | 128,000 |
gpt-5.6-luna | $0.20 | $0.02 | $0.25 | $1.20 | 1,050,000 | 128,000 |
gpt-5.6-cyber | $12.50 | $1.25 | $15.625 | $75.00 | 400,000 au total ; max. 272,000 en entrée | 128,000 |
chat-latest | $5.00 | $0.50 | non indiqué | $30.00 | non indiqué | non indiqué |
gpt-5.3-codex | $1.75 | $0.175 | non indiqué | $14.00 | non indiqué | non indiqué |
gpt-5.6 est un alias qui redirige vers Sol. Sol, Terra et Luna partagent une date limite de connaissances au 16 février 2026 et acceptent pour reasoning.effort les valeurs none, low, medium (par défaut), high, xhigh et max, d'après leur documentation des modèles. Astra a ses propres spécifications ; n'appliquez pas à Astra les valeurs par défaut de GPT-5.6. Notre liste des modèles OpenAI couvre la gamme complète.
Deux lignes méritent une remarque. gpt-5.6-cyber, le modèle Daybreak Red, affiche $12.50 en entrée et $75 en sortie, sans tranche de contexte long dans la grille. Ces tarifs valent respectivement 3.125x et 3.75x les tarifs promotionnels actuels de Sol en entrée et en sortie. Notre guide des tarifs de GPT-5.6 Cyber couvre ce modèle. Par ailleurs, chat-latest affiche $5 en entrée et $30 en sortie, il ne partage donc plus les tarifs actuels de Sol.
Les alias gpt-daybreak-blue-latest et gpt-daybreak-red-latest pointent actuellement vers gpt-5.6-sol et gpt-5.6-cyber. OpenAI indique que leurs cibles et leurs prix changeront à mesure que de nouveaux modèles entreront dans le programme. Utiliser un alias mobile ne fige donc ni une version de modèle ni un prix.
La révision tarifaire du 30 juillet a changé où placer les appels de modèle
Le journal des modifications d'OpenAI consigne une baisse de prix de 80 % pour Luna et de 20 % pour Terra à partir du 30 juillet 2026. Leurs tarifs Standard actuels en contexte court sont respectivement $0.20/$1.20 et $2/$12. Les tarifs promotionnels ultérieurs de Sol figurent séparément dans le tableau actuel ci-dessus. Un commentateur de Hacker News a réagi à la baisse de Luna :
"80% price cut for luna is a very aggressive pricing move"
Un post d'AI Builders a souligné l'écart qui en résulte entre Luna et Terra :
"Luna and Terra now sit 10x apart on both input and output, where the gap was 2.5x."
Aux tarifs actuellement affichés, les prix d'entrée et de sortie de Terra valent chacun 10x ceux de Luna. Cela rend Luna digne d'être évalué pour des charges adaptées, mais ne prouve pas qu'une équipe qui utilise Terra paie trop : la précision, la consommation de tokens et la latence peuvent différer. Un commentateur décrivant des benchmarks internes dans le fil sur Gemini 3.7 Flash a rapporté :
"Then gpt-5.6-luna came along with the price cuts and immediately supplanted gpt-5-mini."
Le niveau de service et la tranche de contexte changent le tarif
Pour Astra, Sol, Terra et Luna, la page de prix liste quatre niveaux de service et deux tranches de contexte. Chaque combinaison a des tarifs distincts pour l'entrée, l'entrée en cache, l'écriture en cache et la sortie. D'autres modèles ont une disponibilité différente ; n'appliquez pas cette disposition à toutes les lignes de la page.
| Facteur de coût | Ce qui change | Ce qu'il faut mesurer |
|---|---|---|
| Niveau de service | Tarifs d'entrée et de sortie du niveau choisi | Niveau effectif de chaque requête |
| Tranche de contexte | Tarifs de toute la requête au-delà du seuil du modèle | Total des tokens d'entrée par requête |
| État du cache | Tarifs d'entrée uniquement : entrée ordinaire, lectures ou écritures | Tokens facturés dans chaque catégorie d'entrée |
| Raisonnement | Quantité de sortie facturée, pas un multiplicateur de tarif distinct | Tokens de raisonnement en plus de la sortie visible |
Sur la seule sortie, gpt-5.6-sol va de $10.00 par million de tokens (Batch, contexte court) à $60.00 (mode Fast, contexte long). C'est un écart de 6x sur le tarif de sortie selon les combinaisons de niveau et de tranche de contexte, sans que le même prompt relève forcément des deux tranches. Aux tarifs Standard en contexte court, l'entrée en cache coûte $0.40 par million de tokens et les écritures en cache coûtent $5.00. Ce sont les tarifs promotionnels actuels de Sol, disponibles au moins jusqu'au 21 novembre 2026.
Je comparerais le modèle et le niveau de service ensemble. Par exemple, ces tarifs sont tous par million de tokens :
| Configuration | Entrée | Sortie |
|---|---|---|
gpt-5.6-sol en Batch, contexte court | $2.00 | $10.00 |
gpt-5.6-terra en mode Fast, contexte court | $4.00 | $24.00 |
gpt-5.6-terra en mode Fast, contexte long | $8.00 | $36.00 |
Aux tarifs de contexte court, Terra en mode Fast coûte 2x Sol en Batch en entrée et 2.4x en sortie. Passer de Sol Batch à Terra Fast peut donc augmenter les coûts en tokens alors même qu'on choisit un modèle moins cher. Ne changer que le modèle en gardant le même niveau est une autre comparaison. Batch a aussi des exigences de latence différentes ; je vérifierais donc si la charge peut attendre avant de le traiter comme une option interchangeable.
La falaise des 272K
La page de prix sépare les tarifs de contexte court et long. La page du modèle GPT-5.6 Sol explique quand la tranche supérieure s'applique :
Prompts with >272K input tokens are priced at 2x input and 1.5x output for the full request.
Trois choses en découlent, et les trois comptent.
Premièrement, le seuil est de 272,000 tokens d'entrée, pas la fenêtre de contexte de 1,050,000 tokens que le marketing met en avant. Vous obtenez environ un quart de la fenêtre annoncée au prix annoncé.
Deuxièmement, il retarife toute la requête, pas seulement le dépassement. Aux tarifs Standard actuels de Sol, un prompt de 272,001 tokens sans entrée en cache facture toute son entrée à $8 par million, et non 272,000 tokens à $4 et un à $8. Les lectures et écritures en cache ont aussi leurs propres colonnes en contexte long.
Troisièmement, il déplace aussi la sortie, de 1.5x, alors que la longueur de votre réponse n'a rien à voir avec la longueur du prompt.
Le tableau des prix et la page du modèle doivent être lus ensemble. Le post LinkedIn de Korbinian Abstreiter décrit sa surprise face au seuil :
"Still didn't expect it"
Je chercherais du contexte redondant avant de franchir 272K, puis je testerais si la compaction préserve l'information nécessaire pour répondre correctement. Une facture de tokens plus basse n'est pas une économie utile si elle supprime des éléments essentiels.
Une discussion sur Hacker News relie les réglages de contexte de Codex aux frais de contexte long. Un commentateur a proposé cette explication :
"It cost people a LOT of money."
C'est le récit du commentateur, pas une explication officielle de la décision produit. Il n'établit ni les motivations d'OpenAI ni le réglage par défaut actuel de Codex. Pour ce budget d'API, la vérification pertinente est le nombre de tokens d'entrée et la tranche tarifaire de chaque requête.
Un calcul simplifié d'attention quadratique n'est pas une mesure des coûts de service d'un fournisseur. L'architecture, le cache et le matériel comptent aussi, il ne peut donc pas établir pourquoi OpenAI a choisi ce palier de prix. Le seuil lui-même est explicite ; un commentateur a remis en question sa forme abrupte :
"I'm actually surprised it's implemented as a hard cutoff instead of a smooth gradient."
Le guide des limites de débit décrit des limites distinctes pour les requêtes en contexte long. Vérifiez les limites applicables dans votre console développeur ; un pool séparé n'établit pas à lui seul un débit plus faible. Notre guide des limites de débit d'OpenAI explique les limites associées.
La tarification dépendante du contexte n'est pas propre à OpenAI, mais les seuils diffèrent. La page du modèle Grok 4.6 affiche une tarification de contexte supérieur au-delà de 200K, pas la frontière de 272K d'OpenAI. Consultez le tableau propre à chaque modèle de chaque fournisseur plutôt que de traiter ces majorations comme équivalentes. Notre guide des tarifs de Grok 4.6 couvre ce modèle séparément.
Ce que la falaise coûte dans une charge hypothétique
Prenons un bot de réponses à récupération hypothétique sur Sol : 40,000 tokens d'entrée par requête, 900 tokens de sortie facturés, 30,000 requêtes par mois, 50 % de l'entrée facturée en cache. Cela fait $3,180 par mois en Standard pour les seuls tokens, hors écritures en cache, frais d'outils et frais de traitement régional.
Supposons maintenant que quelqu'un élargisse la fenêtre de récupération et que chaque requête porte 300,000 tokens d'entrée. Même modèle, même niveau, même volume.
| Tokens d'entrée par requête | Tranche | Coût mensuel |
|---|---|---|
| 40,000 | courte | $3,180 |
| 271,000 | courte | $18,426 |
| 300,000 | longue | $40,410 |
Dans cet exemple, ramener le prompt de 300,000 à 271,000 tokens fait passer le coût mensuel estimé en tokens de $40,410 à $18,426. C'est environ 54 % de moins pour avoir retiré 29,000 tokens d'entrée par requête. Je testerais d'abord si le contexte retiré nuit à la qualité des réponses. Cette économie dépend du fait que la charge franchit le seuil tarifaire ; elle n'établit pas que réduire le contexte l'emporte toujours sur un changement de modèle.
Un post sur r/openrouter décrit une estimation locale de coût qui différait du tableau de bord du fournisseur. L'auteur a collé une explication générée par un LLM, avec cette affirmation :
"Approximately 221 requests exceeded the 272K threshold."
L'auteur a rapporté environ $1.35 dans OpenCode et $2.30 dans OpenRouter. Le rapprochement à $2.297 et le chiffre de 221 requêtes venaient de la réponse collée du modèle, pas d'un export d'usage vérifié de façon indépendante. Je le traiterais comme une piste à vérifier avec les relevés du fournisseur, pas comme une preuve du calcul. Il concerne en outre la tarification d'OpenRouter, pas une facture OpenAI directe.
Le prompt caching offre 90 % de remise et 25 % de pénalité
Aux tarifs Standard actuels en contexte court de Sol, l'entrée en cache coûte $0.40 par million de tokens contre $4.00 hors cache, soit 90 % de remise. Les écritures en cache coûtent $5.00 par million de tokens, 1.25x le tarif d'entrée hors cache. Le guide du prompt caching distingue entrée ordinaire, lectures de cache et écritures de cache ; je comptabiliserais les trois plutôt que d'appliquer une remise unique au prompt.
Le guide du cache distingue GPT-5.6 et les modèles ultérieurs, qui facturent les écritures en cache, des modèles antérieurs sans ce frais supplémentaire. Un commentateur a remarqué la différence en comparant les pages des modèles :
"There was no cache write before!"
"Anyway this does mean the "real" prices are +25% on top of what you wrote there."
Pour la même quantité de tokens de préfixe éligibles, une écriture plus une réutilisation complète coûte 1.35x le traitement ordinaire de l'entrée, contre 2x pour deux passages hors cache. Aux tarifs de contexte court de Sol, cela fait $5.40 au lieu de $8.00 par million de tokens de préfixe sur ces deux passages. Une écriture sans réutilisation ultérieure coûte 25 % de plus que le traitement ordinaire de l'entrée. Les charges à requêtes uniques peuvent donc gagner à contrôler quel contenu est écrit, une préoccupation soulevée dans ce fil de r/OpenAI :
"Most of our API usage isn't for chat bots or long-running agents. We build task-oriented applications where every request is unique: document processing, …"
Le guide du cache d'OpenAI explique que les états clé-valeur en cache préservent le travail d'un préfixe antérieur. Ils occupent des ressources tant qu'ils sont conservés, mais ce mécanisme seul ne prouve pas le coût du fournisseur ni ne justifie une majoration précise. À titre de comparaison, les tarifs d'Anthropic indiquent des écritures Opus 5 à 1.25x l'entrée ordinaire pour cinq minutes de rétention et 2x pour une heure. Comparez la rétention et le schéma de réutilisation, pas seulement le multiplicateur d'écriture.
La mécanique qui décide si vous gagnez le pari
Tiré du guide du prompt caching :
| Mécanique | Valeur |
|---|---|
| Préfixe minimal pouvant être mis en cache, GPT-5.6 et ultérieurs | 1,024 tokens, un minimum strict |
| Minimum sur les modèles antérieurs | 2,048 tokens visibles ; certains modèles antérieurs peuvent produire des succès en dessous |
| Durée de vie du cache, GPT-5.6 et ultérieurs | Au moins 30 minutes après la dernière écriture ou réutilisation ; la réutilisation n'entraîne pas de nouveau frais d'écriture |
| Tarif de lecture du cache | 10 % du tarif d'entrée |
| Tarif d'écriture du cache | 125 % du tarif d'entrée |
| Correspondance | Correspondance exacte du préfixe à un point d'arrêt éligible |
| Clé de routage | prompt_cache_key facultatif ; des clés stables aident à router les préfixes partagés, mais ne garantissent pas la réutilisation |
| Capacité de routage | Au-dessus d'environ 15 requêtes par minute sur une machine, le routage de débordement peut provoquer des échecs de cache |
| Écritures par requête | Maximum de 4 |
| Points d'arrêt pris en compte à la lecture | Les 50 derniers |
Pour GPT-5.6 et ultérieurs, un cache uniquement explicite peut placer un point d'arrêt après des instructions stables et laisser le contenu variable du ticket hors de l'écriture en cache. Avec le mode explicite et sans point d'arrêt, la requête ne lit ni n'écrit dans le cache. Cela compte pour les requêtes de support uniques : répéter les mêmes instructions ne suffit pas si le seul point d'arrêt enregistré inclut aussi le message d'un autre client. Je comparerais cached_tokens, cache_write_tokens et le coût total d'entrée avant et après un changement.
Pour une file de support chargée, je surveillerais le routage autant que la correspondance de préfixe. La documentation explique que le trafic au-delà d'environ 15 requêtes par minute sur une machine peut déborder ailleurs et rater son cache. Ce n'est ni une limite garantie par clé ni une promesse que chaque requête au-dessus rate. Si les succès de cache d'un groupe chargé diminuent, répartissez-le sur des clés stables, puis mesurez le résultat. Les clés influencent le routage ; elles ne réservent pas une machine.
La documentation est aussi explicite : "repeated prompt content alone does not guarantee a cache hit." Les modes de défaillance sont banals et coûteux, et le texte LinkedIn d'Eric Nowoslawski en donne l'énoncé le plus clair que j'aie trouvé, de la part de quelqu'un qui s'est d'abord trompé :
"We were messing it up with putting custom parts of the prompt in the second or third sentence."
La durée de vie du cache compte pour le travail planifié. Prenons dix requêtes hypothétiques espacées de dix minutes, chacune réutilisant le même préfixe éligible de 100,000 tokens. Aux tarifs Standard actuels en contexte court de Sol, traiter ce préfixe sans cache dix fois coûte $4.00. Une écriture suivie de neuf lectures de cache complètes coûte $0.86 : $0.50 pour l'écriture plus neuf lectures à $0.04 chacune. Cela exclut les autres tokens d'entrée et de sortie.
Une durée de vie de 30 minutes permet la réutilisation sur ces intervalles de dix minutes, mais le timing seul ne garantit pas les succès : les points d'arrêt correspondants et le routage comptent toujours. Un cache qui expirerait avant chaque requête changerait le résultat. Je comparerais les réglages de rétention réels et la réutilisation observée avant d'affirmer qu'un fournisseur est moins cher. Le post sur le cache de Ravi Kiran insiste sur la réutilisation et le routage. Ses affirmations chiffrées sur les taux de succès concernent d'autres configurations de service et ne constituent pas une référence mesurée pour votre application OpenAI. Le point pratique est :
"You need sticky routing, stable prefixes, and workloads that actually repeat."
J'utiliserais dans le calculateur la fraction mesurée de tokens d'entrée servis depuis le cache, puis je testerais des scénarios à plus faible taux de succès. Ni 30 % ni 90 % ne sont une valeur par défaut défendable pour toute application, et l'estimation du calculateur exclut toujours les frais d'écriture en cache.
Les tokens de raisonnement sont facturés au tarif de sortie
Les trois modèles GPT-5.6 acceptent reasoning.effort à none, low, medium, high, xhigh ou max, avec medium par défaut. Ces tokens de raisonnement sont facturés comme des tokens de sortie.
L'effort de raisonnement affecte le volume de tokens, pas le tarif par token. Par exemple, la sortie de Sol en Standard et contexte court coûte $20 par million de tokens, tokens de raisonnement facturés inclus. Un réglage d'effort plus élevé peut augmenter la consommation, mais l'ampleur du changement dépend de la tâche. Je le mesurerais plutôt que de supposer un multiplicateur fixe entre niveaux d'effort.
"But at least via the API, you pay for tokens you cannot see."
L'effet en cascade est que l'effort de raisonnement écrase en partie l'écart de prix que les niveaux de modèles sont censés représenter. Un commentateur du fil sur Qwen 3.8 Max l'a formulé précisément :
"So a mid priced model, with heavy reasoning output, cost the same as a expensive model, with medium reasoning output."
Lorsque vous comparez des réglages de raisonnement, notez le modèle, les tâches d'évaluation, le niveau d'effort et le total de tokens facturés. Un benchmark tiers peut suggérer des candidats à tester, mais ce n'est pas une mesure de votre file de support. Je comparerais qualité et coût sur les mêmes requêtes représentatives avant de choisir un réglage.
Un développeur a partagé une analyse d'usage locale valorisée aux tarifs catalogue d'Opus 4.7, pas une facture OpenAI. L'estimation du fil principal était de $19,221 : 56 % de lectures de cache, 35 % d'écritures de cache et 8 % de sortie raisonnement compris. L'analyse plus large couvrait 933 sessions sur des fils principaux et des sous-agents, avec une estimation combinée d'environ $22,720. Ce sont des coûts reconstitués par l'auteur, pas des frais payés vérifiés.
"Same shape as yours: re-read dominates, reasoning is the biggest re-read line, caching is the only thing keeping it sane."
Cette estimation rapportée illustre une répartition possible des coûts, pas une règle pour tous les agents. Retraiter sans cesse une longue conversation peut faire de l'entrée en cache une dépense importante même avec un taux de succès élevé. D'autres charges peuvent être dominées par la sortie, les écritures en cache ou les outils. Je séparerais ces catégories dans les relevés d'usage réels avant de choisir une optimisation.
Je mesurerais le nombre de tokens et la qualité des réponses à chaque niveau d'effort sur du trafic représentatif. Changer le niveau de service, raccourcir le contexte redondant, améliorer la réutilisation et choisir un autre modèle traitent des coûts différents. Notre guide des modèles d'IA pour les tickets de support traite du choix de modèle pour cette charge ; ce n'est pas une preuve qu'une optimisation l'emporte sur toutes les files.
Batch, Flex et mode Fast
Pour les quatre modèles du calculateur, les niveaux de service modifient les tarifs de tokens publiés comme indiqué ci-dessous. Flex et Fast utilisent un réglage de requête ; Batch exige de soumettre le travail via le workflow distinct de la Batch API.
| Niveau | Multiplicateur | Ce que vous cédez ou obtenez | Valeur du champ |
|---|---|---|---|
| Batch | 0.5x | Fenêtre d'achèvement de 24 heures, aucune autre fenêtre proposée | Point d'accès de la Batch API |
| Flex | 0.5x | Réponses plus lentes, indisponibilité occasionnelle des ressources | service_tier: "flex" |
| Standard | 1x | Tarif de base | Vérifiez le niveau effectif ; un réglage omis suit la valeur par défaut du projet |
| Mode Fast | 2x | Jusqu'à 2.5x plus rapide, latence plus régulière | service_tier: "fast" ou "priority" |
Quelques détails de la documentation qui changent la façon de les utiliser.
La Batch API offre 50 % de coût de tokens en moins et un pool de limites de débit distinct. Pour Sol au Tier 5, la file batch affichée contient 15 milliards de tokens d'entrée ; c'est une limite de capacité de file, pas un débit directement comparable à son plafond synchrone de 40 millions de tokens par minute. Un batch autorise jusqu'à 50,000 requêtes et un fichier d'entrée de 200 Mo, avec jusqu'à 2,000 créations de batch par heure. Sa fenêtre d'achèvement prise en charge est de 24 heures. Si un batch expire, les requêtes inachevées sont annulées et les requêtes terminées restent facturables. Il convient donc au travail qui peut attendre, pas à chaque réponse de support en direct. Un praticien a évoqué l'adaptation de l'expérience produit à ce délai :
"The other thing I started looking into is batch pricing which represents 50% off for OAI tokens right now."
Vérifiez la prise en charge de Batch pour le modèle et le point d'accès exacts avant de concevoir autour. La page de prix comprend des lignes Batch pour plusieurs modèles Pro ; ni l'étiquette Pro ni un prix Standard élevé n'établissent donc que Batch est indisponible. La latence reste une contrainte distincte. Notre décomposition des tarifs de Codex couvre les coûts de ce modèle.
Le traitement Flex utilise les tarifs de tokens de Batch pour des requêtes synchrones sur les modèles pris en charge. Il peut être plus lent ou temporairement indisponible ; OpenAI le recommande donc pour du travail de moindre priorité comme les évaluations et l'enrichissement. Le guide montre un délai d'expiration de 15 minutes pour les requêtes longues. Une erreur Flex de ressource indisponible n'est pas facturée, mais cela ne veut pas dire que toute requête échouée ou expirée est gratuite. Bornez les nouvelles tentatives et décidez explicitement si le repli vers le niveau par défaut du projet vaut son coût différent.
Le mode Fast a été renommé à partir de Priority processing le 30 juillet 2026. service_tier: "priority" et service_tier: "fast" sont tous deux pris en charge. OpenAI annonce des vitesses jusqu'à 2.5x supérieures pour Sol, pas une réduction de latence garantie sur chaque requête. Pour les quatre modèles du calculateur, les tarifs de tokens Fast publiés sont le double des tarifs Standard ; cela double le prix par token, pas le nombre de tokens utilisés. Fast ne prend pas en charge les modèles fine-tunés ni les embeddings.
Vérifiez aussi la valeur par défaut du projet, pas seulement la requête. Un projet configuré pour Fast peut l'utiliser quand service_tier est omis ; l'omission ne garantit pas une tarification Standard. Le service_tier de la réponse identifie le niveau réellement utilisé. Les réponses de GPT-5.6 indiquent priority pour Fast, et les requêtes rétrogradées pendant une croissance rapide du trafic peuvent indiquer default et être facturées au tarif Standard.
Deux avertissements. D'abord, le mode Fast se cumule avec la majoration de contexte long : l'entrée en contexte long de Sol en Fast coûte $16.00 par million de tokens, contre $4.00 pour l'entrée Standard en contexte court. C'est 4x, pas 2x. Ensuite, vérifiez le niveau effectif de vos requêtes plutôt que de supposer qu'une tâche d'arrière-plan utilise Standard :
"When I was going through this it was because OpenAI had defaulted to /fast mode with 2x token usage"
C'était quelqu'un qui diagnostiquait un pic inexpliqué de consommation dans le fil du lancement de GPT-5.6. Savoir si 2.5x de vitesse valent 2x de coût est une vraie question, avec une vraie réponse pour votre produit. Le payer par accident sur une tâche d'arrière-plan n'est même plus une question.
Tout le reste qui atterrit sur la facture
Les tokens ne sont pas toute la facture. Les outils, l'audio, les images et la vidéo ont chacun leur propre compteur, et c'est là qu'un prototype « bon marché » cesse discrètement de l'être.
Outils
| Outil | Détail | Prix |
|---|---|---|
| Recherche web | Tous les modèles | $10.00 / 1k appels, plus tokens de contenu aux tarifs du modèle |
| Aperçu de recherche web | Modèles sans raisonnement | $25.00 / 1k appels, tokens de contenu gratuits |
| Recherche de fichiers | Appel d'outil | $2.50 / 1k appels |
| Recherche de fichiers | Stockage | $0.10 / Go par jour, 1 Go gratuit |
| Conteneurs | Hosted Shell et Code Interpreter | $0.03 à $1.92 par session de 20 min, selon la taille de mémoire |
| AgentKit | Stockage des envois ChatKit | $0.10 / Go-jour après 1 Go gratuit par mois |
Les tokens de contenu de la recherche web sont du matériel récupéré transmis au modèle et facturé à son tarif d'entrée, en plus des frais d'appel de recherche applicables. Les sessions de conteneur éligibles sont mesurées à la minute avec un minimum de cinq minutes ; vérifiez les conditions tarifaires de la session plutôt que de supposer que toute exécution brève est facturée au prorata. Le tarif des appels d'outil de recherche de fichiers s'applique à la Responses API. Notre guide d'AgentKit, la référence de l'API des vector stores et le guide de l'Assistants API couvrent ces interfaces différentes.
Audio, temps réel et transcription
| Modèle | Modalité | Entrée | Entrée en cache | Sortie |
|---|---|---|---|---|
gpt-realtime-2.1 | Audio | $32.00 | $0.40 | $64.00 |
gpt-realtime-2.1 | Texte | $4.00 | $0.40 | $24.00 |
gpt-realtime-2.1-mini | Audio | $10.00 | $0.30 | $20.00 |
gpt-realtime-2.1-mini | Texte | $0.60 | $0.06 | $2.40 |
La sortie audio coûte $64.00 par million de tokens pour gpt-realtime-2.1, contre $20.00 pour sa variante mini. Ce sont des tarifs de tokens audio ; les comparer directement aux prix de tokens texte ne donne donc pas le coût d'une conversation. Je mesurerais l'usage audio et la qualité des réponses sur des appels représentatifs. Notre guide des tarifs de GPT-realtime mini discute de ce compromis, et le guide de l'API audio et voix couvre la voie hors temps réel.
La page de prix fournit des tarifs ou estimations à la minute pour la transcription. Certains modèles ont aussi une tarification par tokens ; ces chiffres ne doivent donc pas tous être lus comme un contrat de facturation forfaitaire à la minute :
| Modèle | Cas d'usage | Coût par minute |
|---|---|---|
gpt-realtime-translate | Traduction en direct | $0.034 |
gpt-live-transcribe | Transcription en direct | $0.017 |
gpt-realtime-whisper | Transcription en direct | $0.017 |
gpt-transcribe | Transcription | $0.0045 |
gpt-4o-transcribe | Transcription | $0.006 |
gpt-4o-mini-transcribe | Transcription | $0.003 |
Les $0.017 par minute affichés pour gpt-live-transcribe valent environ 3.8x le tarif de $0.0045 de gpt-transcribe. Ce dernier tarif est inférieur d'environ 74 %, mais ce sont des modèles et des workflows différents. Cette comparaison n'est pas une remise de la Batch API ; testez la latence, la précision et les besoins fonctionnels avant de changer.
Embeddings
OpenAI publie les prix des embeddings par million de tokens d'entrée sur sa page de prix : $0.02 pour text-embedding-3-small, $0.13 pour text-embedding-3-large et $0.10 pour text-embedding-ada-002. Le guide des embeddings donne aussi des comparaisons illustratives de pages par dollar et de benchmarks :
| Modèle | Pages par dollar | Score MTEB | Entrée max. |
|---|---|---|---|
text-embedding-3-small | 62,500 | 62.3% | 8,192 |
text-embedding-3-large | 9,615 | 64.6% | 8,192 |
Le tarif par token du grand modèle est 6.5x celui du petit. L'écart de benchmark n'établit pas à quel point il retrouvera mieux les réponses de votre centre d'aide. Je testerais les deux sur les mêmes questions et documents, en vérifiant aussi le découpage en chunks et les réglages de récupération. Nos notes sur la création d'une base de connaissances IA couvrent cette configuration.
Images et vidéo
gpt-image-2 facture $8.00 par 1M de tokens d'entrée image, $2.00 en cache et $30.00 en sortie, avec l'entrée texte à $5.00. Notez qu'ici l'entrée en cache vaut 25 % de l'entrée, et non les 10 % dont bénéficient les modèles texte. Batch divise le tout par deux.
Le guide de génération liste ces estimations de coût de sortie de GPT Image 2 pour des tailles choisies. Ajoutez l'entrée texte et d'éventuels frais d'entrée d'image de référence pour estimer une requête complète :
| Qualité | Carré 1024x1024 | Portrait 1024x1536 | Paysage 1536x1024 |
|---|---|---|---|
| Basse | $0.006 | $0.005 | $0.005 |
| Haute | $0.211 | $0.165 | $0.165 |
D'après ces estimations de coût de sortie affichées, une image carrée en haute qualité coûte environ 28 % de plus qu'une image paysage en haute qualité, malgré moins de pixels. De la basse à la haute qualité sur le carré, l'augmentation est d'environ 35x. Chaque image partielle diffusée ajoute 100 tokens de sortie image. Nos notes sur l'API d'édition d'images couvrent les points d'accès d'édition.
La vidéo est facturée à la seconde, pas au token :
| Modèle | Taille | Standard | Batch |
|---|---|---|---|
sora-2 | 720p | $0.10 | $0.05 |
sora-2-pro | 720p | $0.30 | $0.15 |
sora-2-pro | 1024p | $0.50 | $0.25 |
sora-2-pro | 1080p | $0.70 | $0.35 |
Une seule minute de sora-2-pro en 1080p coûte $42.00 en Standard. Notre décomposition de Sora 2 couvre ce que vous obtenez en échange.
Les niveaux d'utilisation décident de ce que vous avez le droit de dépenser
Les niveaux d'utilisation d'OpenAI associent des conditions de paiement à des limites d'utilisation mensuelles approuvées et à des limites de débit par modèle. Ils sont distincts des alertes de dépense et des limites strictes que vous configurez vous-même. Le montant en dollars de la ligne Free est une limite d'utilisation approuvée, pas une attribution de crédits gratuits.
| Niveau | Condition | Limite d'utilisation mensuelle |
|---|---|---|
| Free | Zones géographiques autorisées uniquement | $100 / mois |
| Tier 1 | $5 payés | $100 / mois |
| Tier 2 | $50 payés | $500 / mois |
| Tier 3 | $100 payés | $1,000 / mois |
| Tier 4 | $250 payés | $5,000 / mois |
| Tier 5 | $1,000 payés | $200,000 / mois |
Et les limites de débit par modèle évoluent avec lui. Pour gpt-5.6-sol :
| Niveau | RPM | TPM | Limite de la file batch |
|---|---|---|---|
| Tier 1 | 500 | 500,000 | 1,500,000 |
| Tier 2 | 5,000 | 1,000,000 | 3,000,000 |
| Tier 3 | 5,000 | 2,000,000 | 100,000,000 |
| Tier 4 | 10,000 | 4,000,000 | 200,000,000 |
| Tier 5 | 15,000 | 40,000,000 | 15,000,000,000 |
La page actuelle du modèle Sol affiche des limites Standard à partir du Tier 1 ; le guide des niveaux d'utilisation indique $5 payés comme condition de ce niveau. Une condition de paiement n'est pas la même chose que $5 de tokens consommés. Le Tier 5 offre 10x le TPM affiché du Tier 4 et 75x sa capacité de file batch, mais ce n'est pas une exigence universelle de production. Je comparerais la demande de pointe de l'application aux limites réelles de votre organisation et de votre projet.
Les limites de débit sont fixées au niveau de l'organisation et du projet, pas par utilisateur, et certaines familles de modèles partagent un pool ; un outil interne bruyant peut donc brider votre trafic de production. L'ingestion des vector stores a son propre plafond de 300 requêtes par minute et par store.
Pour la maîtrise des coûts, les alertes de dépense et les limites strictes de dépense jouent des rôles différents. Une alerte envoie une notification pendant que le trafic continue. Une limite stricte appliquée à l'organisation ou au projet fait renvoyer 429 aux requêtes concernées une fois la dépense suivie arrivée au montant configuré. L'application a un délai, l'usage enregistré peut donc dépasser légèrement le plafond. J'associerais les alertes à une décision délibérée sur une limite stricte et à un repli côté application, car un plafond peut aussi interrompre le support client. Réessayer après une erreur de limite de dépense ne rétablit pas le budget.
Tarification régionale, facturation cloud et échéances du fine-tuning
La résidence des données coûte 10 %. La note apparaît sous les quatre tableaux de niveaux de service : les points d'accès de traitement régional "are charged a 10% uplift for models released on or after March 5, 2026, that are eligible for data residency." Si vous êtes dans un secteur réglementé et pensiez que le traitement dans l'UE était gratuit, ce n'est pas le cas. Le guide sur vos données liste les régions prises en charge.
Bedrock utilise la facturation AWS. Le guide OpenAI sur Bedrock distingue cette voie de l'API directe. Les prix peuvent différer, vérifiez donc le modèle et la région AWS applicables. Les limites de contexte de Bedrock sont aussi propres à chaque modèle : 272,000 tokens pour GPT-5.4 et GPT-5.5, mais 1,050,000 pour GPT-5.6 Sol, Terra et Luna. N'appliquez pas la limite des anciens modèles à toute l'intégration.
Le fine-tuning en libre-service a aussi une échéance. La page des dépréciations indique que les organisations sans fine-tuning antérieur ont perdu l'accès à l'entraînement le 7 mai 2026. Le 2 juillet, l'accès a pris fin pour les organisations sans inférence de modèle fine-tuné au cours des 60 jours précédents. Les clients actifs existants perdent la possibilité de créer de nouveaux jobs de fine-tuning le 6 janvier 2027. L'inférence se poursuit jusqu'à la dépréciation du modèle de base sous-jacent, qui peut avoir une échéance distincte et plus proche. La page de prix liste encore plusieurs modèles de fine-tuning ; un prix affiché n'établit pas que votre organisation peut lancer un job d'entraînement.
Si votre modèle de coûts repose sur le fine-tuning d'un modèle plus petit, vérifiez à la fois l'éligibilité à l'entraînement et la date de retrait du modèle de base. Le prompt caching et la récupération peuvent régler certains problèmes de coût ou de contexte, mais ils ne sont pas des substituts équivalents pour apprendre un comportement spécialisé par fine-tuning.
Comment OpenAI se compare sur le prix
Ces tarifs sélectionnés sont en dollars américains par million de tokens, vérifiés le 8 septembre 2026. Les lignes OpenAI utilisent la tarification Standard en contexte court ; DeepSeek utilise la tarification en heures creuses. Le tableau exclut les outils, les écritures en cache, le stockage et les taxes. Un tarif forfaitaire par token ne s'applique qu'à l'intérieur de la fenêtre de contexte prise en charge de chaque modèle, pas à une longueur d'entrée illimitée.
| Modèle | Entrée | Lecture du cache | Sortie | Tarification en contexte long |
|---|---|---|---|---|
| GPT-5.6 Sol | $4.00 | $0.40 | $20.00 | Entrée 2x et sortie 1.5x au-delà de 272K tokens d'entrée |
| GPT-5.6 Terra | $2.00 | $0.20 | $12.00 | Mêmes multiplicateurs |
| GPT-5.6 Luna | $0.20 | $0.02 | $1.20 | Mêmes multiplicateurs |
| Claude Opus 5 | $5.00 | $0.50 | $25.00 | Forfaitaire sur toute la fenêtre prise en charge |
| Claude Sonnet 5 | $2.00 | $0.20 | $10.00 | Forfaitaire sur toute la fenêtre prise en charge |
| Claude Haiku 4.5 | $1.00 | $0.10 | $5.00 | Forfaitaire sur toute la fenêtre prise en charge |
| Gemini 3.7 Flash | $0.75 | $0.075 | $3.75 | Aucune majoration par tranche de contexte indiquée |
| DeepSeek V4 Flash | $0.22 | $0.007 | $0.66 | Aucune majoration par tranche de contexte indiquée |
| Kimi K3 | $3.00 | $0.30 | $15.00 | Aucune majoration par tranche de contexte indiquée |
Sources : OpenAI, Anthropic, Google, DeepSeek et Kimi.
Google affiche pour Gemini 3.7 Flash des tarifs de $0.75/$3.75 jusqu'au 31 décembre 2026, puis $1.50/$7.50 à partir du 1er janvier 2027. Son niveau gratuit Standard inclut entrée et sortie gratuites, avec des limites et des conditions d'utilisation des données distinctes. Le context caching payant comporte aussi des frais de stockage ; le tarif de lecture du cache seul n'en est pas le coût complet.
DeepSeek double les tarifs affichés en heures creuses entre 01:00–04:00 et 06:00–10:00 UTC, du lundi au vendredi. Toutes les autres heures sont creuses. J'utiliserais le calendrier de requêtes attendu, et pas seulement la ligne la moins chère, pour budgéter un service de support actif 24 h sur 24.
Aux tarifs actuels en contexte court, les $4 en entrée et $20 en sortie promotionnels de Sol sont inférieurs aux $5 et $25 d'Opus 5. Sonnet 5 égale le tarif d'entrée de $2 de Terra et facture $10 en sortie contre $12 pour Terra. Ce sont des comparaisons par million de tokens, pas des résultats de coût par tâche : les modèles peuvent tokeniser le même texte différemment et générer des quantités de raisonnement différentes. La documentation tarifaire d'Anthropic distingue aussi la tarification du contexte long :
Claude 4.6 and later models and Claude Mythos Preview include the full 1M token context window at standard pricing. (A 900k-token request is billed at the same per-token rate as a 9k-token request.)
La tranche de contexte peut changer l'option la moins chère. Pour des prompts courts, le tarif de sortie affiché de Gemini 3.7 Flash, $3.75, est supérieur aux $1.20 de Luna, pas inférieur. De même, le tarif d'entrée en heures creuses affiché de DeepSeek, $0.22, est supérieur aux $0.20 de Luna, alors que son tarif de sortie de $0.66 est inférieur. Une affirmation unique selon laquelle un fournisseur est le moins cher masque ces différences. Je comparerais pour chaque charge les quantités d'entrée, de cache et de sortie, puis je tiendrais compte des périodes promotionnelles et de la tarification selon l'heure.
Mon avis : avant de planifier une migration, inspectez les longueurs de contexte réelles, les niveaux de service et l'usage du cache. Testez Batch pour le travail qui peut attendre, et testez des prompts plus courts là où le contexte est redondant. Ne supprimez pas d'information nécessaire à une réponse correcte juste pour passer sous un seuil tarifaire. Comparez ces économies mesurées avec un autre fournisseur sur les mêmes tâches ; ni les économies ni l'effort de migration ne peuvent se déduire d'une grille tarifaire seule.
Ce n'est qu'après cela qu'une comparaison de fournisseurs vaut votre temps, et notre panorama des alternatives à GPT-5.6 compare correctement le paysage. Si ce que vous chiffrez est un siège grand public plutôt que des tokens mesurés, tarifs de ChatGPT est la décomposition équivalente.
Trois exemples chiffrés
Voici trois charges mensuelles hypothétiques aux tarifs actuels. Toutes supposent que 50 % des tokens d'entrée sont facturés comme entrée en cache, sauf indication contraire. Ce sont des estimations de coût en tokens, pas des factures complètes : elles excluent les écritures en cache, les outils, le stockage, les frais de traitement régional et d'autres services. Les nombres de tokens de sortie doivent inclure les tokens de raisonnement facturés.
Un classificateur de tickets à fort volume. Luna, 4,000 tokens d'entrée par ticket, 300 en sortie, 50,000 tickets par mois, avec 60 % des tokens d'entrée facturés en cache. Cela fait $36.40 par mois en Standard ou $18.20 en Batch. Je testerais la précision de la classification avant de choisir le modèle le moins cher ; une facture de tokens basse n'établit pas que ses étiquettes soient utiles.
Un bot de réponses à récupération. Sol, 40,000 tokens d'entrée, 900 en sortie, 30,000 requêtes par mois. L'estimation est de $3,180 en Standard, $1,590 en Batch ou $6,360 en mode Fast. L'écart entre Batch et Fast est de $4,770 à nombres de tokens constants. Ce calcul ne mesure ni la qualité des réponses ni si la latence de Batch convient à une conversation de support en direct.
Le même bot après un changement de récupération. Sol, 300,000 tokens d'entrée, 900 en sortie, 30,000 requêtes en Standard. L'estimation monte à $40,410, soit environ 12.7x l'exemple Standard à 40,000 tokens. Deux choses ont changé : il y a 7.5x plus de tokens d'entrée, et chaque requête utilise désormais les tarifs de contexte long. Il serait trompeur d'attribuer toute l'augmentation au franchissement du seuil.
Le troisième cas est la raison pour laquelle je répète que la ligne du modèle n'est pas l'essentiel. C'est aussi pourquoi, pour une file de support en particulier, je pense que le prix au token est souvent la mauvaise abstraction pour raisonner.
Quand le prix au token n'est plus la bonne question
Tout ce qui précède décrit correctement ce que vous payez à un fournisseur de modèles. C'est une mauvaise description de ce qu'un ticket de support vous coûte.
Un ticket de support peut exiger plusieurs requêtes au modèle, des étapes de récupération et des actions dans le helpdesk. Les arguments d'outils générés par le modèle et les résultats d'outils renvoyés peuvent ajouter des tokens facturés ; exécuter un appel d'API du helpdesk ne crée pas en soi un frais de tokens de modèle supplémentaire. Comptez les requêtes réelles au modèle, les services d'outils facturables et les coûts d'infrastructure. Réévaluez l'estimation quand le workflow change.
Un utilisateur de r/SaaS a signalé une boucle coûteuse tout en sondant la demande pour un outil qui l'empêcherait. C'est un incident autodéclaré, pas une facture auditée de façon indépendante :
"Hey everyone, I just got hit with a $4,200 OpenAI bill because an agent I deployed for customer support got stuck in a recursive loop with my CRM tool call."
Le post décrit une boucle incontrôlée, mais n'établit pas quels contrôles de dépense étaient configurés. Ce risque appelle des nouvelles tentatives bornées, des limites sur les appels d'outils répétés, de la surveillance et des contrôles de dépense délibérés. OpenAI prend en charge des limites strictes appliquées, avec un délai de propagation ; la facturation au token n'implique pas en soi une facture sans plafond.
Les abonnements et l'usage de l'API ont des conditions tarifaires différentes. Dans un commentaire Hacker News, Simon Willison a indiqué payer $200 d'abonnements et a estimé le coût équivalent en API de cet usage :
"the API cost version of my token spend was $2,100"
L'estimation équivalente en API rapportée vaut 10.5x le paiement de l'abonnement, mais ce n'est pas une comparaison contrôlée de produits interchangeables. Les quotas d'abonnement et la facturation directe de l'API obéissent à des conditions différentes. Pour un déploiement via l'API, estimez les requêtes qu'il fera réellement plutôt que de convertir le prix d'un abonnement en budget de tokens.
Une note commerciale de mars 2026 consigne un opérateur de e-commerce multi-sociétés se dirigeant vers 150,000 tickets par mois, qui trouvait déroutante la tarification par interaction et par ticket. L'acheteur projetait environ $30,000 par mois au tarif discuté alors. Cette estimation historique n'est pas le prix actuel d'eesel. Elle illustre pourquoi je définirais l'unité de facturation et la charge attendue avant de comparer des offres.
Un service géré change les parties du workflow que vous exploitez et la façon dont l'usage est facturé. Notre guide des économies de coûts du support client par IA examine cette question de construire ou d'acheter.
Si vous en êtes encore à jauger la catégorie plutôt que la facture, notre guide du système de ticketing IA est un meilleur point de départ.
Inspecter l'usage du support avec la CLI eesel
Le prix de l'API vous dit ce qu'un fournisseur de modèles facture à votre application. Avec eesel, vous exploitez un teammate géré et payez selon les forfaits à crédits d'eesel. La CLI eesel est une autre façon d'accéder au même teammate et au même espace de travail que le tableau de bord, pas un abonnement de modèle distinct ni un moyen d'éviter la consommation de crédits.
C'est utile quand un agent de code aide à enquêter sur une question de coût. Claude Code, Cursor ou Codex peuvent lire la sortie JSON de la CLI et aider à inspecter la facturation, l'activité récente et les automatisations qui déclenchent du travail. Vous lui demandez d'examiner une configuration de support existante, pas de construire une autre application ni de déduire votre facture d'un tarif au token OpenAI.
Pour un espace de travail existant, commencez par les vérifications d'authentification et de destination. Ces commandes nécessitent Node.js 18.17 ou plus récent :
npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents
npx @eesel/cli billing
Sélectionnez ensuite explicitement le teammate visé. Remplacez SUPPORT_AGENT_ID par son identifiant :
npx @eesel/cli status --agent SUPPORT_AGENT_ID
npx @eesel/cli activity --agent SUPPORT_AGENT_ID
npx @eesel/cli automations --agent SUPPORT_AGENT_ID
La facturation est une vue en lecture seule de l'état de facturation actuel. Ne supposez pas que sélectionner un teammate restreint à ce teammate tous les frais au niveau de l'espace de travail. Comparez la portée et les dates dans les enregistrements renvoyés. L'activité peut aider à expliquer ce qui a tourné ; elle ne prouve pas que chaque tâche a réussi, et un total d'activité n'est pas automatiquement le total de la facture.
Une instruction bornée pour l'agent de code pourrait être :
Inspect billing, recent activity, and the selected teammate's automations. Explain which work starts automatically and identify any missing information needed to estimate costs. Do not change overage caps, payment details, integrations, or automations. Propose any changes for review, and do not expose credentials.
La documentation tarifaire actuelle décrit la tarification du support en crédits, où 1 crédit correspond à un ticket ou une session de chat, sur un forfait mensuel fixe à partir de $299 pour 500 crédits, plus $4 par article de blog. Il n'y a ni frais de plateforme ni frais par siège. La documentation de la CLI traite spécifiquement les chats comme du travail facturé ; ne supposez donc pas que l'inspection gratuite de la configuration signifie des répétitions gratuites via la CLI.
| Tickets et chats mensuels | Forfait de crédits | Prix mensuel |
|---|---|---|
| Jusqu'à 500 | 500 crédits | $299 |
| Jusqu'à 1,000 | 1,000 crédits | $499 |
| Jusqu'à 2,500 | 2,500 crédits | $999 |
| Jusqu'à 5,000 | 5,000 crédits | $1,899 |
Pour un mois hypothétique de 1,000 tickets et chats de support, le forfait de 1,000 crédits à $499 le couvre. Cet exemple exclut les options, les dépassements et les articles de blog. Utilisez les conditions réelles de l'espace de travail pour calculer la facture.
Testez la décision de déploiement, pas seulement l'arithmétique
Supposons que l'activité ait augmenté après l'élargissement d'une automatisation à davantage de sujets de support. Inspectez d'abord le déclencheur et les filtres. Une hausse de volume est une raison d'enquêter, pas une preuve de double facturation ni de dysfonctionnement. Demandez si les tâches supplémentaires étaient voulues et si leurs réponses respectaient la politique.
Pour une répétition fictive, désactivez les actions d'écriture et utilisez une politique d'annulation approuvée. Demandez au teammate de rédiger une réponse à un client qui veut résilier un abonnement tout en conservant l'accès au-delà de la date de fin normale. Il doit séparer la politique de l'exception demandée, identifier quand une approbation humaine est nécessaire et éviter d'affirmer que l'abonnement a été modifié.
Utilisez une conversation neuve avec un nouveau --name, limitée à l'agent sélectionné, pour démarrer ce cas. Le chat de suivi poursuit cette conversation. Incluez les chats via la CLI dans votre budget de test, car chacun consomme des crédits. L'option --dry-run prévisualise une requête d'écriture, pas la qualité des réponses ni les dépenses futures.
Si vous approuvez ensuite la modification de l'automatisation en production, vérifiez les deux côtés : les requêtes voulues atteignent le teammate et les requêtes exclues non. Examinez le résultat réel côté client séparément du nombre d'activités. Restreindre le volume peut maîtriser les coûts, mais n'améliore pas à lui seul la réponse.
Essayer eesel
Pour une file de support, comparez le coût du workflow complet plutôt que celui d'un seul appel de modèle. eesel utilise une tarification par crédits, et la CLI vous permet d'inspecter la facturation de l'espace de travail et l'activité du teammate sélectionné sans construire une application de support distincte. Vérifiez le forfait actuel et le volume de crédits avant d'estimer un total mensuel.
Commencez par un ensemble défini de requêtes et inspectez l'automatisation qui les sélectionne. Répétez les réponses de politique avant d'activer les écritures, puis vérifiez la livraison réelle des actions. Un rapport montrant le volume de tâches prouve l'activité, pas la réussite des résolutions ni une prévision exacte de facture.
Si vous avez besoin d'une orchestration de modèles ou d'une infrastructure propres à l'application, comparez une implémentation d'API sur mesure avec le workflow pris en charge d'un teammate géré. Des unités de facturation différentes reflètent des responsabilités différentes ; aucun modèle tarifaire ne garantit le meilleur résultat pour votre tâche.
Confirmez les intégrations prises en charge, la préparation des connaissances et les autorisations d'action pour le workflow que vous prévoyez d'exécuter. Connecter une source ne prouve pas que son contenu a fini de se télécharger ni que chaque action du helpdesk est disponible.
Avant de décider, comparez la même charge avec l'offre d'IA native de votre helpdesk et incluez les coûts de test et d'exploitation des deux côtés.
Essayez eesel si vous voulez configurer un teammate de support et inspecter son fonctionnement via la CLI. Examinez les conditions actuelles et les autorisations proposées, puis n'élargissez qu'après avoir vérifié les résultats.
Questions fréquentes
Combien coûte l'API OpenAI par million de tokens en 2026 ?
Quelle est la façon la moins chère d'utiliser l'API OpenAI ?
Existe-t-il un niveau gratuit pour l'API OpenAI ?
Pourquoi ma facture de l'API OpenAI est-elle plus élevée que ce que la page de prix laissait penser ?
reasoning_effort produit bien plus de tokens de sortie que prévu. Les appels d'outils sont aussi facturés séparément en plus des tokens. Notre guide sur les limites de débit d'OpenAI couvre les plafonds de débit associés.
Comment le prix de l'API OpenAI se compare-t-il à Claude et Gemini ?