Aller au contenu principal

Grok 4.6 est le modèle de chat multimodal de xAI derrière un appel compatible OpenAI, avec texte et image dans un même tour. Une requête tient jusqu’à 500 000 tokens et une réponse peut atteindre 450 000, avec quatre niveaux d’effort de raisonnement.

Entrée $2Sortie $6par 1 million de tokensEntrée en cache $0.50Prompts de 200K tokens ou plusEntrée $4Sortie $12

Atelier

Grok 4.6

En quoi Grok 4.6 peut-il vous aider ?

Modèles liés et tâches suivantes

Le modèle que vous cherchez n’est pas là ?

Dites-nous lequel ajouter et à quoi il vous servira. Les demandes vont directement à l’équipe qui décide des prochains modèles.

Des flux de messages stables pour le code, les tâches agentiques et le travail de connaissance

Grok 4.6 est le modèle de pointe de xAI dans ce catalogue : 500 000 tokens de contexte, jusqu’à 450 000 tokens dans une seule réponse et un effort de raisonnement de low à xhigh, high par défaut. Il lit du texte et des images ; cette route n’accepte aucune pièce fichier ni PDF.

Ouvrir le Playground de chat
Des flux de messages stables pour le code, les tâches agentiques et le travail de connaissance
Modèle
Grok 4.6
Utile pour
le code, les tâches agentiques et le travail de connaissance
Structure des messages
Règles système → preuves et état → tâche du tour → contrat de sortie
Portée des faits
Capacités, réglages et prix proviennent du schéma en temps réel

Principe d’intégration

Validez d’abord avec le plus petit jeu de messages, puis ajoutez le contexte nécessaire. Séparez faits, hypothèses et contraintes, et prévoyez les chemins d’interruption, de reprise, de facturation et de relecture humaine.

Construire des workflows reproductibles pour le code, les tâches agentiques et le travail de connaissance

Grok 4.6 est le modèle de pointe de xAI dans ce catalogue : 500 000 tokens de contexte, jusqu’à 450 000 tokens dans une seule réponse et un effort de raisonnement de low à xhigh, high par défaut. Il lit du texte et des images ; cette route n’accepte aucune pièce fichier ni PDF.

  • Budget de fenêtre

    500 000 en entrée, 450 000 en sortie

    Presque toute la fenêtre peut revenir en une seule réponse : ce modèle sert les travaux dont le résultat est long, pas seulement ceux qui lisent de longues entrées.

  • Effort de raisonnement

    Quatre niveaux, high par défaut

    low, medium, high et xhigh sont exposés. Les tokens de raisonnement comptent comme sortie : relevez max_tokens chaque fois que vous relevez l’effort.

  • Parties d’entrée

    Texte et images, jamais de fichiers

    Un message peut mêler des parties texte et des parties image_url avec detail auto, low ou high. Les parties fichier et PDF sont refusées sur cette route ; convertissez d’abord vos documents en texte ou en images de pages.

Choisir Grok 4.6 selon le coût de la tâche et la forme de l’échange

Testez une vraie tâche pour la qualité, la vérifiabilité, la latence et l’adéquation au tarif, plutôt que de vous fier à un classement généraliste.

  1. Choisir 4.6

    La réponse elle-même est longue et difficile

    Refontes de grande ampleur, exécutions d’agents qui écrivent beaucoup de code, travail de connaissance qui doit tenir tout un dossier de preuves en un tour.

  2. Envisager 4.5

    Un long prompt tourne toute la journée

    Les boucles qui renvoient le même bloc de tête paient l’entrée mise en cache moins cher sur le modèle voisin ; comparez les deux fiches de prix avant de trancher.

  3. Envisager 4.3

    Le débit prime sur la profondeur

    Classification, extraction et routage reviennent au modèle voisin, dont la fenêtre est plus large et dont le raisonnement peut être coupé.

Transformer Grok 4.6 en travail concret, pas en étiquettes vagues

