Grok 4.7 vs 4.6 : ce qui change, benchmarks, faut-il migrer ?
grok-4.6 et grok-4.7.Ce guide couvre ce qui change, les chiffres de benchmarks de xAI et d’Artificial Analysis côte à côte, ce que la différence de tokens fait à une facture dont le prix unitaire est le même, et comment tester la mise à niveau sur votre propre charge de travail avant de déplacer du trafic.
Ce qui change dans Grok 4.7
xAI décrit trois changements. D’abord, un modèle de base plus grand : Grok 4.7 est entraîné à partir d’une base plus grande que la 4.6. Ensuite, un entraînement par renforcement plus long sur un mélange de tâches plus difficiles, avec un poids accru pour les problèmes qui demandent de nombreuses heures. Enfin, le résultat comportemental que xAI met en avant : le modèle est « meilleur pour vérifier son propre travail et gérer un contexte plus long ».
Ce qui ne change pas : le contexte de 500 000 tokens, l’entrée texte et image, le function calling et les sorties structurées, les quatre niveaux d’effort de raisonnement, les limites de débit et le prix.
Benchmarks Grok 4.7 vs 4.6 : rapportés par xAI et mesurés par un tiers
xhigh et Grok 4.6 à high.| Benchmark | Grok 4.6 (xAI) | Grok 4.7 (xAI) | Grok 4.6 (AA) | Grok 4.7 (AA) |
|---|---|---|---|---|
| Terminal-Bench 4.0 | 20,3 % | 38,0 % | — | +4,5 pts par rapport à la 4.6 |
| Artificial Analysis Intelligence Index v4.3.2 | — | — | 44 | 46 |
| CursorBench 4.0 | 40,4 % | 46,3 % | — | — |
| DeepSWE v1.1 | 65,2 % | 71,0 % | — | — |
| EEBench | 53,0 % | 64,0 % | — | — |
| AA-Briefcase v1.1 (Elo) | 1 546 | 1 657 | 1 546 | 1 657 |
| GDPval (Elo) | 1 605 | 1 695 | 1 605 | 1 695 |
| Agent juridique Harvey | 15,8 % | 19,6 % | — | — |
| HealthBench Professional | 48,5 % | 56,7 % | — | — |
| Tokens de sortie par tâche de l’index | — | — | ≈36k | ≈81k |
xhigh, Grok 4.7 écrit environ 81 000 tokens de sortie par tâche là où Grok 4.6 à high en écrivait 36 000.Spécifications côte à côte
| Dimension | Grok 4.6 | Grok 4.7 |
|---|---|---|
| ID de modèle pour l’API | grok-4.6 | grok-4.7 |
| Sortie | 12 août 2026 | 21 septembre 2026 |
| Fenêtre de contexte | 500 000 tokens | 500 000 tokens |
| Modalités | Texte et image en entrée ; texte en sortie | Texte et image en entrée ; texte en sortie |
| Effort de raisonnement | low, medium, high (par défaut), xhigh | low, medium, high (par défaut), xhigh |
| Function calling et sorties structurées | Oui | Oui |
| Tarif standard par million de tokens (xAI en direct) | 2 $ en entrée, 0,50 $ en entrée mise en cache, 6 $ en sortie | 2 $ en entrée, 0,50 $ en entrée mise en cache, 6 $ en sortie |
| Palier long contexte | Prompt ≥ 200 000 tokens : chaque token facturé 2× | Même règle, même seuil |
| Variante Fast | — | Grok 4.7 Fast : 2× la vitesse, 2× le prix (4 $ / 1 $ / 12 $) ; uniquement dans Cursor et Grok Build, pas sur l’API publique |
| Limites de débit publiées | 150 requêtes/s, 50M tokens/min | 150 requêtes/s, 50M tokens/min |
| Route EvoLink | En service | En service depuis le 22 septembre 2026 (modèle standard) |
Même prix par token, pas la même facture
Les deux modèles facturent 2 $ par million de tokens en entrée et 6 $ par million de tokens en sortie aux tarifs directs de xAI. Le prix unitaire est fixé. Ce qui change, c’est le nombre d’unités que le nouveau modèle dépense pour terminer une tâche.
xhigh contre 36 000 pour la 4.6 à high. À 6 $ par million de tokens de sortie, cela fait environ 0,49 $ contre 0,22 $ de sortie par tâche, avant tout frais d’entrée, de cache ou d’outils. Le réglage d’effort plus élevé fait partie de cette différence, et c’est pourquoi la première chose à faire est d’exécuter les deux modèles au même effort sur vos propres tâches.cost per accepted task = total billed cost of all attempts / accepted tasksComptez les échecs et les reprises au numérateur. Si aucune tâche n’est acceptée, signalez ce résultat ; n’affichez pas un coût nul. Séparez le coût de la relecture humaine des frais d’API.
Trois règles de facturation s’appliquent de la même façon aux deux modèles et méritent d’être vérifiées sur de vraies traces :
- Le seuil des 200 000 tokens. Lorsqu’un prompt atteint 200 000 tokens, xAI facture chaque token de cette requête au tarif long contexte. Une conversation qui dépasse le seuil en cours de session double son coût à partir de ce point.
- L’entrée mise en cache. Des prompts système et des schémas d’outils stables peuvent être servis au tarif cache. Vérifiez le champ des tokens en cache dans l’usage pour confirmer que le cache est atteint avec votre schéma de requêtes.
- Les frais d’outils. Depuis le 21 septembre 2026, xAI facture X Search par post récupéré (5 $ pour 1 000) et par profil utilisateur récupéré (10 $ pour 1 000) plutôt que par appel, pour Grok 4.5, 4.6 et 4.7 indifféremment. Les autres outils serveur restent facturés par appel.
Comment mener un test de mise à niveau équitable
Partez d’un problème que la 4.6 a réellement. Si la 4.6 respecte vos règles d’acceptation et votre échéance, il n’y a aucune pénalité de coût à rester. Réservez le test aux charges qui présentent un échec nommé : un assistant de code qui explique un correctif au lieu de l’appliquer, une tâche d’extraction qui renvoie un JSON valide avec des champs manquants, un agent qui termine mais fait exploser le budget de latence avec des appels d’outils répétés.
| Votre situation | Que faire | Ce qui justifierait de migrer |
|---|---|---|
| Résultats corrects, coût et latence acceptables | Enregistrer un petit jeu de régression ; tester la 4.7 sans urgence | Un gain net sans perte du comportement requis |
| Tâches de dépôt inachevées | Rassembler des échecs représentatifs et des tests indépendants | Davantage de correctifs acceptés pour le même budget |
| Boucles d’outils ou reprises coûteuses | Conserver les traces et des cas d’erreur contrôlés | Meilleure reprise et coût plus bas par tâche acceptée |
| Tâches à long contexte qui perdent les contraintes initiales | Construire des cas à vos tailles de contexte réelles, y compris près de 200K | Contraintes conservées à consommation de tokens égale ou inférieure |
| Échéance de livraison stricte | Garder la configuration 4.6 validée | Validation terminée avant l’échéance |
high, la valeur par défaut, et notez les tokens de raisonnement et de sortie consommés par chacun. Une seconde passe peut régler chaque modèle séparément ; présentez les deux passes à part.Pour une tâche de dépôt, une exécution acceptée doit produire un correctif fonctionnel, réussir les tests pertinents et rester dans le périmètre autorisé. Une explication plausible sans correctif est un échec. Si l’agent affirme avoir lancé les tests, conservez la sortie de l’outil pour qu’un relecteur puisse vérifier cette affirmation. C’est ainsi que l’affirmation « vérifie son propre travail » devient observable.
Notez le travail terminé, pas la réponse :
| Indicateur | Comment le mesurer | Erreur qu’il évite |
|---|---|---|
| Taux de tâches acceptées | Tâches conformes à la grille figée, divisées par les tâches tentées | Compter des réponses plausibles comme du travail terminé |
| Respect du périmètre | Contrôler les modifications, les actions et les contraintes autorisées | Récompenser un contournement efficace mais inacceptable |
| Temps d’achèvement | Du début de la tâche au livrable accepté, reprises comprises | Présenter la vitesse du premier token comme la latence de bout en bout |
| Tokens de raisonnement et de sortie par tâche | Champs d’usage de chaque tentative, par réglage d’effort | Supposer que des tarifs égaux impliquent une dépense égale |
| Coût facturé par acceptation | Frais de toutes les tentatives divisés par les tâches acceptées | Masquer les dépenses liées aux requêtes échouées et aux reprises |
| Charge de relecture | Corrections et temps de relecture, notés séparément | Transférer invisiblement le travail du modèle vers un humain |
Gardez les décomptes bruts à côté des pourcentages, et relancez les cas difficiles pour faire apparaître la variabilité. Ne laissez pas un benchmark de code remplacer votre répartition de tâches : gardez les cas de traduction, d’extraction et de captures d’écran dans le jeu de régression.
Contrôles de compatibilité et déploiement
Même fournisseur, même protocole, mêmes valeurs d’effort : sur le papier, un changement d’une ligne. En pratique, les changements de version se manifestent dans la forme des sorties, le comportement des outils et les cas limites.
| Surface | Ce qu’il faut conserver | Ce qu’il faut retester |
|---|---|---|
| ID de modèle | Configuration explicite et valeur de retour arrière | Envoyer grok-4.7 ; confirmer l’ID de modèle dans la réponse |
| Sortie structurée | Votre schéma et votre validateur | Champs manquants, valeurs invalides et troncature |
| Outils | Définitions des outils et limites d’autorisation | Arguments, appels répétés et reprise après erreur |
| Streaming | Gestion des sorties partielles | Forme des événements, réponses interrompues et état terminal |
| État de la conversation | Messages d’origine et données de test | Limites de contexte, compaction et contraintes retenues |
| Usage et facturation | Journaux reliant une tâche à ses tentatives | Comptabilisation du cache, du raisonnement, de la sortie et des outils par modèle |
Ne changez pas en même temps le modèle, le prompt, l’adaptateur d’outils et la politique de reprise. Commencez par une relecture hors ligne, puis faites tourner en trafic fantôme du travail en lecture seule pendant que la 4.6 reste responsable de ce que voient les utilisateurs, puis déplacez une charge limitée. Définissez une condition d’arrêt en termes opérationnels : une défaillance critique de schéma, un comportement d’outil non autorisé, une baisse des résultats acceptés, ou un coût et une latence hors budget. Lors du retour arrière, vérifiez quels effets de bord ont déjà abouti avant de réessayer sur la 4.6.
La promotion n’a pas à être du tout ou rien. Un candidat pourrait gagner les tâches de dépôt difficiles pendant que la 4.6 garde le travail d’extraction prévisible. Comme les tarifs sont identiques, une répartition ne coûte rien de plus en prix unitaire ; elle ne coûte que de la supervision et de la configuration.
La décision pratique sur EvoLink
FAQ
Grok 4.7 est-il meilleur que Grok 4.6 ?
Sur les chiffres de xAI, clairement : Terminal-Bench 4.0 double presque et chaque benchmark listé progresse. Sur le run indépendant d’Artificial Analysis, le gain est plus petit, deux points d’index et 4,5 points sur Terminal-Bench, pour plus de deux fois les tokens de sortie par tâche. Savoir s’il est meilleur pour vous, c’est ce que mesure le test à conditions identiques.
Quelle est la différence de benchmark entre Grok 4.7 et 4.6 ?
xAI rapporte Terminal-Bench 4.0 à 38,0 % contre 20,3 %, CursorBench à 46,3 % contre 40,4 % et GDPval à 1 695 contre 1 605 Elo. Artificial Analysis mesure l’Intelligence Index à 46 contre 44. Voir le tableau ci-dessus pour l’ensemble complet avec les sources.
Grok 4.7 coûte-t-il plus cher que Grok 4.6 ?
xhigh a consommé environ 81 000 tokens de sortie dans le test d’Artificial Analysis contre 36 000 pour la 4.6 à high, si bien que le même travail peut coûter plus cher.Dois-je migrer de Grok 4.6 vers 4.7 ?
Migrez les charges pour lesquelles la 4.6 présente un échec nommé et où la 4.7 réussit le test à conditions identiques à un coût par tâche acceptée acceptable. Gardez la 4.6 comme cible de retour arrière. Une sortie n’est pas un avis de retrait.
Puis-je réutiliser le même prompt et le même réglage d’effort ?
low, medium, high et xhigh. Réglez chacun séparément ensuite et présentez les passes à part.Les appels d’outils et les sorties structurées demandent-ils un nouveau test ?
Oui. Retestez les schémas, les arguments, la reprise et la validation des sorties, et revérifiez les coûts d’outils : X Search est désormais facturé par post et par profil utilisateur récupérés.
Qu’est-ce que Grok 4.7 Fast ?
Le même modèle sur une infrastructure plus rapide, avec deux fois la vitesse de sortie pour deux fois le prix par token. xAI ne le propose que dans Cursor et Grok Build, pas sur l’API publique ; la route EvoLink de Grok 4.7 sert le modèle standard.
Quand faut-il revenir en arrière ?
Lorsqu’un comportement critique échoue ou que vos limites prédéfinies de qualité, de coût ou de latence sont dépassées. Inspectez les effets de bord déjà produits avant de réessayer une tâche sur l’autre modèle.
