Tarification de l’API Grok 4.7 sur CometAPI : référence officielle, estimations des coûts et économies

xAI décrit Grok 4.7 comme son modèle de pointe pour le code, les tâches agentiques et le travail cognitif, avec une fenêtre de contexte de 500 K jetons. Selon la page tarifaire actuelle de xAI, les tarifs directs de l’API en dessous de 200 000 jetons d’invite sont de 2,00 $ par million de jetons d’entrée, 0,50 $ par million de jetons mis en cache, et 6,00 $ par million de jetons de sortie. Lorsqu’une invite atteint 200 000 jetons ou plus, xAI affiche respectivement 4,00 $, 1,00 $ et 12,00 $. Ce sont des tarifs directs xAI, pas un prix universel sur les plateformes tierces.

La dépense réelle dépend de plus que le tarif d’entrée affiché. L’entrée nouvelle, l’entrée mise en cache, la sortie, les réessais, les appels d’outils et le nombre d’appels au modèle dans un workflow d’agent peuvent tous modifier la facture. Le seuil des 200 K d’invite est particulièrement important, car xAI comme CometAPI publient des tarifs « long contexte » plus élevés une fois cette limite franchie.

Ce guide établit d’abord la base tarifaire xAI, puis compare la fiche CometAPI de Grok 4.7 actuelle. Au 28 septembre 2026, CometAPI affiche 1,60 $ / 0,40 $ / 4,80 $ par million de jetons d’entrée nouvelle, d’entrée mise en cache et de sortie dans le palier standard, et 3,20 $ / 0,80 $ / 9,60 $ dans le palier long contexte — soit 20 % de moins que les tarifs directs xAI correspondants. Les sections suivantes expliquent comment calculer le coût d’une charge de travail, réduire le gaspillage et accéder au modèle via CometAPI. Tous les prix sont des instantanés datés et doivent être revérifiés avant l’usage en production.

Tarification xAI directe vs CometAPI pour Grok 4.7

Tarifs directs xAI (USD par 1 M de jetons)

Catégorie de jetons	En dessous de 200 K jetons d’invite	Contexte long (≥200 K)
Entrée non mise en cache	2,00 $	4,00 $
Entrée mise en cache	0,50 $	1,00 $
Sortie	6,00 $	12,00 $

Tarifs CometAPI (USD par 1 M de jetons)

Catégorie de jetons	CometAPI : en dessous de 200 K jetons d’invite	CometAPI : palier long contexte
Entrée non mise en cache	1,60 $ / 1 M de jetons	3,20 $ / 1 M de jetons
Entrée mise en cache	0,40 $ / 1 M de jetons	0,80 $ / 1 M de jetons
Sortie	4,80 $ / 1 M de jetons	9,60 $ / 1 M de jetons

La limite des 200 K d’invite compte, car les deux plateformes listent actuellement des tarifs « long contexte » au double de leurs tarifs standard pour Grok 4.7. Il s’agit d’une règle de tarification définie par chaque plateforme API, non d’un changement de capacité du modèle. Une requête devient plus chère lorsqu’une application envoie de grandes invites à répétition ou laisse l’historique d’un agent croître sans contrôle — pas simplement parce que Grok 4.7 prend en charge une fenêtre de contexte de 500 K.

Pour la budgétisation, considérez toute requête susceptible d’atteindre la limite comme « long contexte » jusqu’à ce que le comportement de facturation effectif soit vérifié. La disponibilité des modèles et les prix peuvent changer, donc les calculateurs de production devraient revérifier à la fois la tarification directe de xAI et la page du modèle CometAPI au lieu de coder des valeurs permanentes en dur.

La formule d’estimation du coût de Grok 4.7

Estimez une requête en tarifant séparément chaque catégorie de jetons :

request cost = (fresh input tokens × input rate + cached input tokens × cached rate + output tokens × output rate) ÷ 1,000,000

Puis convertissez l’estimation par requête en estimation de charge de travail :

monthly cost = request cost × requests per user × active users × days in billing period

Utilisez un percentile réaliste plutôt qu’une moyenne unique. Une estimation p50 décrit une requête normale, mais les longueurs p95 d’entrée et de sortie exposent la queue coûteuse qui entraîne souvent la facture. Pour les workflows d’agent, multipliez par le nombre attendu d’appels au modèle par tâche achevée. Un workflow en cinq étapes représente cinq appels facturables, pas un seul.

Exemple détaillé 1 : Un copilote d’assistance

