maiTerm vs Solo
The closest comparison: both wrap the agent CLIs you already have, and both run your project’s processes. Solo leads on breadth of agent support and hands-on process control; maiTerm discovers the stack rather than asking you to declare it, and leads on supervising agents and reaching them remotely.
What Solo is
Solo is a Tauri desktop app that describes itself as a meta-harness for coding agents. It runs the CLI agents already installed on your machine alongside your project’s processes — dev server, queue workers, tunnels — defined once in a shared solo.yml, and exposes the whole workspace to agents through MCP, HTTP and a CLI, with scratchpads, todos, prompt templates and agent spawning as primitives.
Where Solo is the better choice
Solo supervises processes; maiTerm runs them in terminal tabs. That difference keeps mattering at the edges — quit maiTerm and its stack goes with it, to come back as definitions waiting to be started, where Solo can reattach to something already running, and it handles orphaned processes itself. Solo also supports more agent CLIs out of the box, has prompt templates and git-worktree linking, and has a considerably larger community around it. And its solo.yml commits with the repository, which matters most for a project whose processes are not declared in anything maiTerm could import.
Which to use
These two overlap more than either does with anything else, and since maiTerm 2.4 they overlap on your dev stack too — nine processes, duplicate ports and rebuilding the same layout every morning are a problem both of them now answer. They come at it from opposite ends. Solo has you declare the processes once, in a file that commits with the repository. maiTerm reads what the project already declares — package.json scripts, a Procfile, a compose file, a justfile — and offers that back as a checklist, so setting a project up is a few ticks, or one instruction to an agent. Solo’s way is the better one when the processes are not written down anywhere yet; maiTerm’s avoids keeping a second copy of something the repo already says. Past that the question is what else is watching, and if the pain is the agents themselves — a dozen sessions, one about to hit a compaction wall, one stuck at a permission prompt, three of them on remote hosts — that is what maiTerm is built around.
Side by side
| maiTerm | Solo | |
|---|---|---|
| The agent CLIs | Claude Code and Codex through one runtime-neutral pipeline. Others run in a tab, without the agent-aware features. | Built-in support for a longer list — Claude Code, Codex, Amp, Gemini CLI, OpenCode, Copilot CLI and more — plus any interactive CLI as a custom tool. |
| Your dev stack | A workspace declares what its project runs, imported from package.json, a Procfile, compose or a justfile. Each service is a real tab maiTerm owns — kept out of the tab strip so it cannot be closed by accident, watched, restarted with backoff when it crashes, and read for the address it announces so the port lands in the sidebar by itself. Every agent in the workspace drives the same one. | The centrepiece: solo.yml defines the processes and commits with the repo, humans and agents share them, no duplicate npm run dev. |
| Supervision | Overlord watches every agent tab in a window and acts on rules you write — deterministic, no model in the loop, every directive held for approval by default. The Loom puts every agent’s conversation and open prompts in one view, answerable without visiting its terminal. | Heuristic status detection — working, idle, waiting for permission, blocked — with optional auto-summaries, unread badges and an attention-jump shortcut. |
| Agents talking to each other | Mesh: every agent in a workspace addresses any other by role, across repositories, with topics and loop caps. | Agent spawning: a lead agent spawns others, even in a different harness, waits for them and collects the result. |
| Coming back later | Follow-ups: the agent schedules its own next prompt into its own tab — at a time, when a service comes up or stops, when a task ends, or when a check script it wrote (and you approved) passes. Held by maiTerm, so it survives a restart, and an exited agent is relaunched to receive it. | “Set timer” gives a running agent a delayed prompt, set by you from the command palette. |
| Remote hosts | First class. Remote agents over SSH get the same tab identity, task board, notes and MCP tools through a reverse tunnel. | Not offered — their docs point you at SSH and tmux for work that must live on another machine. WSL is supported on Windows. |
| Phone | maiLink connects a phone directly to your machine over your LAN — watch, answer, approve, and work the board. No cloud in the data path. | None. |
| When the app restarts | Tabs, layout and scrollback come back. Services come back as definitions, stopped, for you to start again — a service is a tab, and a tab does not outlive the app. | Can reattach to a process that is still running, so a restart of the UI need not be a restart of your stack. |
| Terminal state | Scrollback persists to SQLite and comes back after a restart, along with layout and sessions. | Process definitions persist and it can reattach to a running process; terminal output is kept for the current run rather than archived. |
| Platforms | macOS (Apple Silicon), Windows, Linux. | macOS and Windows. Linux planned, not yet available. |
| Price | Free, every feature, no account. | Free for up to four projects; Pro is $99/year for unlimited. |
Solo details are as published by its makers as of 2026-09 and may have changed since — check their own documentation before deciding.
Try it against your own desk
It is a terminal first. Open a project, run a shell, and turn the rest on when you want it.
Also compare: maiTerm vs Warp maiTerm vs iTerm2