Limitations, statut beta et gestion de la consommation — Multi-Agent Research

Ce que vous devez savoir avant de déployer

Le multi-agent de Grok tient ses promesses sur la qualité de recherche, mais il reste en beta, avec des angles morts qu’il vaut mieux connaître avant qu’ils ne se manifestent en production. Cette dernière leçon rassemble les limitations actuelles et la discipline qui permet de vivre avec, à commencer par le point le plus sensible : la consommation de tokens.

Les contraintes techniques du modèle

Celle qui surprend le plus concerne max_tokens : le paramètre n’est pas supporté par le modèle multi-agent. Vous n’avez donc aucun moyen technique de plafonner la longueur de la réponse du leader, ce qui donne des réponses volontiers longues — surtout avec seize agents — et un budget de tokens qui se pilote au niveau du prompt plutôt qu’à celui de l’API. Le seul levier restant est rédactionnel : une consigne du type « réponds en 500 mots maximum » ou « fais un résumé en 5 points » remplace le paramètre absent, sans la rigueur d’une limite technique mais respectée dans la grande majorité des cas.

Vient ensuite une contrainte traitée en détail plus tôt : seuls les outils intégrés fonctionnent, et aucune fonction personnalisée ne peut être déclarée via l’API.

Votre infrastructure, elle, est concernée par une troisième restriction. Le multi-agent est accessible avec le xAI SDK, en méthode native, et avec la Responses API via le SDK OpenAI ; l’API Chat Completions, /chat/completions, n’est pas compatible. Si tout votre code passe par elle, planifiez la migration avant d’annoncer la fonctionnalité à qui que ce soit.

Reste l’observabilité, qui pose un problème d’un autre ordre : vous n’avez accès qu’à la réponse du leader et aux appels d’outils. Le raisonnement des sub-agents demeure chiffré, ce qui limite ce que vous pourrez auditer ou expliquer à un utilisateur qui conteste une conclusion.

Ce qu’implique le statut beta

Une API en beta est une API dont le contrat n’est pas figé. L’interface peut changer sans préavis — paramètres, format de réponse, comportement ; les performances varient d’une période à l’autre, tant sur les temps de réponse que sur la qualité des recherches ; le modèle peut être mis à jour, grok-4.20-multi-agent-0309 cédant la place à une version ultérieure ; et la liste des outils supportés évoluera dans les deux sens.

D’où une règle d’écriture : ne codez pas en dur d’hypothèses sur le comportement exact du modèle. Isolez l’appel derrière une fonction unique, prévoyez un chemin de repli, retestez régulièrement plutôt qu’au moment où un utilisateur signale la panne.

Tenir la consommation sur la durée

Tout commence dans le code. Un wrapper unique concentre le choix du nombre d’agents et le comportement en cas d’échec, ce qui vous laisse un seul endroit à modifier le jour où l’API change.

# Pattern recommande : wrapper avec fallback
async def research(query: str, depth: str = "quick"):
    try:
        agent_count = 16 if depth == "deep" else 4
        chat = client.chat.create(
            model="grok-4.20-multi-agent-0309",
            agent_count=agent_count,
        )
        chat.append(user(query))
        result = ""
        for response, chunk in chat.stream():
            if chunk.content:
                result += chunk.content
        return result
    except Exception:
        # Fallback vers un modèle standard
        return await standard_query(query)

Autour de ce wrapper, posez des quotas de requêtes multi-agent par utilisateur et par période, faute de quoi rien n’empêche un compte, par curiosité ou par script mal réglé, de lancer des centaines de requêtes à seize agents en une soirée.

Rendez ensuite la dépense lisible. Tracez la consommation de tokens requête par requête et cherchez les motifs de surconsommation : prompts trop vagues qui font s’éparpiller les agents, conversations qui tournent en boucle, comportements abusifs. Ce sont presque toujours quelques cas isolés qui pèsent l’essentiel de la facture.

La mesure la plus rentable, enfin, consiste à n’envoyer au multi-agent que ce qui le mérite. Un routeur en amont suffit : question factuelle simple vers un modèle standard, recherche comparative vers quatre agents, analyse exhaustive vers seize. Ce tri divise souvent la facture sans aucune dégradation perceptible.

Avant de basculer en production

Passez cette liste en revue, honnêtement, avant l’ouverture aux utilisateurs.

Un fallback vers un modèle standard est-il en place et testé ?
Des limites de tokens par utilisateur sont-elles définies ?
Le monitoring de la consommation est-il opérationnel ?
Vos prompts sont-ils assez précis pour éviter le gaspillage ?
Le comportement en cas d’erreur a-t-il été vérifié ?
Êtes-vous organisé pour absorber un changement d’API en beta ?

Une réponse négative n’interdit pas le déploiement, mais elle vous dit exactement où vous serez surpris.

Points clés à retenir

max_tokens n’est pas supporté — contrôlez la longueur via le prompt
L’API est en beta et peut changer — prévoyez des fallbacks
La consommation de tokens est significative — mettez en place du monitoring
Implémentez un routeur pour choisir entre multi-agent et modèle standard
Définissez des quotas par utilisateur pour contrôler les coûts
Testez régulièrement votre intégration pour détecter les changements d’API

Testez vos connaissances

Le multi-agent de xAI : leader, sub-agents et réalités de facturation.

1. Comment fonctionne grok-4.20-multi-agent-0309 ?

Réponse : Un leader décompose la requête et coordonne des sub-agents qui travaillent en parallèle, puis synthétise — une équipe d’agents derrière un seul appel API.

2. 4 ou 16 agents : comment choisir ?

Réponse : Selon la profondeur de recherche voulue : 4 pour les questions cadrées, 16 pour les investigations larges — l’effort supplémentaire se paie en tokens et en latence.

3. Quelle limitation majeure faut-il connaître ?

Réponse : Pas de function calling custom : le multi-agent travaille avec les outils intégrés (web_search, x_search…) — vos fonctions personnalisées ne sont pas invocables dans ce mode.

4. Comment se calcule la facturation ?

Réponse : Tous les agents comptent : le travail parallèle des sub-agents s’additionne — une requête multi-agent consomme bien plus qu’un appel simple, à budgéter en conséquence.

5. Comment enchaîner des tours multi-agents ?

Réponse : Avec previous_response_id : la conversation se poursuit sur l’état serveur — et le streaming verbose (contenu chiffré compris) donne la visibilité sur le travail des agents.

Une équipe d’agents en un appel : puissant, facturé en conséquence, encore en bêta — l’utiliser en connaissance de cause est tout l’objet du cours.