Supposons qu’une demande d’assistance envoie 6 000 jetons d’entrée nouvelle et génère 800 jetons de sortie. Elle reste en dessous du seuil des 200 K et ne bénéficie pas d’une remise de cache.

Entrée : 6,000 × 1,60 $ ÷ 1,000,000 = 0,00960 $
Sortie : 800 × 4,80 $ ÷ 1,000,000 = 0,00384 $
Total : 0,01344 $ par requête

À 100 000 requêtes par mois, le coût estimé en jetons est de 1 344 $. Si l’évaluation montre qu’une réponse de 400 jetons fonctionne aussi bien qu’une réponse de 800 jetons, l’estimation tombe à 0,01152 $ par requête, soit 1 152 $ par mois. Ce seul plafond de sortie économise environ 192 $ par mois, soit 14,3 %, sans changer de modèle.

C’est pourquoi le contrôle de la sortie mérite de l’attention. Au tarif CometAPI indiqué, les jetons de sortie coûtent trois fois plus cher que les jetons d’entrée nouvelle dans le même palier.

Exemple détaillé 2 : Réutiliser un préfixe stable de 20 000 jetons

Supposons que chaque requête contienne un manuel produit de 20 000 jetons, 2 000 jetons de nouveau contexte de conversation, et une réponse de 600 jetons.

Sans hit de cache, l’estimation est :

22 000 jetons d’entrée nouvelle : 0,03520 $
600 jetons de sortie : 0,00288 $
Total : 0,03808 $ par requête

Si le préfixe stable de 20 000 jetons est facturé comme entrée mise en cache tandis que seuls 2 000 jetons restent nouveaux, l’estimation devient :

20 000 jetons d’entrée mise en cache : 0,00800 $
2 000 jetons d’entrée nouvelle : 0,00320 $
600 jetons de sortie : 0,00288 $
Total : 0,01408 $ par requête

À 100 000 requêtes, cela fait 1 408 $ au lieu de 3 808 $ — une économie estimée de 2 400 $, soit 63,0 %. L’économie n’est pas automatique : la première requête, un préfixe modifié ou une route qui ne produit pas de hit de cache peuvent toujours être facturés au tarif d’entrée nouvelle. Confirmez le nombre de jetons mis en cache dans les données d’usage réelles avant de considérer l’estimation comme une économie acquise.

Exemple détaillé 3 : Le coût du franchissement des 200 K

Considérez une requête d’agent de longue durée avec 210 000 jetons d’invite et 2 000 jetons de sortie. En utilisant les tarifs « long contexte » indiqués :

210 000 jetons d’entrée nouvelle : 0,67200 $
2 000 jetons de sortie : 0,01920 $
Total : 0,69120 $ par exécution

Si la compaction du contexte, le filtrage de récupération et des checkpoints de résumé réduisent l’invite à 180 000 jetons tout en conservant la même sortie de 2 000 jetons, l’estimation du palier standard est :

180 000 jetons d’entrée nouvelle : 0,28800 $
2 000 jetons de sortie : 0,00960 $
Total : 0,29760 $ par exécution

La différence est de 0,39360 $ par exécution, soit environ 56,9 %. Sur 10 000 exécutions, l’économie estimée est de 3 936 $. La leçon n’est pas de supprimer un contexte utile. Il s’agit de ne conserver que le contexte qui change la réponse et de résumer ou récupérer le reste avant que la requête ne franchisse une limite de prix.

Un calculateur Python pour des estimations pré-appel

La fonction suivante utilise les tarifs actuellement affichés par CometAPI pour Grok 4.7. Elle applique de manière conservatrice le palier long contexte lorsque l’invite totale atteint 200 000 jetons.

from dataclasses import dataclass

@dataclass(frozen=True)
class Rates:
    input_per_million: float
    cached_input_per_million: float
    output_per_million: float

SHORT = Rates(1.60, 0.40, 4.80)
LONG = Rates(3.20, 0.80, 9.60)

def estimate_grok_47_cost(
    fresh_input_tokens: int,
    cached_input_tokens: int,
    max_output_tokens: int,
) -> float:
    prompt_tokens = fresh_input_tokens + cached_input_tokens
    rates = LONG if prompt_tokens >= 200_000 else SHORT

    return (
        fresh_input_tokens * rates.input_per_million
        + cached_input_tokens * rates.cached_input_per_million
        + max_output_tokens * rates.output_per_million
    ) / 1_000_000

estimate = estimate_grok_47_cost(
    fresh_input_tokens=2_000,
    cached_input_tokens=20_000,
    max_output_tokens=600,
)
print(f"Estimated upper bound: ${estimate:.5f}")

