What Neuro OS actually is: the open-source AI Management System, layer by layer
One git repo for agents, skills, memory, and connectors. Isolated machines per session. Any model. Work lands through review.
Discuss this post in AI
Send a pre-filled prompt to ChatGPT, Claude, Gemini, or Perplexity — get a summary, ask follow-ups, or compare ideas from this guide.
Neuro OS is the open-source AI Management System — the leading open-source alternative to Claude Cowork and ChatGPT Work. One git repo holds the agents, the skills, the memory and the connector config. Every session runs on its own isolated machine, on its own branch. Any model, your keys. Work lands through a change request. Self-host it, or run it on our cloud. This is the long version of that paragraph: every layer, in the order you meet it.
The category is real. The question is who ends up holding it.
Agents that deliver finished work stopped being a demo and became a product category. Claude Cowork and ChatGPT Work are good products. Both also share a shape: they run inside a model lab, on that lab’s models, on that lab’s cloud, with no self-host option.
Which leaves most companies choosing between a toy and a cage: a single-tenant demo with no isolation, no version history and no permission model, or renting your company back from the lab that keeps your data, your configuration and your model. Neuro OS refuses both. The refusal is not a philosophy — it is six layers, and you can read every one of them.
01 · One git repo that is the company
A Neuro OS project is a git repository, and that repository is the company. neuro.yaml is the Neuro OS layer: the machine a session boots on, the connectors, the triggers, the secret names, and what each agent may touch. Everything past that is markdown.
So the whole company answers to grep. Every agent prompt, every skill, every remembered fact and every grant is a line in a file with an author, a timestamp and a diff, and undo is git revert. neuro init turns any directory into a Neuro OS project; neuro ship checks it compiles, asks for the secrets it is missing, and brings it live.
# neuro.yaml — the Neuro OS layer of the repo.
neuro_version: 2
runtime: opencode
default_agent: neuro
project:
name: acme
opencode:
config_dir: .neuro/opencode
agents:
neuro:
connectors: all
secrets: all
skills: all
neuro_cli: all
memory-reflector:
neuro_cli: [project.cr.open]
triggers:
- slug: memory-reflector
type: cron
agent: memory-reflector
cron: "0 0 3 * * *"
timezone: UTC
prompt: |
Reflect on the last 24 hours of project activity, update
.neuro/memory/, and open one change request.
Every omitted grant resolves to none: leave a connector out of an agent’s list and that agent does not get it.
02 · Every tool your company already runs on
Connect a tool once, for the whole project: 3,000+ apps through their own OAuth screens, or your own APIs through an OpenAPI or Postman spec, a GraphQL endpoint, a remote MCP server, or a bare HTTP base URL.
The credential never travels. The machine carries exactly one project-scoped Neuro OS token; the third-party key is decrypted server-side and attached to the outbound request, so the raw key never reaches the sandbox. Every action gets one of three answers — allow, ask, or block.
03 · Any model. Keep your keys.
The one safe bet in this field is that a better model ships, so Neuro OS is model-agnostic on purpose. Pick the model per agent, per session or per message. Bring your own API key from any major provider, or use ours. Or point it at your own model behind your own URL — anything OpenAI-compatible. When you switch, nothing above this layer moves.
04 · The part that turns a model into an agent
A model on its own answers a question. A harness gives it planning, tool use, and multi-step runs it actually finishes. Neuro OS runs OpenCode as that harness. A skill is a directory with a SKILL.md at its root: how your company does one specific job, written once.
05 · Every session gets its own computer
Start a session and its own isolated Linux machine boots. It clones the project repo into /workspace, cuts a branch named after the session, and starts the harness. The agent gets the whole machine — a shell, a package manager, a filesystem, the network — and nothing runs on your laptop.
The machine is disposable, so a bad install or a wiped directory goes away with it and only what the agent commits survives. Run one, or run thousands at once, each a different version of the company working at the same time.
06 · One place to start it, one gate to land it
The web app, Slack, mobile, the CLI and the API all start the same session — same object, same branch, same audit row. Then the work comes back the one way it is allowed to: a change request you read as a diff before anything reaches main.
Merging one is a capability of its own, and it is default-deny for agents. An agent gets it only if an admin grants project.cr.merge in neuro.yaml.
What it does on an ordinary Tuesday
- Sales — pulls a lead list, enriches every account and writes a sequence per lead. Put an ask on the send step and it stops with you before anything goes out.
- Engineering — sweeps the day’s errors, groups them, reproduces the worst one on its own machine, patches it, and opens a change request against
main. - Finance — reconciles the ledger against the bank, chases the receipts that are missing, attaches them, and closes the month with the variance explained.
- Marketing — tracks the queries you care about, finds the pages losing ground, rewrites them against the brief, and opens each rewrite as a change request.
- Data — queries the warehouse on a schedule, checks the result against last week, draws the chart, and posts the whole thing to Slack while you are asleep.
Every one of those is a job, not a chat. What lands is a file — a diff, a spreadsheet, a draft, a report — with a branch behind it and a person in front of it.
Read every line, then run it on your own box
All of it is open source. Clone the repo, read what you are trusting, fork it if you want it different. Then run that same product on hardware you control.
# bring the whole stack up on your own box
$ neuro self-host start
# point the CLI at your stack
$ neuro hosts use selfhost
→ Active host is now selfhost
# same commands, back on the managed cloud
$ neuro hosts use cloud
→ Active host is now cloud
Side by side
| Dimension | Claude Cowork · ChatGPT Work | Neuro OS |
|---|---|---|
| Where your configuration lives | Inside the vendor’s product | A git repo you own |
| Version history on that configuration | Not published | git diff on every agent, skill and grant |
| Which models it runs | The vendor’s own | Any model — your keys or your subscription |
| Where it runs | The vendor’s cloud; no self-host | Managed cloud, your VPC, or your own on-prem network |
| Reading the source | Closed | Open source — clone it and read it |
| Isolation per unit of work | Not published | One isolated machine and one branch per session |
| How work lands | Inside the product | A change request you read as a diff first |
| Getting started | A Claude Max plan, or a paid metered ChatGPT plan | Free to start, free to self-host |
When to pick which
Choose a model lab’s agent if
you want finished work today with nothing to run, you are happy on that lab’s models and that lab’s cloud, and your company’s configuration living inside their product is a trade you are content to make.
Choose Neuro OS if
you want the same finished work with the company underneath it staying yours — agents, skills, memory and connector config as files in one repo you own, any model on your own keys, one isolated machine per session, and work that lands through review.
The architecture argument behind all of it is in AGI-ready architecture; the direct comparisons are Claude Cowork and compiled workflow platforms.
Run your whole company from one repo you own.
Start with one job, connect the tools it needs, and reach it from Slack, the web or the CLI. Free to start, free to self-host.