Neutron is open source

For the last ninety days I have run three companies, two side projects and most of my personal life using Claude Code, orchestrated by a piece of software I built for myself. It started as a private system I called Vajra, born out of frustration with the tools that existed. I wrote up why I built it, what it feels like to live in, and a full teardown of how it works. The question I got over and over from people was “can I run this myself?”

Now you can. Neutron is open source, Apache 2.0, at github.com/rjunee/neutron. It is self-hosted by design. It runs on your own machine, your data stays on your own disk, and it manages a fleet of Claude Code sessions through your own Anthropic subscription.

Why open source

Two reasons, and the second one is the real one.

The first is trust. This system manages my email, my calendar, my files, my businesses’ internal state, my family logistics. I would not run a black box over that surface, and I would not ask you to either. The honest version of “your data stays on your machine” is a repo you can read line by line.

The second is that the harness is not the moat, and pretending it is would slow down the thing I actually want. The frontier models are necessary but not sufficient; the scaffolding around them (the runtime, the memory, the scheduling, the policy layer) is where the daily-driver experience lives. That scaffolding gets better faster in the open. Peter Steinberger’s OpenClaw invented many of the conventions I still use. Garry Tan’s GBrain gave me the best persistent memory store. Every Inc’s compound-engineering plugin is the build primitive inside my autonomous shipping loop. I took freely from all of them. The right move is to put my work back on the same table.

Apache 2.0 because it is the least friction for the people most likely to actually build on this: it is permissive, it is patent-safe, and nobody has to think twice before using it at work.

What’s in the repo

Neutron is the substrate from the teardown, packaged so you can stand it up without reverse-engineering my setup. The pieces:

• The gateway. A single Bun HTTP server bound to loopback. It is the only always-on process in the system. It routes messages in and out, owns the durable state (the routing table, the reminder store, the agent registry), and runs a stack of supervision loops that keep the fleet healthy. Everything else is either a Claude Code session or a JSON file.
• The session fleet. Long-lived Claude Code sessions, one per project, each in its own tmux window, each resumable across days with --resume. This is the part that makes “starting cold every time” go away. Open a project and you are talking to a process that has held that project’s full history for weeks.
• The channel layer. The adapter between a chat interface and the gateway. The bundled web app and mobile app are the default front door. I personally run mine through Telegram, which is an optional adapter, not a requirement. The gateway only ever sees “a message came in for project X” and “send this reply back out,” so the front door is swappable without touching anything underneath.
• The MCP reply tool. A tiny per-session MCP server that gives a headless session a way to talk back. Without it, a session running in a detached tmux window can think all it wants and you see nothing. With it, and a Stop hook that refuses to let a turn end without a reply, the session always answers.
• Memory, powered by GBrain. Durable, persistent memory is the feature that separates a daily driver from a chat window. Neutron’s memory layer is built on GBrain: one markdown file per entity, a rewritable compiled head, an append-only timeline below a horizontal rule. The agent reads what it needs before a conversation and writes back after. My personal system layers more stores on top of this; the GBrain core is what ships and it is the part I would tell you to start with. The memory post is the deep dive.
• Reminders and cron. A durable JSON store and a tick loop. Each reminder, at fire time, spawns a small short-lived worker that reads the current state of the world and composes a message that fits the moment, rather than sending a fixed string. The 10am “feed the dogs” nudge knows whether it is raining.
• Background workers. When a session needs to do something heavy (a research dispatch, a code build, a review), it hands the work to a detached worker that runs to completion and posts the result back to the right project. The registry tracks every spawn and completion so a worker that dies silently gets caught and surfaced, not left to spin forever.

The rules that make all of this reliable are in code, not in prose the model is asked to remember. That is the whole lesson of the origin story: conventions erode under attentional pressure on the model; hooks and assertions do not.

How to self-host

You need a Mac (or a Linux box) that can stay on, Bun, tmux, and a Claude subscription. Authentication is your own: Neutron uses claude setup-token so the fleet runs on your account, your quota, your billing relationship with Anthropic.

