Local vs hosted
Revue has one decision-plane implementation with two deployments. The product loop is the same in both; reachability, credentials, and storage differ.
| Local | Hosted | |
|---|---|---|
| Start | revue service start | revue or revue login |
| Account | None | Browser-approved Revue account |
| Reachability | 127.0.0.1 on this machine | Hosted Revue service |
| Agents | Processes on the same machine | Local and remote agents with workspace credentials |
| Memory | Owner-only local JSONL event log | Configured hosted workspace |
| Restart after reboot | Manual | Not applicable; the service is hosted |
| Best fit | Personal work, evaluation, local harnesses | Remote Orbs, multiple machines, persistent shared operation |
Local and hosted memory are separate. Revue does not synchronize or merge them, and one CLI configuration selects one plane at a time.
Use the local plane
revue service start
revue service statusThe service binds to 127.0.0.1:47838, creates distinct machine and human credentials, and writes its owner-only state under ~/.config/revue and ~/.local. It survives terminal closure but is not installed as a launchd or systemd service, so start it again after reboot.
Use local mode when every connected harness runs on this machine. The loopback service cannot be reached from an Amp Orb or another computer. Launch a local child, or switch to hosted mode before launching remote agents.
Stop it with:
revue service stopStopping the process does not delete local decision memory.
Use the hosted plane
With no plane configured, bare revue starts browser approval and then launches the Amp manager when Amp is installed:
revueTo approve hosted access without launching the manager immediately:
revue loginThe approval provisions workspace-scoped machine credentials under ~/.config/revue; you do not paste an API key into the browser. Use revue login --api-url <url> only for a non-default deployment you know is supported.
Hosted mode is appropriate when an Orb, remote machine, or other remote asker must reach the same decision plane. A long-running resident manager can use either deployment; the local plane remains loopback-only. Intentional decision content leaves your machine in hosted mode, so read the Data boundary before connecting sensitive work.
Switch planes
These commands select a plane as well as connect to it:
revue service start # select local
revue login # select hostedAfter switching, rerun revue connect <harness> and update the harness configuration. The generated command and credentials differ by plane.
Switching does not copy decisions. A question answered locally is not reusable in hosted mode, and a hosted answer is not present in the local event log.
Launch the manager
Once either plane is active, bare revue launches the Amp manager against that plane:
revueThe manager is the preferred cockpit, not a requirement for askers. Any supported MCP harness can ask through revue-mcp, and humans can answer without Amp through revue inbox --interactive.