# A daemon with memory, a heartbeat and four ways to talk to it

> rho is an always-on personal AI operator built on the pi coding agent: it stays running in the background, keeps durable context in an append-only memory file, checks in on a schedule every 30 minutes, and exposes the same agent through a terminal, a no-build web workspace, Telegram and an email inbox at rhobot.dev. What makes it unusual is that the memory is inspectable and editable rather than sealed inside a model.

**mikeyobrien/rho** — An AI agent that stays running, remembers across sessions, and checks in on its own. macOS, Linux, Android. Built on Pi.

- Repository: https://github.com/mikeyobrien/rho
- Website: https://rhobot.dev
- Stars: 371 · Forks: 29
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/mikeyobrien-rho

## The daemon is the product, not the chat window

The pitch starts by naming what rho refuses to be: most AI tools are stateless chat tabs. An always-on personal AI operator stays running in the background, remembers context across sessions, and checks in proactively on a schedule, with the heartbeat firing every 30 minutes by default.

Two supporting properties matter more than the slogan. The first is memory observability: you can inspect, search and edit what the agent has learned, rather than trusting a summary of your own preferences. The second is local-first state, with memory and config staying on your machine, and the model and provider being your own pi setup rather than an account with the project.

The four surfaces follow from that. Terminal, web UI, Telegram and an agent email address are all ways into the same running agent, which is the point of an operator rather than a chat app: the agent keeps working whether or not you are looking at it.

It is built on the pi coding agent, and the package metadata reflects that by declaring extensions and skills directories rather than bundling a model.

## Memory is three subsystems, and none of them needs a server

The core runtime has three named parts. Heartbeat is the scheduled autonomous check-in. Brain is append-only structured memory stored as brain.jsonl. Vault is a markdown knowledge graph under ~/.rho/vault/, reachable in a session through commands like /vault inbox.

The split between Brain and Vault is the design worth understanding. Brain is a log you append to, which is why it can be searched and edited in place and why /brain opens a memory viewer rather than a settings panel. Vault is prose you keep, which is the right shape for knowledge that arrives as documents.

Both live in your home directory: ~/.rho/brain/brain.jsonl for memory, ~/.rho/init.toml and ~/.rho/packages.toml for configuration, with the vault directory beside them. The security section states the position plainly, no hosted rho memory backend required.

That is a real trade rather than a free win. Local state means you can read and correct what the agent believes, and it also means the daemon's entire memory is one directory you have to back up and protect like any other personal data.

## Four commands, and tmux is a prerequisite

The recommended quick start is short, and the prerequisites explain why it is short: Node.js 18 or newer, tmux and git.

```bash
npm install -g @rhobot-dev/rho
rho init && rho sync
rho login && rho start
rho
```

Each step has one job. rho init creates the config under ~/.rho/, rho sync pushes that config to pi, rho login authenticates provider access through pi, rho start brings up the background heartbeat daemon, and a bare rho attaches an interactive session to it.

The first five minutes are then a list of inspection commands rather than features:

```bash
rho status                # daemon + module health
/rho status               # heartbeat status (inside session)
/rho now                  # trigger immediate check-in
/brain                    # open memory viewer
/vault inbox              # see captured knowledge items
```

There are four install routes. A pi package install is pi install npm:@rhobot-dev/rho followed by the same init, sync, login and start. A source route clones into ~/.rho/project and runs ./install.sh, which checks missing dependencies and supports NixOS. Android goes through Termux and Termux:API with curl -fsSL https://rhobot.dev/install piped to bash. And iPhone or iPad is not native at all: you run rho on a server or home machine and connect over SSH with Termius or any other client.

## The web workspace is deliberately unbundled

rho ships a browser workspace for day-to-day operation: streaming chat, session browsing with forking from any message, memory management, task management, config editing against ~/.rho/init.toml, and line-level code review at /review.

