Your assistant works one repo at a time.
You have twelve.

noirdeck is a console on your own machine that runs Claude Code, Codex, Aider or a local Ollama model across every project you have. It queues work that keeps going after you close the laptop, and stops at the point where something would change, so you come back to decisions rather than surprises.

Free for personal use, and free for business use during Early Access. The installed software needs no key to run.

noirdeck · 127.0.0.1:4747local
$ noirdeck serve
→ console on http://127.0.0.1:4747  (loopback only)
→ runtimes: claude, codex, aider, ollama
→ 51 projects · 229 memory notes · 38 skills

· improve/README.md      proposed
· skills/deploy.md       proposed

? 2 proposals waiting. Nothing applied.
  review them at /proposals

Runs the assistants you already pay for

  • Claude Codeskills, memory, transcript resume
  • Codexread-only sandbox supported
  • Aiderbring your own model key
  • Ollamafully local, zero egress
  • Any CLIbring your own runner

What it is

A console for the work,
not a chatbot in a sidebar.

01

It asks first

There is exactly one code path that writes to your assistant configuration, and it runs only when you press approve. That is not a policy. It is a property of the build, covered by a test that fails if anyone widens it.

02

It stays on your machine

The console binds 127.0.0.1 and nothing else. Point it at a local model and no part of your work leaves the building. Choose a hosted model and it says so, every time, before it sends anything.

03

It works with your model

Claude Code, Codex, Aider, Ollama, or a CLI you wrote yourself. The runner is a setting, not an architecture. Hand a session from one model to another without rebuilding the context by hand.

Why not just use the assistant?

Because the terminal only has
one speed setting.

01

It knows more than one repo

A coding assistant starts each session knowing nothing but the folder it was opened in. noirdeck reads your whole fleet and the skills, agents and memory you have already written, so the answer to "which projects need attention" comes from your actual files rather than from a guess.

02

Unattended, and still stopped

Running work overnight in a terminal means approving everything in advance. Here a job runs in staged phases with the quality gates between them executed by code rather than by the model that wrote the work, and anything genuinely uncertain parks with a question instead of guessing.

03

The runner is a setting

Every assistant ships its own client and expects you to live in it. Here Claude Code, Codex, Aider, Ollama and your own CLI are interchangeable, and a live session can be handed from one to another with the context carried across.

All three are claims about the code, and the code ispublic. The first one in particular: there is exactly one function that writes into your assistant configuration, it runs only on approve, and a test fails if anyone widens it.

What it actually does

Eight things, and it does them
without taking the wheel.

Work

Live sessions, any assistant

A real terminal in the browser running Claude Code, Codex, Aider, Ollama or your own CLI. Sessions survive a restart and resume where they stopped. Hand a session from one model to another and it carries the context across, so switching tools does not mean explaining the project again.

Work

Say what you want, in English

Describe the outcome and noirdeck writes the brief: it picks the assistant, asks the handful of questions that actually matter for the job, and turns your answers into a clean instruction. For the common needs of a product, payments, auth, hosting, email, uploads, it already knows what to ask.

Work

Send jobs off and walk away

Queue work to run unattended in staged phases: plan, build, test, review. Quality gates run between phases outside the model, so a phase that fails is caught by code rather than by the thing that wrote it. If it hits something genuinely uncertain it parks the job with a question instead of guessing.

Judgement

A second model, watching

Ask for help mid-session and another model reads the recent output and offers a view. Or leave it watching, and it speaks up on a traceback, a failing test or a non-zero exit. It is read-only and advisory: it can suggest, never change. Everything it sees is scrubbed for credentials first.

Judgement

Quiet improvement, locally

A small model running on your own machine reads your repositories and proposes documentation and comment tidying. It works in a throwaway git worktree, proves the executable code is untouched, runs your tests, and leaves a branch. You merge it or you do not.

Care

Backups you have actually restored

A nightly encrypted backup of your assistant configuration and any repository holding work that exists nowhere else, pushed offsite. It captures uncommitted changes, not just commits, and it tells you how long ago a restore was last verified, because a backup nobody has restored is a guess.

Care

Your notes, kept tidy

Finds duplicate and near-duplicate notes, dead links, oversized files and index drift across your skills and memory. Every fix arrives as a proposal you approve. It never deletes an original, and every applied change can be reverted.

Care

One place that knows the state

Which repositories have unpushed work or a dirty tree, what is waiting for review, what ran overnight and what it decided. The console reads your projects and your session history directly, so it reflects what is true rather than what was last typed into a tracker.

What you actually see

Six screens, and one of them
is a real terminal.

Captured from the running console. The projects and findings in them are invented — a screenshot of the real thing would show somebody's actual repositories.

