Du Python distant sans accès au shell

Un assistant capable de lire un tableau de chiffres n’est pas un assistant capable de calculer dessus à n’importe quelle échelle. L’outil d’exécution de code d’OpenClaw comble cet écart en lançant du Python sur les serveurs de xAI et en rendant le résultat à la conversation. Il est volontairement étroit, sans aucune prise sur votre machine, et il est facturé à chaque appel, donc mieux vaut savoir ce qu’il est et ce qu’il n’est pas avant de l’activer. Ce billet suit ce que la documentation expose.

Ce que fait l’outil

• L’outil lance une analyse Python distante en bac à sable sur l’API Responses de xAI, au même point d’entrée que la recherche X, et il est enregistré par le greffon xAI fourni d’origine, activé par défaut, sous le contrat des outils.
• Ses valeurs par défaut sont Grok 4.6 comme modèle et trente secondes comme délai de requête, sans plafond de tours, si bien que xAI applique sa propre limite interne tant que vous n’en fixez pas une.
• xAI le facture cinq dollars pour mille appels d’outil, en plus des jetons d’entrée et de sortie du modèle, ce qui en fait un outil compté et non un utilitaire local gratuit.
• Les identifiants proviennent d’un profil d’authentification xAI, de la variable de clé xAI dans l’environnement de la passerelle, ou de la clé posée dans la configuration de recherche web du greffon xAI, et chacune des trois alimente aussi la recherche X et la recherche web de Grok.

Il n’a aucun accès à vos fichiers locaux, à votre shell, à votre dépôt ou à vos appareils appairés, et il ne conserve aucun état entre deux appels, donc traitez chaque appel comme une analyse éphémère et non comme une session de carnet.

Quand l’outil apparaît

L’activation est la partie que l’on comprend le plus souvent de travers, parce que l’outil est conditionnel plutôt que simplement actif ou inactif. Si le réglage d’activation est omis, l’exécution de code n’est exposée que lorsque le fournisseur du modèle actif est xAI et que des identifiants xAI se résolvent. Si le modèle actif appartient à un fournisseur connu qui n’est pas xAI, il faut l’activer explicitement, ce que la documentation appelle l’usage entre fournisseurs. Si le fournisseur du modèle actif est absent ou non résolu, l’outil reste masqué au lieu de deviner. Mettre le même réglage à faux le désactive d’un coup pour tous les fournisseurs. Dans tous ces cas, des identifiants xAI restent nécessaires, puisque le travail se fait du côté de xAI. C’est dans le même bloc de configuration que l’on remplace le modèle, le plafond de tours d’outil internes et le délai de requête. Avec le mode de rechargement hybride par défaut, les changements de configuration du greffon s’appliquent seuls, et un redémarrage ne s’impose que si l’environnement du service de passerelle a changé. Pour vérifier le résultat, envoyez /tools dans la conversation concernée et cherchez l’outil dans la liste.

Bien s’en servir

• L’outil ne prend qu’un seul paramètre de tâche, donc la demande complète et les données en ligne doivent tenir dans une seule invite plutôt que s’accumuler sur plusieurs tours.
• Pour des données X fraîches, le schéma documenté consiste à lancer d’abord la recherche X puis à passer son résultat à l’étape d’analyse, et il en va de même pour les résultats de recherche web.
• Sans identifiants, l’outil renvoie une erreur JSON structurée plutôt qu’une exception, ce qui permet à l’agent de lire l’échec et de se corriger au lieu de rester bloqué.

Si ce que vous voulez vraiment, c’est un shell sur votre propre machine ou sur un nœud appairé, c’est L’outil exec qui convient, et pas cet outil. Et comme le Python tourne ici sur l’infrastructure de xAI plutôt que dans votre Le bac à sable de la passerelle, aucun de vos réglages de bac à sable ne s’y applique.

Pourquoi cette conception

La séparation est justement le propos. L’exécution locale d’un shell pose une question de politique sur ce qu’une commande a le droit de toucher, d’où Les approbations exec, tandis que l’analyse distante n’en pose aucune puisqu’elle n’atteint rien qui vous appartienne. Cette contrainte explique aussi l’absence d’état entre deux appels, car il n’y a aucun carnet à protéger et aucune session dont une invite ultérieure pourrait hériter. Le modèle de coût pousse dans le même sens, puisque chaque appel est facturé et qu’une conception qui encourage une demande bien formée vaut mieux qu’une qui encourage le tâtonnement. Cela explique également le paramètre de tâche unique, qui oblige l’appelant à rassembler tout le problème avant de dépenser un appel. Quand l’analyse a besoin de matière fraîche, les données doivent d’abord être récupérées par Les outils de recherche web et X puis collées dans la demande. Il en résulte un outil facile à raisonner précisément parce qu’on lui permet si peu.

Sur Diali

Diali fait tourner OpenClaw hébergé sur Diali pour vous, chaque client dispose de son propre assistant, et la configuration d’exécution est générée depuis le tableau de bord puis remplacée à chaque version. Si vous pesez l’idée d’un outil qui envoie des données chez un tiers pour les analyser, nos notes sur La sécurité Diali sont le bon point de départ.

• Du Python distant chez xAI, sans accès à vos fichiers ni à votre shell.
• Masqué par défaut si le modèle actif n’est pas un modèle xAI.
• Facturé à l’appel : envoyez une requête complète plutôt que des essais.