Nyx

Why "Nyx"?

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.

Bring your dreams to life. Even if you don't code.

Here's the part Ethan wants you to know: you can use this yourself. You don't have to be a programmer. You describe what you want — in plain English, the way you'd describe it to a friend — and Nyx figures out the rest.

Ethan barely codes anymore. He describes. He says things like "build a page that does X" or "fix the thing that crashed last night", and Nyx does the actual writing of the code. He just reads the result and approves the parts that matter.

That means anyone with an idea can build it, as long as they can describe it clearly. A spreadsheet that tracks your kid's soccer schedule and texts you reminders. A website that takes your photography portfolio and lets people order prints. A little bot that watches eBay for a specific guitar and pings you when one shows up under $400. None of that requires you to learn JavaScript anymore. It requires you to know what you want.

What it looks like

Two interfaces, depending on what you're doing.

The dashboard

This is the everyday view. You see your agents on the left, what they're working on in the middle, a chat with the manager on the right. Tap the + button to start a new agent.

The mac-window chrome at the top tells you which mode you're in. The green "live" dot in the upper-right means Nyx is connected and listening. The chat box on the right is where you type goals.

The terminal (for when something goes wrong)

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.

First: what is an "AI agent"?

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.

What Nyx actually is

Nyx is an orchestrator — a piece of software that runs and coordinates many AI agents together. You give it a goal in plain English. A "Manager" agent inside Nyx reads your goal, breaks it into smaller tasks, and dispatches each task to a "Worker" agent. Multiple workers can run at the same time. Everything is visible to you on a dashboard.

The key piece is what sits in the middle: a 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 + a configurable safety gate + a permanent record of every safety decision — is what makes Nyx different from the tools listed below.

The flow, step by step

1. You give it a goal

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.

2. The Manager agent clarifies, then plans

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.

3. Worker agents spawn and do the work

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.

4. The Push Gate intercepts every risky tool call

This is the safety-critical piece. Three layers, in order:

• Tier 1 — hardcoded floor. A list baked into the code itself, not in any config file. Things like ~/.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.
• Tier 2 — operator blacklist. A file at ~/.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.
• Default — allow. Anything not in tier 1 or tier 2 runs without interruption. The point is to let the agent move fast on safe work, and pause only on the things that actually have blast radius.

5. You see the gate prompt and decide

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.

6. Everything is recorded into the audit log

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.

7. The whole thing is visible live

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.

The picture version

What separates Nyx from other AI tools

There are a lot of AI coding tools right now. The big ones, in rough order of how Nyx compares against them:

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.

What's built so far

Everything below is finished, tested, and working today. 130 automated tests check that nothing is broken.

• OK
  The basic system runs end to end Type a goal, watch Claude actually do the work, see the result. Verified by a real session: a worker read the project's own status doc and wrote a coherent self-introduction back. No simulation, no fake harness, real Claude through the real pipeline.
• OK
  Cursor-style dashboard Dark mac-window interface. Multiple agents visible as tabs. Live worker output in real time. Embedded preview window for any dev server a worker spins up. Layout you can adjust on the fly.
• OK
  Three-tier safety gate Hardcoded floor (cannot be overridden, even by a malicious config), operator blacklist (hot-reloaded YAML), and best-effort command normalization (catches common obfuscation like base64-encoded payloads). The "cannot be overridden" property is enforced by an automated test.
• OK
  Universal audit log Every gate decision goes into a SQLite table with a timestamp, the matched rule, which tier caught it, and who decided. Queryable via HTTP. The "did the gate work" data the 30-night trial will measure.
• OK
  Two-phase Manager prompt Manager clarifies first (up to three questions), then goes silent and runs to completion. Either it asks a real question or it does the work. No filler questions just to seem helpful.
• OK
  A "researcher" sub-tool When a worker needs to look something up (how does this library work, what are people doing for this problem) it can dispatch a short-lived research agent that does the web fetching and returns a tight summary. Keeps the main worker focused on the task instead of getting lost reading docs.
• OK
  Public landing site This site. Hosted on Cloudflare Pages. Includes the technical overview, the live project status, and this plain-English explainer. Auto-updates when Ethan ships something.
• OK
  Audit log viewer on the dashboard A drawer on the right side of the dashboard that shows every safety-gate decision in real time. Filter by type. Click any entry to see the full details. Auto-refreshes every 5 seconds. Replaces having to type curl commands to inspect the log.
• OK
  Smart database upgrades When the data structure changes (a new column gets added, etc.), the system now upgrades the database automatically and safely. No more "rename the old file and let it rebuild" friction. Each upgrade runs in a transaction so partial failures roll back cleanly.
• OK
  Auto-respond to broken things When FBM Sniper (or anything monitored) sends an error, Nyx automatically spawns an investigator agent that reads the error context, looks at the relevant code, and writes up what it thinks the cause is. It does not commit or deploy anything; Ethan still approves any actual fix. This is the main reason Ethan built this in the first place.
• OK
  Knows each project's rules When a worker enters a project folder, it automatically loads any CLAUDE.md notes Ethan has written for that project (coding conventions, things to watch for, special quirks). So a worker working on FBM Sniper sees FBM rules; a worker working on Nyx sees Nyx rules. No need to repeat instructions every time.
• OK
  Scheduled jobs Nyx can now run on a schedule. "Every morning at 8am, check if FBM Sniper deployed cleanly." "Every hour, scan for new error reports." When a scheduled time hits, an agent spawns automatically and goes to work.
• OK
  Memory that lasts (the Hermes-inspired part) Nyx now keeps a small bounded notebook (MEMORY.md + USER.md) that every worker reads when it starts. Capped on purpose so it stays curated. Once a memory is in there, every future worker knows it without being told. Fixes the "every session starts from scratch" problem.
• OK
  Per-project memory In addition to the global memory, each project gets its own .orchestrator/PROJECT.md file. When a worker enters that project, it sees only that project's notes. So FBM Sniper rules don't pollute when working on something else.
• OK
  A skills library Nyx can now save reusable recipes under ~/.orchestrator/skills/. Each one is a markdown file describing how to do something ("deploy FBM Pro", "investigate a memory leak"). Future workers see the list of available skills and can call any of them when relevant. Stops Nyx from re-figuring-out-from-scratch every time.
• OK
  Phone control via Discord Ethan can now DM the Nyx bot from his phone. Each Discord user gets their own persistent agent. Long replies get split into multiple Discord messages automatically. Plus a Cloudflare Tunnel script that gives the dashboard a public URL on demand, so it's also viewable from anywhere.
• OK
  A reviewer that checks the work When a worker finishes something, a second AI (the Critic) can read what they did and either approve it, ask for changes, or abstain. The verdict is structured (approve / revise / abstain) so the moderator can decide what to do next without guessing.
• OK
  A 24/7 watchdog Always-on monitor that scans every 5 minutes for workers that have been running too long (over 15 minutes by default). When it finds one, it logs a warning and records it in the audit log. Catches stuck workers and runaway loops before they burn hours of API time.

What's coming next

In order, smallest first. This is the list Nyx is going to work through, in many cases by building itself.

• 10
  A reviewer that can SEE For visual work, the reviewer takes screenshots, compares to what was asked for, and tells the worker to keep iterating until it looks right. Needs the Playwright browser plugin wired in first.
• 12+
  Parallel branches + safety refinements Workers editing different versions of the project simultaneously without conflict. A queue for reviewing what Nyx has learned. Kill switches for any skill that turns out bad. Daily spending caps so the system can't burn money overnight.

Why Ethan is actually building this

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.

If you want to dig deeper