noirdeck Home screen
HomeWhat changed while you were away, what needs you, and the shortest way back into a repo.
noirdeck Build live screen
Build livePick a project, press one button. A real terminal, any assistant, with options tucked away until you want them.
noirdeck Tasks screen
TasksWork queued to run unattended. A running job can be taken over mid-flight and continued by hand.
noirdeck Review screen
ReviewEvery change noirdeck wants to make to your notes and skills, with a diff. Nothing is applied until you apply it.
noirdeck Credentials screen
CredentialsPasswords and keys sitting in cleartext in your workspace. It never shows you the secret — just where it is.
noirdeck Settings screen
SettingsLocal models set up for you: what this machine can run, and which model suits the work you actually do.

How it looks

Three interface kits,
and they are not colour schemes.

Carbon is square-cornered and dense. Fluent is cool, layered and softly rounded. Claude is warm neutrals and a clay accent. A kit changes type, corner radius, row height and the accent family together, and each one works in dark or light, at either density, at any text size. Every combination is checked before it ships: text has to clear its contrast ratio on every surface, and the accent has to stay perceptually distinct from the alarm colour, so a kit can never make a warning look like ordinary furniture.

The same console screen rendered in the Fluent kit
FluentCool greys, layered depth, four-pixel corners.
The same console screen rendered in the Claude kit
ClaudeWarm neutrals, a clay accent, and the only kit with a serif in it.

What you can ask for

You describe the outcome.
It knows which questions matter.

The gap between “add payments” and a brief an assistant can actually execute is about six questions. noirdeck ships those questions for the ten things every product needs, so you answer them once instead of discovering them in the wrong order.

  • PaymentsProvider, one-off or subscription, what is being bought, what happens after, webhooks.
  • AuthWho signs in, by which method, what roles exist, and which routes are protected.
  • DomainThe name, the DNS host, where it points, apex or www, and whether email lives there.
  • HostingDeploy target, build command, environment variables, health check.
  • DatabaseSchema, migrations, seed data, and how it gets backed up.
  • EmailTransactional sending, templates, the DNS records, and retry behaviour.
  • UploadsWhere files go, what is allowed, previews, and cleaning up orphans.
  • AnalyticsWhich events, which funnels, the product metrics, and privacy.
  • AdminBack office, roles, audit trail, and the support tools you will need at 2am.
  • ReleaseTests, QA gates, environment checks, rollback notes.

Or start from a whole thing, and answer as it goes:

  • A booking page
  • A small website
  • A team tracker
  • A quote calculator
  • A signup sheet
  • A private dashboard

Where the time goes

It is not a faster model.
It is less of your day.

The same assistant does the same work at the same speed. What noirdeck changes is how much of it needs you sitting there, and how often you explain your own project back to it.

Work that happens while you are not there

Queue a job with a deadline and a token budget and it runs in staged phases, plan then build then review, with gates between them that run outside the model. It parks the job with a question rather than guessing. You read the outcome, not the process.

No re-explaining the project

Every background job starts with a written brief of the repository, its conventions and its recent history, assembled from what noirdeck already knows. On this machine that brief is about 670 tokens the assistant does not spend rediscovering.

Six sessions, not one window

Up to six live sessions at once, each in its own repository, each surviving a restart and resuming where it stopped. Handing one from one model to another carries the context across, so switching tools is not a re-briefing.

The review is the fast part

Changes to your notes and skills arrive as proposals with a diff, so the decision is a glance rather than an audit. noirdeck adds files and never edits one it did not write.

No speed multiplier is quoted because the queue runs one job at a time — a queued job takes about as long as the same job typed by hand. The saving is unattended time, not throughput.

Install

One line, and your key.

noirdeck installs from here rather than from a public index, so the download carries your key. Keys are free during Early Access, for personal and for business use, and arrive by email the moment you verify an address. The code is open to read atgithub.com/jasonagnewnz/noirdeck.

curl -fsSL https://noirdeck.dev/install.sh | sh -s -- YOUR-KEY

One line, no admin rights, and it brings its own Python so there is nothing to set up first. Linux and macOS — on Windows, run it inside WSL.Read the script before you pipe it anywhere; it is short on purpose.

Your key is checked when you download, and nowhere else. The installed software never contacts us, which is why it keeps working whether or not we do, and why pointing it at a local model means nothing leaves the machine at all.

To be straight about what the key is for: it is so we know who is running noirdeck while it is this young, and can tell you when something breaks. It is not a lock. The repository above is the same application, building it yourself needs no key, and the licence expressly allows it. We would rather say that here than have you find it out and wonder what else we were quiet about.

Get a keyRead the source

Coffee

It is free. Coffee is not.

noirdeck is free during Early Access and stays free for personal use. If it has saved you an afternoon, you can put something in the tin. No account, no subscription, and nothing about the software changes either way.

Buy me a coffee