
Inari is now MIT, and it runs on a core of our own
Inari began as a coat of paint on someone else's excellent app. Today it is a core, a web interface and an Android client of our own, written for the way we actually work, and the whole repository is MIT. Here is what we borrowed, why it is good, and why we stopped borrowing.
What you get. The source of the new Inari, an honest picture of how it differs from Cloudroom (what each is for), and the reasons we moved, so you can tell which one fits you.
What we used: Cloudroom
Cloudroom, by David Ondrej, is a desktop app for Claude Code, Codex and Pi. Your agents run on your Mac or in the cloud, on your own subscriptions. Its interface is Apache-2.0, its core can be self-hosted, and local use needs no account. For a few weeks we ran it that way and repainted it with our own colours, our kitsune signature and our name. We never forked its engine: a small tool patched each upstream release in place. That was the first Inari.
Why it is great
- Teleport. Move a running thread from your Mac to the cloud and back, with the same chat, model and effort.
- A cloud computer per thread, with its own Git branch, and a dial for how much a cloud agent may do on your Mac: off, read-only, ask first, or full.
- Several Claude and Codex accounts, switched in one click, and computer use: agents that see and drive desktop apps.
- Pace and polish. More than fifty releases in under four weeks, signed and notarized, with a phone app.
It is built for people with structural needs: several frontier subscriptions, work that must run in the cloud, a team. That is a real problem, and it is solved well. It is not quite ours.
What we needed instead
- Our own machines, not a vendor's cloud. A laptop, a GPU box, a small server, any number of them, cooperating.
- Cost under control. Local models for free, free tiers where they exist, a frontier subscription only when the task deserves it. One place that pools every access we have.
- A family. A child using AI on the family core while a parent follows every thread, and a friend continuing a thread on their own machine.
- Nothing to sign in to, nothing phoning home, and an agent's state that is a file you can read.
- Small. One static binary of about 6 MB per machine, roughly ten megabytes of memory at rest.
What Inari does now

- Move a thread by dragging it onto another machine: the conversation, the files and the state travel together, two-phase and with rollback.
- Every agent through one protocol. Claude Code, Gemini CLI and OpenFox all speak the Agent Client Protocol, so a thread can change model, mode or agent without losing its history. The page shows each agent's own modes (plan, accept edits, build…) and slash commands.
- Approvals in the conversation. When an agent asks to run something, a card appears in its thread: deny, allow once, or always allow here. Auto mode lets a thread act without asking, and every action is still journaled. Stop interrupts an agent at once.
- Core passes. A collaboration pass shares threads with a friend; a supervision pass lets a parent follow a child's threads and answer the agents' requests, and the child always sees that it is so.




The Android client is a thin app: it opens a core's interface behind the phone's fingerprint, keeps the login to your gate in the Android Keystore, and takes what other apps share (a photo, a document, a link) straight into the message box. Where your core is and where updates are published are build settings, never in the source.
Where Cloudroom is still ahead
We do not try to match it on a cloud computer per thread, on computer use, or on a signed desktop app for macOS. If those are what you need, use Cloudroom; it is excellent, and the ideas we kept (teleporting a running agent, switching model mid-thread) are its.
The repository, and the licence
The new repository is github.com/bengua/inari, MIT, and it is developed on our own forge too. It holds the Rust core, the web interface, the Android client and the documentation. The first Inari, and the fork of Cloudroom's interface it ran on, are archived under inari-v1 and inari-gui, kept for history. No code of Cloudroom's is in the new one, and we say so to be clear about what is ours.
Try it
git clone https://github.com/bengua/inari.git
cd inari
cargo build --release # one binary: target/release/inari-core-rs
# write a node.json (docs/node.md lists every option), then:
target/release/inari-core-rs node node.json
Open the address of the gateway you configured. Add the agents installed on that machine to the harnesses of the file, and join a second machine to the first with inari-core-rs join. For the phone, android/build.sh builds the app in a container; point it at your core with a build.env file (see android/README.md).
Inari has no sign-in by design. Bind its gateway to loopback and reach it from your other machines over a private network (Tailscale, WireGuard, an SSH tunnel), behind a reverse proxy that asks for a login if you want one. The cores' transport authenticates but does not encrypt: keep it on that private network.
Sources: Inari (MIT), Cloudroom GUI (Apache-2.0), Agent Client Protocol. Thank you to David Ondrej for Cloudroom, which this project ran on and learned from.
Found this useful? Tell us what to measure next.