Introduction

Nautelle is a self-hosted control plane for fleets of AI coding agents: Claude Code and Codex, across many repositories and more than one machine. You describe work in one sentence. Nautelle interviews you, turns the answer into cards, can draw a design for them and runs a dedicated agent per card on your own machines. Each agent opens a pull request and fixes its own CI. You see every agent, every pull request and every dollar of API-equivalent cost in one web app, from the browser or from Telegram.

It is built to drive the Code Sentinel orchestrator, a Claude Code plugin that turns GitHub issues into merged pull requests with parallel workers. Nautelle is open source under the MIT license: https://github.com/AndreyBegma/Nautelle.

The problem

Run Code Sentinel unattended for a while and your fleet becomes a pile of tmux sessions, git worktrees, markdown files inside .git and GitHub labels, per project and per machine. Three things go missing:

• Nothing shows the whole fleet. To learn what is running, on which model, what each slot last reported and what merged today, you run tmux ls, read markdown inside .git and call gh pr list, project by project.
• Nothing remembers. The orchestrator's watch stream goes to stdout, and history is scattered over daily board folders. Tokens and cost are not recorded anywhere.
• It is bound to the machine. A fleet on a server can only be followed from somewhere else one session at a time.

Nautelle answers those with one screen per project, a recorded history of every round, slot and run (with tokens and cost), and controls that work from any browser.

Who it is for

A developer or a small team that runs coding agents unattended on their own machines and wants to watch them, steer them and keep their spend in check from one place.

There are three roles. An admin runs fleets, pairs machines, approves merges and new users, and controls spend. An operator watches and steers the projects they are assigned to and runs skills. A viewer sees progress, history and cost.

How work flows

There are two lanes, and one project can use both.

The Board lane is for work you describe yourself:

idea ─▶ New work intake ─▶ cards / split / stack ─▶ design (optional)
     ─▶ Run ─▶ draft PR ─▶ CI watched, up to 3 fix rounds ─▶ auto-merge or Accept

The Fleet lane is for GitHub issues and the Code Sentinel orchestrator:

cs-spec ─▶ cs:ready issue ─▶ orchestrator ─▶ slots ─▶ approval ─▶ merge

Slots from the Fleet lane are mirrored onto the Board, so one place shows everything in flight. Start with New work intake for the Board lane and with Fleet for the other.

How it fits together

Nautelle has three moving parts. You host the first, install the second on each machine with repositories, and install the third into Claude Code.

 Browser ──HTTPS──▶ web (Next.js) ──/api──▶ API (NestJS) ──▶ PostgreSQL, Redis
                                                ▲
                                                │ outbound WebSocket, opened by the runner
                                                │
 Agent machine:  nautelle-runner ──▶ tmux, git worktrees, gh, claude / codex CLIs
                                        └─ Code Sentinel orchestrator and workers

The control plane

The API, the web app, PostgreSQL and Redis (Redis only holds cron timers). It stores everything and serves the UI, and it never reads a project's files itself. Everything that touches a disk goes through a runner. You run it with Docker Compose on a server you own, or from source for local use.

The runner

nautelle-runner is a single binary, one per machine that holds repositories. It dials out to the API over a WebSocket, so the agent machine needs no open port. It observes tmux sessions, worktrees, orchestrator boards, transcripts and pull requests, and sends that up as events. Going down, it accepts only a typed allowlist of commands (start the orchestrator, stop a slot, run a skill and so on), never a shell string.

The Code Sentinel orchestrator

The orchestrator is the /code-sentinel:orchestrator skill of the Code Sentinel plugin. It reads GitHub issues that carry the ready label (cs:ready by default), dispatches one worker per slot into its own git worktree and tmux session, and merges green pull requests. Nautelle starts and stops it and reads what it writes. It does not reimplement its scheduling, and it never picks which issue a slot works on.

What Nautelle is not

• Not a billing system. Cost in Nautelle is API-equivalent cost: what the recorded tokens would cost at public API prices, even when you run on a subscription. Nothing is charged, and Nautelle never handles your Anthropic or OpenAI keys.
• Not a replacement for GitHub. GitHub issues are the fleet's queue, and pull requests are where code is reviewed. Board cards are Nautelle's own and are not issues.
• Not a remote shell. The runner executes a fixed list of typed commands. Admins can attach to an agent's terminal, and every attach is audited.
• Not a prompt tool. There is no prompt management, eval suite or dataset store. Sessions are stored as metadata (models, token counts, tool names, durations), never prompt or response text.
• Not a SaaS. There is no hosted Nautelle. You run every part, and no installation reports anything back to the project.

Project status

Nautelle is young: the first commit is from October 2026. The web app and API are at 0.0.1, the runner at 0.1.0. Milestones M1 (see the fleet), M2 (steer it) and M3 (automate it) are built, and so is the Board pipeline: intake, stacks, the design stage, cards that ship themselves, Steward, Token Saver, coding rules, the Telegram Mini App and the assistant. See the roadmap for dates.

Next steps