Works while you sleep.
This is a no-jargon explanation of the software Ethan has been building. If you have heard him say "Nyx" or "AI agent" and wanted to know what that actually means, this page is for you. It is a little technical, but not painfully so.
Nyx (pronounced niks) is the Greek goddess of the night. In the old myths she is one of the very first beings, born from Chaos itself. She rules the dark hours. Even Zeus is supposed to have been afraid of her. She is the mother of Hypnos (sleep) and most of the other night-things.
The whole point of this software is that it works the night shift. Ethan's other software (a Facebook Marketplace bot called FBM Sniper) breaks at the worst possible times: 3am, a weekend, while he is at the gym. Nyx is meant to watch over it all, fix the easy stuff on its own, and only wake him up if there is something he genuinely needs to decide.
So: Nyx works while you sleep. Greek goddess of the night, for a piece of software that runs the night shift on your other software. The name also pairs with Atlas, the brand Ethan uses for the cloud version of FBM Sniper — both are Greek, both are primordial figures, both belong in the same family of products.
You describe what you want -- in plain English, the way you'd describe it to a colleague -- and Nyx figures out the rest. Teams that move fast don't want to babysit every agent decision. They want guardrails they trust and a clear audit trail when something unexpected happens.
The shift is real. Developers describe rather than write. "Build a page that does X", "fix the thing that crashed last night", "add this new platform to the app" -- Nyx does the actual implementation. Humans read the result and approve the parts that matter. The team's judgment stays in the loop; the repetitive execution moves to the agent.
That changes what "productivity" looks like. A feature that would take a sprint of careful coding takes 30 minutes of Nyx running while someone watches. A 3am crash gets diagnosed automatically. A new integration gets scaffolded across 13 files without a human writing a single line. The team still owns the outcome -- they just stop being the bottleneck.
You bring the direction. Nyx handles the execution. The hard part has always been knowing what you actually want built. That part stays yours. The "make the computer do it" part -- Nyx handles that, safely, with a full audit trail.
Three interfaces, depending on where you are.
A Claude-Code-style terminal interface. Conversation in the main pane, a live queue and worker grid on the right, status bar at the bottom. Type a goal in the chat, hit enter, watch a worker pick it up. Slash commands handle the rest: /queue focuses the queue panel, /dispatch runs a specific item, /sleep on tells Nyx to keep working overnight, /remote-control prints the URL if you want to attach from a phone.
Hit localhost:8787/m from your phone (over Tailscale or Cloudflare Tunnel). You get a one-column dashboard with live worker count, the pending queue, the last ten things that shipped, and a big text box at the top with a mic button. Tap mic, say "add a task to fix the Discord rate limit," Nyx enriches the title into a worker brief and queues it. No claude.ai/code session attachment required.
The Cursor-style web dashboard at localhost:5173 still exists for the cases where you want a multi-tab view of long-running workers, including their embedded dev-server previews. The terminal log lines below are the receipts:
Most of the time you won't look at this. But when something breaks at 3am, this is where the receipts are. Color-coded log lines, one per thing that happened, with the agent ID in brackets so you can follow a single agent through.
Each colored row is one event. agent = something changed about an agent. worker = something happened inside a worker. gate = the safety gate intercepted something. dev = a worker started up a website. The bracketed code is the agent's short ID, so you can follow one agent through all its events.
You have probably used ChatGPT or Claude. You type a question, the AI types back an answer. That is a chatbot. It does one thing per turn, then stops.
An AI agent is the next step up. Instead of answering one question at a time, it works on a goal across many steps. You give it something like "figure out why the deploy is broken and fix it", and it does the work: reads files, runs commands, edits code, runs tests, tries again if something fails, reports back when done. Between you giving it the goal and it telling you it is finished, it might have made fifty separate decisions on its own.
Agents are useful because they can finish whole tasks without supervision. They are dangerous for the same reason: the longer they run without checking in, the more time they have to do something you did not actually want. A bad agent can delete files, push broken code, or burn through hundreds of dollars in API charges overnight.
The interesting design question with agents is not "can we make them do stuff" (we already can). It is "can we make them do stuff without doing the things we did not want them to do."
That is what Nyx is about.
Nyx is an orchestrator — a piece of software that runs and coordinates many AI agents together. You give it a goal in plain English. The Moderator (the brain, a long-lived server on your machine) drops the goal into a queue, then an autopilot picks it up and dispatches a Worker agent to actually do the work. Multiple workers can run at the same time. Everything is visible to you in the TUI or on your phone.
The Moderator does more than just dispatching. It runs an auto-merge daemon that integrates finished work into your main branch when tests pass, an auto-sync that closes the queue items as their branches land, a watchdog that notices stuck workers, and a self-iterator that diagnoses why a worker got stuck and patches Nyx's own code. The loop is mostly closed: work flows in, work flows out, and the operator only touches the things that genuinely need judgment.
A new layer arrived this week: hybrid routing. The autopilot used to spawn an LLM worker for every queue item. After a spike where Nyx burned $30 of Opus to do a fifteen-line git loop, the system grew a router: shape-known work (cherry-pick, fanout, rebase, cleanup) routes to deterministic code with zero tokens; genuinely creative work still goes through an LLM. The expensive engine is reserved for what actually needs it.
The next key piece is the safety gate that every worker has to pass through whenever it wants to do anything risky. Routine stuff (read a file, run a test, search code) flies through with no friction. Risky stuff (push code to production, delete data, charge a card, edit a secret file) pauses and pings your phone. You see exactly what it wants to do, in plain text, and you tap approve or deny.
Every single decision the gate makes gets recorded into an audit log. After a month of use, you can scroll through that log and see exactly what the gate caught, what it let through, and whether your trust was well placed.
That combination — autonomous worker agents + an autopilot that drains a queue + a hybrid runtime (LLM where you need creativity, code where you don't) + a configurable safety gate + a permanent record of every safety decision — is what makes Nyx different from the tools listed below.
Typed into the dashboard, sent from Discord (planned), or triggered by something like a CI failure (planned). Plain English. You do not specify files or commands.
The Manager reads your goal, looks at the project, and asks any clarifying questions it needs — but it asks them upfront, in a single message, not one at a time. If your goal is clear, it skips clarification entirely and goes straight to work. This is enforced by a system prompt called the "two-phase Moderator prompt" that the Manager loads at startup.
a project manager at a design studio. They take the client's vague brief, ask a few sharp questions upfront, then disappear and don't bother the client again until there's something real to show. Not every decision goes back to the client. Only the ones that actually need their judgment.
The Manager hands tasks to Workers. Each Worker is its own copy of Claude (the AI model) running as a separate process. Workers can run several in parallel — Nyx can run up to 8 at once. Each one streams its output (text + tool calls) back to the dashboard in real time.
Workers see a small allowed-tool set by default: Read, Grep, Glob, WebSearch, WebFetch all run freely. Anything that modifies the system — Bash, Write, Edit, MCP server calls — has to pass through the gate first.
This is the safety-critical piece. Three layers, in order:
~/.ssh, ~/.aws/credentials, sudo, rm -rf /, and curl ... | sh are always blocked regardless of what Ethan or anyone else writes in the config. There is a test that proves this: even if you load an empty or malicious config that tries to allow ~/.ssh, the floor still blocks it.
~/.orchestrator/blacklist.yml where Ethan lists additional patterns that need approval. git push always asks. fly deploy always asks. Anything touching **/.env* always asks. This list is hot-reloaded, so editing the file updates the rules instantly.
When something hits the gate, an amber bar appears at the bottom of the dashboard (or a notification on your phone). It shows the exact command, which rule matched, which layer caught it, and approve/deny buttons. No "recommended action" — the gate refuses to recommend, on purpose, because if the AI is telling you what to do then you have just replaced your judgment with the AI's judgment, which defeats the point.
Every gate decision — approved, denied, auto-allowed, auto-denied — gets written to a permanent log. You can query it with one HTTP request, or scroll through it on the dashboard (coming soon). The intent is that after 30 nights of running Nyx against the FBM Sniper bot, Ethan can review the audit log to learn: was the gate strict enough? Too strict? What did it miss that it should have caught?
That data is what tells you whether to trust the system more, or pull it back.
A dashboard at localhost:5173 shows every active worker as a tab. You see what each one is doing in real time, including any websites they start up (those appear in an embedded preview window). When a worker is done, its tab shows the final result and you can close it.
There are a lot of AI coding tools right now. The big ones, in rough order of how Nyx compares against them:
| Tool | What it does | How Nyx differs |
|---|---|---|
| Cursor | A code editor with an AI built in. You write code, the AI suggests changes, you accept or reject. | Single agent, you are the loop. Nyx runs multiple agents that work without you in the loop, and pauses only at the safety gate. |
| Devin | A fully autonomous AI engineer. You give it a task, it runs on its own and comes back later. | Devin is famous for going off the rails (deploys broken code, burns hours of API time on the wrong path). Nyx is autonomous like Devin but adds the safety gate so it cannot do irreversible things without your sign-off. |
| OpenHands | An open-source autonomous agent platform. Similar idea to Devin, more transparent. | No safety gate. No audit log. Nyx has both, and a smaller, more focused feature set so each piece can actually be trusted. |
| Aider | Command-line AI that edits one file at a time with your approval. | Aider is the opposite extreme: you approve every single edit. Nyx is "approve only the risky stuff", which is faster while still safe. |
| Hermes Agent | An open-source agent with very good memory (it actually remembers things across sessions). | Hermes' memory design is excellent — Nyx is going to copy it. But Hermes has no safety gate and no way to handle multiple repos at once. Nyx solves both. |
| Nyx | Autonomous, multi-agent, safe by design, focused on running unattended for hours or days at a time. | The combination is what is new. None of the others have all four (autonomy, multi-agent, configurable safety gate, audit trail). |
The honest take: nobody is trying to build the longest feature list. The win is being the only tool where a developer genuinely closes the laptop and trusts it. That trust is earned by the safety gate + the audit log, not by being the smartest or the fastest.
Everything below is finished, tested, and working today. 670+ automated tests across 88 test files check that nothing is broken. As of 2026-05-30, Nyx is approximately 31k lines of code (19k source + 12k tests) across 264 commits to main, with Nyx itself having written the majority of that. Today's additions include GET /status/pulse (token-free SQL health snapshot, auto-broadcasts every 20min on SSE) and GET /reflection/digest (rule-based weekly digest, one haiku call per digest).
The classics still apply — three-tier safety gate, universal audit log, two-phase Moderator prompt, researcher sub-tool, knows-each-project's-CLAUDE.md, scheduled jobs, Hermes-style memory, per-project PROJECT.md, skills library, Discord phone control, Critic reviewer, watchdog, Cloudflare-Pages public landing site. All still there, all still tested. Below is the original list, kept for reference:
Earlier shipments (still live):
In order, smallest first. The autopilot is now picking these off the queue as it has slots — most can be built by Nyx itself, with Ethan reviewing each commit.
Ethan runs a Facebook Marketplace bot called FBM Sniper. It is the kind of software that breaks at 3am on a weekend while he is at the gym. When that happens, the current routine is: drop everything, drive home, debug, deploy a fix. Often before he even gets the chance to notice, customers are already complaining.
Nyx is meant to be his on-call engineer. The bot breaks → Nyx gets a webhook → a worker investigates → the worker proposes a fix → if it is something safe (revert to last working version, restart a process) Nyx does it automatically and writes it in the log; if it is something risky (push to production, change a database) Nyx pauses and pings Ethan.
Ethan wakes up, sees a clean log of what Nyx did overnight, approves anything still waiting, and goes about his day.
That is the user-facing case. There is also a quieter ambition: Nyx eventually building itself. The roadmap above is mostly going to be built by Nyx running its own self-iteration loop, with Ethan reviewing each commit. That is the test of whether the trust model actually works.