Which coding agent

A cell runs one agent, chosen in the Agent Picker at the top of an empty cell. Five agents are first-class, plus Shell, which is not an agent at all.

They are not interchangeable. Each keeps its conversations in its own place, so only the agent that wrote a conversation can continue it — switching the picker changes which “or resume here” list you see. And they reach the GUI tools three different ways, which is the part most worth reading before you pick one.


The five agents at a glance

  Agent Picker Command Badge GUI tools reach it by Model override
Claude Code Claude (default) claude a per-session URL the Model picker, or a providers entry
Codex Codex codex cx a per-session URL CODEX_MODEL
Antigravity Antigravity agy agy a file in the directory ANTIGRAVITY_MODEL
Grok Grok grok gk a file in the directory GROK_MODEL
Muse Muse muse mu a plugin, per machine MUSE_MODEL

Every command can be pointed elsewhere with CLAUDE_BIN / CODEX_BIN / ANTIGRAVITY_BIN / GROK_BIN / MUSE_BIN — a pinned version, a wrapper, a path outside PATH.

Nothing has to be installed for an agent you do not use. An agent whose command is missing simply fails to start that cell; the others are unaffected.


How each one reaches the GUI tools

This is the real difference between them. “GUI tools” are MulmoTerminal’s own MCP tools — the ones that draw a chart in the Canvas, read the workspace’s data, and so on, grouped as render / data / media / external.

There are three routes, and which one an agent takes is a property of the agent’s CLI, not a setting you can change.

1. A per-session URL — Claude Code and Codex

In the workspace, these two are handed every tool on one generated URL, per session. There is nothing to register and nothing to switch on: the launcher form does not even show the tool-group toggles there, because they would not add anything.

In a project directory they use route 2 below, like everyone else.

2. A file in the directory — Antigravity and Grok

Neither CLI can be handed a URL at spawn, so both read a config file in the directory and get whatever that file registers — in the workspace too.

  • Antigravity reads a JSON file MulmoTerminal writes from the directory’s toggles, and rewrites whenever a toggle flips. Servers it did not write are left alone, and the file is kept out of git status.
  • Grok reads .grok/config.toml, which is yours — so MulmoTerminal drives grok mcp add rather than editing the file itself.

So with either of these picked, the four toggles stay visible in the launcher form even in the workspace. That is the truthful answer: they are the only way those agents get any GUI tools.

3. A plugin, per machine — Muse (new in 4.7.0)

Muse has no way to take a URL and no per-directory config either. Its MCP servers are declared by an installed plugin, and muse plugins install records one per machine — installing from one directory does not register anything in that directory.

So MulmoTerminal registers one plugin holding all four group servers, and narrows each session back to what its directory switched on. The plugin is installed and approved through Muse’s own CLI, and an unchanged plugin spawns no subprocess at all.

A group the session is not entitled to serves an empty toolset rather than an error — otherwise a cell that switched one group on would show three broken servers.

Two consequences worth knowing:

  • The plugin is machine-wide. It appears in muse plugins list for every Muse session on the machine, including ones MulmoTerminal did not start. Those resolve to no session and serve nothing. Remove it with muse plugins remove mulmoterminal; the next Muse cell re-registers it.
  • Muse’s plugin support is behind an experimental flag of Muse’s own. If a future Muse build renames or drops it, a Muse cell still starts — it just has no GUI tools, with one warning.

Resuming a conversation

OR RESUME HERE lists conversations in the current directory for the agent the picker has selected. Each agent keeps its own store, so the lists never mix.

  Where the conversation lives
Claude Code its own transcript directory
Codex a rollout file it writes per session
Antigravity its own conversation store
Grok its own store, keyed by directory
Muse a SQLite session index plus a session log

A resumed Muse session keeps its --workspace, which is what registers its workspace tools — a resume that dropped it came back with the conversation and without the tools (fixed in 4.7.0).

A Muse resume takes no seed prompt. Muse does not accept a prompt on a resume command line, so a seed is only sent on a fresh session.


The header badges

A non-Claude cell wears a short badge (cx, agy, gk, mu) so you can tell at a glance what a cell is running. Beside it the header shows the model and how full the context is, and the up/down arrows are the session’s token usage.

For Muse the context reading is the last completed call, not the largest ever seen — a high-water mark never came down after a compaction and told you to /compact when you need not (fixed in 4.7.0).


Shell is not an agent

Shell starts your OS default shell ($SHELL). Nothing to install, nothing to configure, no conversation and no GUI tools.

The launch commands below the picker are the same idea: they run the command line you wrote, verbatim. MulmoTerminal does not read that command — so a launch command whose text is claude is a terminal with Claude Code in it, not an agent session: no session id, no resume, no GUI tools, no badge. The Agent Picker is what starts an agent.


Running Claude Code differently

Two things widen what “Claude” means, and both are Claude-only.

A different backend or model — providers

A providers entry in ~/.mulmoterminal/config.json registers any Anthropic-compatible backend — OpenRouter, Moonshot, a local Ollama bridge, a company gateway — and it then appears in the Model picker beside Anthropic’s own models. A directory can pin its own provider / model so a project always runs on the same one.

Full setup, the measured pass rates of the built-in model list, and the misconfigurations that are hard to diagnose from inside a session: Providers and models.

Your own command line — customAgents

A customAgents entry is your way of starting Claude Code — a wrapper script, a pinned binary, ollama launch claude --model … -- — and it appears in the Agent Picker beside the five above. Claude Code’s whole argv is appended to what you wrote, so the session still resumes, still reports cost, and still gets the GUI tools.

This is what separates it from a launch command: the entry declares agent: "claude", so MulmoTerminal knows which CLI’s arguments to append. Only Claude is supported — an entry for another agent is not a label that would work.

See Configuration for the entry shape.



This site uses Just the Docs, a documentation theme for Jekyll.