Ceci est un garde-fou de planification, pas une facture. Le coût final dépend des entrées réelles, des entrées mises en cache, de la sortie, des réessais, des appels d’outils et du prix actif au moment de l’exécution. Après chaque réponse, enregistrez l’usage de jetons renvoyé, l’ID du modèle, le statut de la requête et le résultat de la tâche. Rapprochez ces valeurs des relevés de facturation du fournisseur.

Cinq leviers de coût pour Grok 4.7, classés par impact probable

1. Maintenez le contexte répété suffisamment stable pour le cache

Placez des instructions statiques, de la documentation produit, des schémas et des exemples réutilisables avant le contenu spécifique à la requête. Évitez de modifier les horodatages, IDs, espaces ou l’ordre à l’intérieur d’un grand préfixe partagé, sauf si le changement est nécessaire. Les recommandations de Grok 4.7 par xAI préconisent des identifiants de routage de cache stables pour les conversations ; en utilisant une route intermédiaire, vérifiez quels contrôles de cache et champs d’usage sont pris en charge avant de compter dessus.

Mesurez les jetons en hit de cache et le taux de hit de cache par charge de travail. Une remise de cache théorique n’a aucune valeur si l’application modifie constamment le préfixe.

2. Considérez 200 K comme un budget d’ingénierie, pas une cible

Réservez de la marge sous le seuil pour les instructions système, les passages récupérés, les résultats d’outils et le prochain tour utilisateur. Pour un agent, compactez les anciens tours en un résumé validé et conservez la transcription brute en dehors du contexte du modèle. Pour la récupération, classez et dédupliquez les passages avant insertion au lieu d’envoyer chaque correspondance.

Suivez les distributions de longueur d’invite et alertez avant que le p95 n’approche du seuil. Selon le barème officiel de xAI, dès qu’une invite atteint 200 K jetons, les tarifs long contexte s’appliquent à tous les jetons de cette requête. CometAPI liste également un palier long contexte distinct et plus élevé pour Grok 4.7. Ce sont des conditions de tarification de plateforme, pas des capacités du modèle.

3. Plafonnez la sortie et calibrez l’effort de raisonnement sur un jeu d’évaluation

Définissez un plafond de sortie au niveau application qui correspond au produit. Un résultat de classification peut nécessiter des dizaines de jetons ; une réponse d’assistance quelques centaines ; un rapport de recherche davantage. Ce plafond est un contrôle de budget et d’expérience utilisateur, pas une limite dure du modèle Grok 4.7. Les notes de version du 21 septembre de xAI indiquent que Grok 4.7 n’a pas de limite d’output textuel ; cela n’empêche pas une application ou une route API spécifique d’imposer son propre plafond par requête. Confirmez toute limite de requête imposée par l’endpoint ou le SDK avec la route effectivement utilisée.

Grok 4.7 prend en charge plusieurs niveaux d’effort de raisonnement. Utilisez le niveau le plus bas qui passe un jeu d’évaluation représentatif, et réservez un effort plus élevé aux tâches où il produit une amélioration mesurable. Réduire le raisonnement ou la sortie sans contrôle qualité peut créer des réessais et annuler l’économie.

4. Rejetez ou remodelez les requêtes coûteuses avant l’appel API

Estimez une borne supérieure à partir de la taille d’entrée et du plafond de sortie configuré. Si la requête dépasse le budget produit, l’application peut demander à l’utilisateur de restreindre la tâche, résumer le matériel téléversé, réduire le contexte récupéré, ou déplacer le job vers un workflow asynchrone approuvé. C’est plus prévisible que de découvrir le coût après génération.

Une approximation grossière caractères/jetons peut servir de garde précoce, mais elle ne doit pas remplacer un tokenizer ni des données d’usage réelles. Les langues, le code, le JSON et le formatage peuvent produire des densités de jetons très différentes.

5. Optimisez le coût par tâche réussie, pas le coût par appel

Un appel moins cher qui échoue deux fois à la validation peut coûter plus qu’un appel réussi. Suivez :

le coût par réponse acceptée ;
le coût par tâche d’agent complétée ;
le coût des réessais et de repli ;
le taux de hit de cache et la part de jetons mis en cache ;
les jetons d’invite et de sortie p50 et p95 ;
le score de qualité, la latence et le taux d’escalade humaine.

Si le trafic routinier n’exige pas la qualité ou la capacité de contexte de Grok 4.7, le catalogue unifié de modèles de CometAPI peut faciliter un basculement de modèle géré par l’application. Gardez la règle de routage explicite, évaluez chaque modèle sur le même jeu de tâches, et n’envoyez à cette route que les requêtes qui bénéficient de Grok 4.7.

Un examen pratique du coût mensuel

Une fois par semaine, regroupez le trafic par fonctionnalité et comparez le coût estimé à l’usage réel. Commencez par les fonctionnalités responsables du plus grand nombre de jetons de sortie, des invites les plus volumineuses et du plus faible taux de hit de cache. Puis examinez les valeurs aberrantes coûteuses plutôt que d’optimiser à l’aveugle la requête médiane.

Signal	Problème probable	Première action
Faible part de jetons mis en cache	Le préfixe partagé change trop souvent	Stabilisez et versionnez le contexte réutilisable
Les invites se concentrent près de 200 K	Historique ou récupération non bornés	Compactez, classez et réservez de la marge
La sortie domine la dépense	Les réponses sont plus longues que nécessaire	Abaissez le plafond et testez la qualité des réponses
Coût de réessai élevé	Validation, timeouts ou invites instables	Corrigez le mode d’échec au premier appel
Coût faible mais faible taux d’achèvement des tâches	L’optimisation a réduit une qualité utile	Mesurez le coût par résultat accepté

La place de CometAPI dans le modèle de coût de Grok 4.7

Le rôle de CometAPI dans ce workflow est au niveau de la plateforme API : elle fournit l’accès à Grok 4.7, publie ses propres tarifs en jetons et documente un point d’entrée compatible OpenAI. Elle ne modifie pas les capacités sous-jacentes du modèle Grok 4.7. Les équipes utilisant déjà un client de style OpenAI peuvent souvent conserver le même schéma de client tout en changeant la clé API, l’URL de base et l’ID du modèle, sous réserve de la compatibilité de l’endpoint.

Au 28 septembre 2026, les tarifs listés par CometAPI pour Grok 4.7 sont 20 % inférieurs aux tarifs directs xAI correspondants, tant dans le palier standard que dans le palier long contexte. Il s’agit d’une comparaison de prix de plateforme, pas d’une affirmation sur la qualité du modèle. Avant un déploiement en production, les équipes devraient aussi vérifier l’ID de modèle actif, les paramètres d’endpoint, le comportement du cache, les limites de débit, la fiabilité, le support et les conditions de facturation.

Pour tester le modèle, consultez les tarifs et modalités d’accès actuels sur la page du modèle Grok 4.7 chez CometAPI. Conservez le tableau des prix en configuration, enregistrez l’usage réel après chaque appel, et relancez les estimations de charge de travail à chaque changement du modèle ou du comportement produit.

FAQ

Quel est le prix par jeton de Grok 4.7 sur CometAPI ?

Pour des invites en dessous de 200 K jetons, CometAPI liste actuellement 1,60 $ par million de jetons d’entrée nouvelle, 0,40 $ par million de jetons d’entrée mise en cache, et 4,80 $ par million de jetons de sortie. Les tarifs « long contexte » affichés sont respectivement 3,20 $, 0,80 $ et 9,60 $ par million de jetons.

Combien coûte une requête API Grok 4.7 ?

Cela dépend de l’entrée nouvelle, de l’entrée mise en cache, de la sortie et du palier de contexte actif. Multipliez chaque compte de jetons par son tarif au million, additionnez les résultats et divisez par un million. Incluez aussi les réessais et chaque appel au modèle dans un workflow multi-étapes.

Quelle est la manière la plus simple de réduire le coût de l’API Grok 4.7 ?

Commencez par le plus grand moteur de coût mesuré. De longues instructions répétées bénéficient généralement du cache ; des historiques d’agent en croissance bénéficient de la compaction ; des réponses verbeuses bénéficient d’un plafond de sortie plus bas. Confirmez que la qualité reste acceptable après chaque changement.

Une fenêtre de contexte de 500 K signifie-t-elle que je dois envoyer 500 K jetons ?

Non. La fenêtre de contexte est une limite de capacité, pas une recommandation. La tarification directe xAI comme la grille actuelle de CometAPI utilisent des tarifs long contexte plus élevés au seuil de 200 K jetons d’invite ; les applications ne devraient envoyer que le contexte nécessaire à la tâche.

Puis-je estimer le coût avant d’appeler Grok 4.7 ?

Oui. Estimez les jetons d’entrée, choisissez le palier de contexte adéquat, ajoutez un plafond de sortie réaliste et calculez la borne supérieure. Après l’appel, remplacez l’estimation par les données d’usage réelles pour le reporting et l’optimisation.