Agent runtimes
The model dropdown in the Composer header holds two different kinds of thing. Composer models answer inside the Mantis assistant with the MCP tool set. Agent runtimes hand the turn to a coding agent running in a container with a shell and a filesystem. The dropdown separates the two groups with a divider, but they behave very differently, and the difference is not otherwise labelled in the UI.
The runtimes
| Runtime | What the backend says it is | Availability |
|---|---|---|
| Opencode | Sandboxed coding agent with shell and filesystem access | Always offered |
| Hermes | Nous Research’s Hermes agent via Bedrock with sandboxed tools | Always offered |
| Claude Code | Anthropic’s Claude Code via Bedrock with sandboxed tools | Only when your account has Bedrock enabled |
All three report a 200,000 token context window. None of them is marked as the backend default; the default flag belongs to a Composer model.
Which one you get
A freshly opened Composer picks the first available of codex, then Opencode, then whichever model the backend marks as default. codex is a local development runtime and is not part of the hosted model list, so in practice a new Composer panel opens on Opencode until you choose something else. The choice is not remembered across panel mounts, so reopening the panel returns to the same preference order.
Starting a chat with a custom agent from the agent catalog switches the model to GLM 5, regardless of what was selected before.
The sharp edge: mode is ignored
Important
Selecting ask and then switching to an agent runtime does not give you a read-only agent.
The Composer mode selector applies only to the Composer models. A model counts as an agent runtime when its name is opencode or claude_code, or when the backend puts it in the agent group, which also covers Hermes. For those models the frontend hides the mode selector entirely and never sends a mode, so the read-only tool policy that ask mode enforces is simply not in play. An agent runtime turn can write to the container, edit files, and run commands.
If you want the guarantees that ask mode makes, stay on a Composer model.
How a runtime turn actually runs
An agent runtime turn does not execute in the WebSocket handler. The chat consumer queues a Celery task with the session, your message, and the message id, then opens a bridge that consumes the runtime’s events from Kafka and forwards them to your browser.
That has one practical consequence worth internalizing: a turn that hangs is a backend condition, not a frontend one. Reloading the page or reopening the panel will not restart it. If the Celery worker or the Kafka bridge is down, the turn was accepted and then never produced events. The frontend’s job here is only to render what arrives.
The events you see in the transcript are the runtime’s own: turn start and end, thinking, tool calls, tool results, and the streamed reply. A tool-only run can finish without emitting any text at all, which is why the transcript can end on a completed turn with no assistant message.
Stop clears the composer state immediately and asks the server to cancel the run. Cancellation is best effort.
Seeing what the turn did
The runtime works in a container that you share with it. The Agent workspace panels are the window into it: File Browser shows the files, Editor opens them, and Terminal gives you a shell in the same container.
What runtimes do not do
- They do not honor the Composer mode, so
askgives you no protection here. - They do not get the Composer’s map tool policy applied per mode. What a runtime can reach is decided by its own sandbox and MCP configuration on the server.
- Claude Code will not appear at all unless Bedrock is enabled for your account.