Chaque scénario demande des limites d’entrée, une vérification et une reprise ; les capacités officielles, les benchmarks et le support d’outils ne sont jamais inventés.

  • Des changements à l’échelle du dépôt en un tour

    Code

    Des changements à l’échelle du dépôt en un tour

    Fournissez interfaces, invariants et tests, puis demandez le plan, le diff et les risques de migration que le changement crée.

  • Appels d’outils avec un plan large

    Agents

    Appels d’outils avec un plan large

    Jusqu’à 128 définitions de fonctions et tool_choice sont exposées ; gardez les étapes irréversibles derrière une porte d’approbation tenue par votre produit.

  • De longs dossiers de preuves qui finissent en décision

    Travail de connaissance

    De longs dossiers de preuves qui finissent en décision

    Nommez chaque source, exigez le chemin de la source à la conclusion et demandez quelle hypothèse renverserait la recommandation.

  • L’image comme preuve, pas comme décor

    Écrans et schémas

    L’image comme preuve, pas comme décor

    Envoyez captures et schémas d’architecture avec detail: high quand les petits caractères comptent, et dites précisément ce qu’il faut y lire.

Organiser le contexte en une entrée Grok 4.6 inspectable

Objectif, preuves, état, contraintes et contrat de sortie doivent tenir des rôles distincts pour qu’une requête soit compressible, débogable et reproductible.

  1. Système

    Les règles durables dans un bloc fixe

    Persona, contrat de sortie et conventions ne doivent pas bouger d’une exécution à l’autre ; une tête stable est aussi ce qui rend la mise en cache possible.

  2. Preuves

    Délimiter et nommer chaque source

    Les parties texte comme les parties image ont besoin d’un nom, pour qu’une conclusion puisse désigner ce dont elle provient.

  3. Effort

    Ajuster le niveau à la tâche

    Relevez-le quand les contraintes s’entrecroisent ; laissez-le bas pour la rédaction et la réécriture, où c’est la latence qui se remarque.

  4. Sortie

    Annoncer la forme que vous analyserez

    response_format peut exiger un objet JSON. Nommez les champs obligatoires et dites à quoi ressemble un résultat vide.

Prouver un cas Grok 4.6 reproductible avant d’intégrer au produit

Confirmez le schéma en temps réel, l’estimation, le streaming et le comportement d’erreur avant de réutiliser la requête normalisée.

  1. 01 · Référence

    Valider la plus petite requête dans le Playground

    Vérifiez les couches de messages, la forme de sortie, le streaming et les réglages actuels.

  2. 02 · Limites

    Éprouver l’échec, l’annulation et la reprise

    Contrôlez délais dépassés, flux interrompus, entrée trop longue, régénération et double envoi.

  3. 03 · Intégrer

    Copier la requête API normalisée

    Utilisez l’identifiant public du modèle et le contrat messages ; lisez les réglages sur le schéma en temps réel.

  4. 04 · Exploiter

    Mesurer l’usage et continuer d’évaluer

    Conservez état, consommation finale, causes d’échec et retours qualité ; estimez d’abord les appels coûteux.

Faire entrer Grok 4.6 dans un contrat d’API clair

Playground, exemples d’API, états de requête et relevés d’usage restent alignés, de l’évaluation à l’intégration en production.

  • Contrat unifié

    Une seule forme pour messages, flux et erreurs

    La structure des requêtes, la gestion d’état et la reprise sur erreur restent identiques quand le modèle change.

  • Schéma en temps réel

    Utiliser les réglages du point de terminaison courant

    Playground et exemples d’API exposent ensemble les champs disponibles, les limites et les comportements par défaut.

  • Cycle de vie observable

    Chaque requête a un état clair

    Soumission, streaming, échec, annulation et usage suivent une sémantique publique inspectable.

  • Intégration portable

    Moins de reprises quand les modèles évoluent

    Un contrat clair garde le code produit concentré sur les entrées, les résultats et l’expérience.

Les limites de l’API Grok 4.6 à confirmer avant d’intégrer