The install is one line:

curl -fsSL https://neutronagent.ai/install.sh | sh

The installer stands up the gateway, wires the Claude Code settings and hooks, and walks you through claude setup-token and creating your first project. From there, creating a project is: name it, point it at a working directory, and the gateway spawns a session.

If you want to understand every piece before you run it, the teardown builds the whole thing up from a single tmux pane, with the real code for each layer. You can build the spine yourself in a weekend, but sorting out the edge cases will probably take months. The repo is the polished version of exactly that.

The architecture in one paragraph

A small always-on gateway routes messages between a chat interface and a fleet of long-lived Claude Code sessions, one per project, each running headless in tmux and resumable across restarts. Sessions talk back through an MCP reply tool over loopback. Durable memory lives in GBrain-format markdown files the agent reads before it needs them. Reminders and heavy work are handled by short-lived workers the gateway spawns and supervises. The substrate is Claude Code; the harness boundary is clean enough that you could point it at local open-weights for an airgapped install, but the bet I keep making is Claude Code. The whole thing is well under 20,000 lines and depends on no model abstraction. That is the system. The rest is watchdogs and edge cases earned in production.

Cores and Neutron Connect

Two things sit on top of the substrate.

Cores are the business logic: pre-built workflows that install onto the foundation in one step. Eight ship free in the box: notes, tasks, reminders, calendar, email, research, code-gen (autonomous build, review, and merge, powered by Neutron’s built-in Trident loop), and agent-settings. More will be coming, and the ecosystem is open: anyone can build and publish a core, including paid third-party ones, and the runtime treats them all the same. A core is a working system, not a template, and it assumes the substrate is already there underneath it.

Neutron Connect is how you invite other people into your projects: a teammate, a collaborator, a contractor, scoped to the projects you choose. The default is single-user and fully private; Connect is the opt-in path to shared work.

Both are their own posts. The substrate is the thing that is open today.

Standing on other people’s work

Neutron is a combination of the parts that were figured out by people I learned from, and the open-source release is partly an act of crediting them in the most concrete way available.

• Claude Code (Anthropic) is the substrate. Every agent in the fleet is a Claude Code process. The depth of its tool ecosystem, MCP, skills, hooks, and session persistence is the reason I bet the whole system on it instead of a model abstraction. The reasoning is in the origin story. I’ve tried all the models and for me nothing comes close to Claude Code.
• OpenClaw (Peter Steinberger) is the direct ancestor. The SOUL / USER / TOOLS / MEMORY file conventions, and the structural idea that a long-running agent needs durable files any session can read into its prompt, are all OpenClaw’s. Neutron exists because OpenClaw didn’t work for me as a daily driver.
• GBrain (Garry Tan) is the memory format, and it is load-bearing. One file per entity, compiled head over append-only timeline, provenance and confidence on every claim. Neutron’s persistent memory is GBrain, ported with no improvements to the file format because it did not need any.
• compound-engineering (Every Inc) is the build primitive inside Trident, the autonomous shipping loop. Without it there is no Forge. The full mechanics are in the Trident post.

Each of these solved a problem I would have solved worse on my own. Opening Neutron is how I put the result back where they put theirs.

It’s pre-release. Star the repo.

I made the Neutron repo public now, ahead of being polished. The substrate is what I run every day and trust with everything, but the install path, the docs, and the web app are still hardening, and the Cores ecosystem is just opening up. If you want to follow along or build on it, star github.com/rjunee/neutron so you see the releases land, and open an issue or a PR if you hit an edge.

If you want the why before the how, start with why I built Neutron. If you want to build the whole thing yourself and understand every layer, the teardown is the one to read. And if you want help putting agents to work in your own business, that is what my consulting is for.

The intelligence was already there in Claude Code. What was missing was a harness you could live in, on your own machine, with your data staying yours. That harness is open now.

I'm productizing this substrate as Neutron for operators who want a real agent system without rebuilding it themselves. Separately I take on a small number of consulting engagements per quarter for teams shipping into production. Services →

← All posts