Early access: your personal sandbox is free, with $5 in model credits included. AQ adds no markup on your model usage. Start free

aq.dev / alternatives / soloterm

Solo (soloterm) alternatives: when one machine is not enough

Solo (soloterm.com, by Aaron Francis) calls itself "the meta-harness for coding agents": a desktop app for macOS and Windows where Claude Code, Codex, OpenCode, and other agent CLIs run beside your local dev stack (dev servers, queues, workers) and coordinate through MCP, a local HTTP API, and a CLI. It is a genuinely thoughtful take on the local agent-sprawl problem. People search for Solo alternatives for three reasons, all of them the shape of the product rather than defects: everything runs on your machine and stops with it (Solo's own docs say it does not currently provide remote-host or headless session management), it is single-player (the shareable part is a config file, not a running session), and some people wanted a different shape entirely (a purpose-built agent terminal, a worktree orchestrator, or a vendor cloud). The right alternative depends on which of those is your actual problem: cmux and Conductor cover different local shapes, tmux on a server or a vendor cloud agent solves machine lifetime, and AQ moves the whole pattern onto an always-on VM your team shares. Honest fit notes on each below.

What Solo does well, and where it stops

Solo grew out of an open-source Laravel package of the same name (soloterm/solo on GitHub) that tamed local development by running every command a project needs in one place. The desktop app generalizes that idea and points it at agents. As of September 2026 it ships in beta for macOS (Intel and Apple Silicon) and Windows, with built-in support for Claude Code, Codex, Amp, Gemini CLI, OpenCode, GitHub Copilot CLI, Kimi CLI, and Antigravity, plus any interactive CLI agent (Pi, for example) added as a custom tool.

The interesting part is the coordination layer, which is why "meta-harness" is not just branding. Solo exposes MCP tool groups for projects, processes, output, agents, and coordination, so a lead agent in one harness can spawn an agent in another, send it follow-up work, read its output, and wait for it to finish: Codex can hand work to Claude, or Claude to Gemini. Shared todos, scratchpads, prompt templates, locks, timers, and key-value state live outside any one chat history, and a recent release added workspaces plus immediately captured session IDs so agent sessions can be resumed even after a hard quit. Around the agents sits a real process manager: auto-restart on crash, notifications, resource views, and a solo.yml config your team can commit to version control. The Free tier includes every feature for up to 4 projects and 20 processes; Pro is $99 for the first year ($69 per year to renew) for unlimited projects and processes.

Where it stops is equally clear, and Solo is refreshingly honest about it. Everything lives on one machine: the docs recommend SSH or tmux "for work that must survive on another machine," the HTTP API listens only on localhost and requires the running desktop app, and nothing runs when the laptop sleeps. And it is single-player by design (the name is not an accident): a teammate can commit the same solo.yml and reproduce your setup on their own machine, but they cannot open your running session, watch your agent work, or take over when you go to lunch. For vocabulary on the category Solo and its neighbors are converging on, see harness of harnesses.

Solo alternatives at a glance

ToolPlatformShapeSurvives the laptopTeam features (as of September 2026)
Solo (reference)macOS, Windows desktopMeta-harness: agents + dev stack + coordination primitivesNo (local only, by its own docs)Shareable solo.yml config; sessions single-user
cmuxmacOS 14+Native terminal purpose-built for parallel agentsNoNone (single-player)
ConductormacOSWorktree orchestrator for parallel agentsCloud workspaces on paid tiersMultiplayer on an invite-only paid tier
tmux + git worktrees on a VMAny Unix, any clientDIY: one worktree and session per taskYesShared SSH access (coarse)
Claude Code on the web / Codex cloudBrowserVendor-hosted sandboxes running the vendor's own agentYesOrg plans; sessions per-user
AQBrowser (macOS, Windows, Linux, mobile)Multiplayer harness: real CLIs in tmux on your team's VMYesShared live sessions, delegated control, previews, Linear

If you want a different local shape: cmux or Conductor

Some searches for Solo alternatives are really shape comparisons among local tools. If what you want is the best possible terminal for watching many agents at once (vertical tabs with git status, notification rings, split panes) rather than a process dashboard with coordination primitives, cmux is the purpose-built answer on the Mac: free, open source, and excellent at exactly that job. Our cmux alternatives guide covers its side of the field, including the Linux and Windows answers. If what you want is more automation around parallel tasks (managed git worktrees, diff review), Conductor is the established Mac orchestrator, free for local use with paid cloud and team tiers. What stays constant across all three: single-person tools on a single machine. Switching among them changes the workflow, not the lifetime of your sessions.

If the real problem is machine lifetime: move execution off the laptop

Solo's own docs point at the first alternative: tmux on a machine that stays up. A Linux VM, SSH, tmux, and one git worktree per task reproduce the core pattern (many agents, isolated tasks, everything visible) with one decisive upgrade: sessions keep running when your laptop closes. You lose Solo's dashboard, coordination primitives, and auto-restart, and you build the glue yourself. Running Claude Code on a cloud VM walks the setup end to end.

The other route is the vendor clouds: Claude Code on the web runs sessions in Anthropic-managed VMs against your GitHub repository, and Codex runs cloud tasks in isolated sandboxes on OpenAI's side. Both solve machine lifetime with zero setup, at the cost of the properties that likely drew you to Solo: one vendor's agent instead of every CLI in one place, a task queue instead of a live terminal beside your dev stack, and the vendor's sandbox instead of your machine. The cloud coding agents roundup compares the options.

If the real problem is that it is solo: the team gap

The single-player limit matters more than it first appears. A July 2026 LeadDev analysis of 25,264 agent-generated pull requests across 2,361 popular GitHub repositories found that in 79 percent of agentic PRs the same developer both reviewed and modified the agent's contribution, and only about one in eight workflows involved multiple humans. Local single-user tools make that the default physics: nobody else can see the session, so nobody else is in the loop before the PR. What changes it is a second person able to watch the same live session and step in; monitoring multiple coding agent sessions covers the visibility half across tools.

Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud.

Against Solo's two structural limits, AQ's answers are direct. Machine lifetime: agents run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on your team's VM (one you connect from your own cloud, or a dedicated always-on AQ-managed VM), streamed live to the browser, so sessions survive a closed laptop and resume from any device, including a phone. Single-player: teammates open the same workspace and watch the same live session; typing into someone else's terminal is delegated by its owner approving a control request in one click, and workspaces are team-visible or private and shared with specific people. The task mechanics are built in rather than scripted: each workspace gets an isolated git worktree (branch ai/{id}-{slug}, automatic dependency install, one-click rebase onto main), agents commit and open PRs with per-user GitHub auth, PRs are tracked per workspace, each workspace can run a live dev-server preview with shareable links that work without an account for viewing, and Linear issues flow in when someone labels them ai-task. Like Solo, AQ does not resell inference: you log into each CLI with your own Claude or OpenAI account, and AQ never marks up model usage.

The honest trade: Solo is a local-first desktop app beside your editor with programmable coordination primitives (MCP tools for spawning and sequencing agents, locks, scratchpads), and AQ is neither local-first nor that kind of programmable orchestration surface. If your workflow is one developer scripting agents against a local dev stack, Solo is better at being that. AQ earns its place when sessions need to outlive a machine or be seen by more than one person. Pricing is two plans: Free is a personal sandbox for one person (AQ creates a private machine in an isolated network, nothing to install, no time limit), and Team is $50 per user per month early access (standard $200, billed monthly), covering VMs you connect from your own cloud or a dedicated AQ-managed VM, with the rate locked for your first 12 months. There is no shared multi-tenant execution tier: your agents run on your VM.

How to choose

Solo's free tier covers every feature for four projects, so if you are one developer on one machine, try it before hunting alternatives; it may simply be the right tool. Want a purpose-built agent terminal instead of a dashboard: cmux on the Mac. Want managed worktrees and diff review locally: Conductor. Need sessions that survive the laptop on your own box: tmux and worktrees on a VM. Happy inside one vendor's ecosystem: Claude Code on the web or Codex cloud. And if the goal is many agents, always-on, where the whole team can watch and steer the same live sessions from any OS, that is the case AQ was built for; the Free sandbox is the no-cost way to test it.

Frequently asked questions

Is Solo (soloterm) free?

Partly. As of September 2026, Solo's Free tier includes every feature for up to 4 projects and 20 processes, and the Pro plan is $99 for the first year ($69 per year to renew) for unlimited projects and processes, with a 30-day money-back guarantee. The original soloterm/solo Laravel package it grew from remains open source on GitHub.

Does Solo run on Linux?

As of September 2026, Solo's download page offers beta builds for macOS (Intel and Apple Silicon) and Windows (64-bit); Linux is not among them. On Linux, the closest equivalents are tmux with git worktrees for the session layer, plus tools like cmux-style tmux automation for the agent workflow. Browser-based platforms like AQ work from any OS, Linux included.

Can Solo manage agents on a remote server?

No. Solo's own documentation says it does not currently provide remote-host or headless session management and recommends SSH or tmux for work that must survive on another machine. Its HTTP API listens only on localhost and requires the desktop app to be running. If always-on execution is the requirement, the practical routes are tmux on a VM you manage, a vendor cloud agent, or a harness like AQ that runs sessions on an always-on VM and streams them to the browser.

Can my teammates see or join my Solo sessions?

Not the running sessions. Solo's team-shareable surface is configuration: a solo.yml file teammates commit to version control so everyone's machine starts the same processes and agents. The live terminals, agent output, and coordination state stay on your machine, single-user. If teammates need to watch a live agent session or take over one, that requires a shared execution layer: coarse-grained via shared SSH and tmux, or purpose-built in a multiplayer harness like AQ, where control of a terminal is delegated when its owner approves a request.

What does Solo mean by meta-harness?

Solo sits above the coding harnesses you already use (Claude Code, Codex, OpenCode, Gemini CLI, and others) rather than replacing them: through its MCP tools, an agent in one harness can spawn an agent in another, hand it context via shared todos and scratchpads, wait for it to finish, and collect the result. The industry is converging on this layer from several directions; the harness of harnesses glossary entry covers the category and how the local and cloud takes on it differ.