The implementation choices are unusual enough to be worth naming. There is no frontend bundler or transpile pipeline: server logic lives in web/*.ts and the browser runtime in web/public/js/*.js. Routes are Hono-based with response compression on, and chat responses stream over RPC or WebSocket. Where possible the server pushes instead of being polled, emitting a sessions_changed UI event that the client applies immediately.

The rest is honest performance work rather than architecture: polling pauses when the tab is hidden or the user is idle and resumes on activity, markdown updates during streaming are debounced at 150ms so rapid token deltas do not churn the DOM, and session metadata is cached by file mtime to avoid re-reads.

Three flags start it:

```bash
rho web
rho web --port 4000
rho web --open
```

and the default address is http://localhost:3141, or your host IP if you want another device to reach it.

## Email and Telegram are channels with their own guardrails

Two channels reach the agent from outside your terminal. Email gives you an inbox at name@rhobot.dev, and the agent polls it, reads it and replies. Telegram is a polling adapter with an allowlist and a moderation flow, and the agent answers in-thread to prompts it receives there.

Both come with controls rather than being open doors. Telegram uses allowlists and mention gating, so a group member cannot drive the agent without being permitted and addressed. Email has sender controls plus outbound policy limits on what the agent may send.

Inside a session the same reachability shows up as slash commands: /rho, /brain, /vault, /skill, /telegram and /email, with the CLI covering the same ground through rho subcommands.

The use cases the project lists map onto those surfaces: a daily operator loop that keeps reminders and tasks alive between sessions, a memory-backed coding copilot whose learned preferences you can edit, the email inbox agent, the Telegram-controlled agent, and the browser panel as the general control surface.

## Live Mode is the Android trade you have to choose

The native Android wrapper around rho-web has one explicit switch, and it is about continuity rather than features. Idle Mode is the default and the best for battery: no always-on background socket while the app is backgrounded, with reconnect and replay when the app becomes active again.

Live Mode, started with GO LIVE, launches an Android foreground service with a persistent notification and lease heartbeats to keep active streams alive while the phone is locked or in the background. You need it when a long response has to keep streaming with the screen off.

Without it, the README warns, WebView background limits can cause disconnect or orphaned behaviour around the default orphan window, which is the failure mode this mode exists to prevent.

The costs are listed rather than hidden: higher battery and network use while it is active, a permanent foreground notification, and a lifecycle you have to manage yourself with GO LIVE and STOP LIVE. Live Mode does not require Firebase credentials.

One graceful degradation is worth knowing on Termux: if the optional node-pty native module will not build, rho still installs and runs, and only the embedded web terminal drawer stays disabled until it compiles.

## The project's own comparison with OpenClaw and nanobot

The README positions rho against two alternatives in a small table, and the claims are about emphasis rather than features.

rho is described as a built-in operator workspace with stronger memory observability and a lightweight no-build stack, listing chat, learned-memory inspection and editing, tasks, config and review. OpenClaw is characterised by a strong Gateway Control UI plus a WebChat control plane, so the difference is where the work happens: a gateway-oriented control plane against an operator workspace you use directly. nanobot is described as a README that primarily emphasises CLI and channel gateway flows, so the difference there is surface area and documentation focus.

Treat that table as the project's own framing rather than a benchmark. What you can verify from the tree is the substance behind the middle column: an append-only memory file you can edit, a vault you can browse, a tasker directory, a web/review route and configs you can change from the browser.

The honest question for an evaluator is whether memory observability is what you are missing in your current setup, because that is the claim being made and it is the one with evidence in the repository.

## Version 0.1.12, with scripts that admit there is nothing to build

The package metadata is candid in a way most repositories are not. The build, lint and typecheck scripts are not real steps: each one prints a message saying there is no build step, no lint step or no typecheck step, because the CLI runs as cli/rho.mjs straight from source.

The test script loops over tests/test-*.ts through tsx and exits on the first failure, skipping tests/test-vault.ts specifically, which tells you the vault tests are not part of the default gate. There is a separate web test through playwriter and a telegram smoke script.

The pi integration is declared rather than implied: a pi block pointing at ./extensions and ./skills, with peer dependencies on the pi packages left at wildcard versions, and Biome present as the formatter.

Distribution is broader than the npm entry point suggests. flake.nix and flake.lock carry Nix support, apt/ and postinst carry Debian packaging, mobile/ holds the Android wrapper with its own install, build and sync scripts, and five ralph*.yml files at the root look like agent workflow definitions rather than application config.

On cadence, v0.1.12 shipped on 2026-03-15 after two releases the day before, and the last push was on 2026-10-01. A project at 0.1.x with releases months older than its last push is fine, but the README copy available here is cut off in the command quick reference, so check the repository for the current command list.

## Conclusion

Adopt rho if you want an agent that survives between sessions and whose memory you can read and correct, and if you are willing to run a background daemon with tmux on your own machine. Do not adopt it if you need a hosted, shared or audited memory backend, because everything lives in your home directory and there is no hosted component by design. Verify first that your provider login through pi works on the machine that will hold the daemon, since rho login is the step that binds it to your model.

## FAQ

### How do I install rho?

With Node.js 18+, tmux and git installed, run npm install -g @rhobot-dev/rho, then rho init && rho sync, rho login && rho start, and a bare rho to attach. Alternatives are pi install npm:@rhobot-dev/rho, cloning into ~/.rho/project and running ./install.sh which supports NixOS, or the Termux route on Android.

### Where does rho store its memory?

On your machine. Brain is an append-only structured memory file at ~/.rho/brain/brain.jsonl, Vault is a markdown knowledge graph under ~/.rho/vault/, and configuration lives in ~/.rho/init.toml and ~/.rho/packages.toml. The README states no hosted rho memory backend is required.

### Can I see and edit what rho has learned about me?

Yes, that is memory observability, described as one of the reasons rho exists. The /brain command opens a memory viewer, /vault inbox shows captured knowledge items, and the web workspace includes memory management alongside chat, tasks, config editing and line-level review.

### What does the rho heartbeat do?

It is the scheduled autonomous check-in, firing every 30 minutes by default. Inside a session you can inspect it with /rho status, and /rho now triggers a check-in immediately rather than waiting for the next slot.

### Does rho need an API key of its own?

No, you bring your own model and provider through the pi setup, and rho login authenticates that access. The README describes this as a bring-your-own model arrangement, with providers being yours rather than a hosted account with the project.

## Sources

- [License: MIT](https://github.com/mikeyobrien/rho/blob/main/LICENSE)
- [mikeyobrien/rho on GitHub](https://github.com/mikeyobrien/rho)
- [Project website](https://rhobot.dev)
- [README](https://github.com/mikeyobrien/rho/blob/main/README.md)
- [Releases](https://github.com/mikeyobrien/rho/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mikeyobrien-rho