Skip to main content
Experimental features are new and their interface and implementation may change at any time. Expect sharp edges.
Chat in the Pluto sidebar answers questions about your runs in plain language — “why did MMP-42 diverge?”, “which of last week’s runs had the most stable loss?” — by querying your metrics, logs, config and files directly. It has two backends, chosen from the Chat backend selector at the top of the page: This page covers Local agent mode, which is available today.

​
How local agent mode works

A small program called the bridge runs on your machine. The Pluto web app sends it your chat messages over loopback; the bridge runs your agent CLI, and the agent looks up experiment data through the Pluto MCP server using your API key.
Two consequences worth knowing up front:
  • Inference runs on your machine, under your own Claude or ChatGPT subscription. Chat costs nothing extra and uses no Trainy model quota.
  • Conversations never pass through Trainy’s servers. Only the data lookups your agent makes reach Pluto, as ordinary authenticated API calls.

​
Requirements

You do not need to set up the MCP server separately. The bridge configures it for the agent session it starts.

​
Setup

​
Step 1: Start the bridge

In the Pluto UI, open Chat and set the backend selector to Local agent. The page shows the exact command to run, pinned to a version:
Run it in a terminal. Use the command shown on the Chat page rather than this one — it pins the version that page expects, which is how a compromised release cannot reach you automatically. The bridge prints a port and a pairing token:

​
Step 2: Pair the browser

Click Connect agent, enter that port and token, and save. The dot next to the button turns green once the health check succeeds. The token is stored at ~/.config/pluto-bridge/token and reused, so restarting the bridge does not break the pairing. You only pair again if you rotate the token with --rotate-token.

​
Step 3: Ask

Pick a project from the selector and ask away:
“Compare train/loss across my last three runs — which one converged fastest?”
“Run MMP-42 failed at step 12000. What do the logs say?”
“Are there any loss spikes in the runs tagged baseline?”
Multi-turn context uses your agent’s own session resume, so follow-up questions keep the thread.

​
What the agent can reach

The agent gets an explicit allowlist of read-only Pluto tools — projects, runs, metrics, logs, files, statistics, comparisons and dashboards. The full tool list is on the MCP Integration page. Pass --allow-writes to additionally let it add or remove tags, edit notes, and create, edit or restore dashboards:
Everything the agent can reach is bounded by your API key, so it sees exactly the projects you do — no more. With --allow-writes it can change tags, notes and dashboards for anyone in your organization, so leave it off unless you want the agent editing shared state.

​
Options

​
Self-hosted Pluto

A self-hosted deployment serves the UI and the MCP from your own domains, so name both:

​
Security

  • Loopback only. The bridge listens on 127.0.0.1, so other machines cannot reach it.
  • Pairing token. Every request must carry the token, and the token file is readable only by you (0600).
  • Origin allowlist. Browsers may call the bridge only from https://pluto.trainy.ai plus any origins you add with --origin. Someone who sees your token still cannot use it from another website.
  • Read-only is enforced by the agent, not by a prompt. Claude Code runs with --strict-mcp-config and the write tools in --disallowedTools, which beats your own allow rules; Codex runs with --ignore-user-config, enabled_tools limited to the granted tools, and shell commands in the read-only sandbox. Text sitting in run data cannot talk the model past that boundary.
  • Your API key stays out of the process list. The agent reads PLUTO_API_KEY from its environment, never from a command-line argument.
  • No runtime dependencies and no install scripts in the published package.
Because Codex runs with --ignore-user-config, settings in your ~/.codex/config.toml — model choice among them — do not apply to bridge chats. Sign-in still comes from CODEX_HOME.

​
Troubleshooting

The browser origin is not on the allowlist. Restart the bridge with --origin <that origin> — needed for any self-hosted Pluto, and for http://localhost:3000 during local development.
The bridge stopped answering — usually the terminal was closed or the machine slept. Your conversation is still on screen; restart the same command and it reconnects automatically, because the pairing token persists.
Your organization is not in the private preview for the hosted model. Switch the selector to Local agent, which works regardless, or contact us.
Check that the terminal running the bridge shows Agent: claude (or codex) and no MCP errors. If the agent CLI is not signed in, it fails before reaching the Pluto tools — run claude or codex once on its own first.

​
Feedback

Chat and the bridge are experimental. We’d love to hear how they behave on real experiments: