Remote Python without a shell

An assistant that can read a table of figures is not the same as an assistant that can compute over it at any scale. The OpenClaw code execution tool closes that gap by running Python on xAI's servers and handing the result back to the conversation. It is deliberately narrow, with no reach into your machine, and it is billed on every call, so it pays to understand what it is and is not before switching it on. This post follows what the documentation sets out.

What the tool is

• The tool runs sandboxed remote Python analysis on the xAI Responses API, at the same endpoint the X search tool uses, and it is registered by the bundled xAI plugin, which ships enabled by default, under the tools contract.
• Its defaults are Grok 4.6 as the model and thirty seconds as the request timeout, with no turn cap set, so xAI applies its own internal limit unless you supply one.
• xAI bills it at five dollars per one thousand tool calls on top of the model's input and output tokens, which makes it a metered tool rather than a free local helper.
• Credentials come from an xAI auth profile, the xAI API key variable in the Gateway environment, or the key placed in the xAI plugin's web search configuration, and any of the three also powers X search and Grok web search.

It has no access to local files, your shell, your repo, or paired devices, and it does not persist state between calls, so treat each call as ephemeral analysis, not a notebook session.

When the tool appears

Enablement is the part most people get wrong, because the tool is conditional rather than simply on or off. With the enabled setting omitted, code execution is exposed only when the active model's provider is xAI and xAI credentials resolve. If the active model belongs to a known provider that is not xAI, you have to opt in by turning the enabled setting on, which is what the documentation calls cross provider use. If the active model's provider is missing or unresolved, the tool stays hidden rather than guessing. Setting the same option to false disables it for every provider at once. In all of these cases xAI credentials are still required, since the work happens on xAI's side. The same configuration block is where you override the model, the cap on internal tool turns, and the request timeout. With the default hybrid reload mode, plugin configuration changes apply on their own, so a restart is only needed when the Gateway service's process environment changed. To confirm the result, send /tools in the conversation you care about and look for the tool in the list.

Using it well

• The tool takes a single task parameter, so the full request and any inline data have to travel in one prompt rather than being built up over several turns.
• For fresh X data the documented pattern is to run X search first and pipe its result into the analysis step, and the same shape applies to web search results.
• Without credentials the tool returns a structured JSON error rather than throwing an exception, which lets the agent read the failure and correct itself instead of stalling.

If what you actually want is a shell on your own machine or a paired node, the local Exec tool tool is the right surface and this one is not. And because the Python here runs on xAI infrastructure rather than inside your own Gateway sandboxing, none of your Gateway sandbox settings apply to it.

Why it is this narrow

The separation is the point. Local shell execution carries a policy question about what a command may touch, which is why it sits behind Exec approvals, and remote analysis carries none of that because it cannot reach anything of yours. That constraint is also why the tool keeps no state between calls, since there is no notebook to protect and no session for a later prompt to inherit. The cost model pushes in the same direction, because every call is billed, so a design that encourages one well formed request beats one that encourages exploratory poking. It also explains the single task parameter, which forces the caller to assemble the whole problem before spending a call. When the analysis needs live material, the data has to be fetched first by Web and X search tools and pasted into the request. The result is a tool that is easy to reason about precisely because it is allowed to do so little.

On Diali

Diali runs Hosted OpenClaw on Diali for you, each customer runs their own assistant, and the runtime configuration is generated from the dashboard and replaced at each release. If you are weighing up a tool that sends data to a third party for analysis, our Diali security notes are the right place to start.

• Remote Python on xAI, with no path to your files, shell, repository or devices.
• Hidden by default unless the active model is an xAI one, or you opt in.
• Metered per call, so send one complete request instead of exploring turn by turn.