Project Cockpit — Control Plane for an AI Fleet

A control plane that lets one person run a small fleet of computers as a single, dependable AI service: one endpoint for chat, vision, speech and images, with each piece of work sent to the machine best able to do it.

Running several machines as one dependable AI service

95,270lines of code
247files
444commits
110automated checks
1data models
Project Cockpit — Control Plane for an AI Fleet: BroadcastProject Cockpit — Control Plane for an AI Fleet: AgentsProject Cockpit — Control Plane for an AI Fleet: Remote  (1)Project Cockpit — Control Plane for an AI Fleet: Project Cockpit

The hard part

Local AI on a single PC reaches its limit quickly: one graphics card, one model loaded at a time, and every application wired to its own port. Meanwhile several capable machines sat idle while one did all the work. More machines only help if nobody has to remember which one does what, so the fleet had to look like a single service from the outside.

One endpoint sits in front of everything, and each request goes to whichever machine is fastest or already has the right model loaded. A graphics card that runs short of memory raises no error; it spills into system memory and slows to a third of its speed, so an arbiter refuses any load that would cause that. Idle models are put away to free memory and brought back when a request needs them. Every machine reports its vital signs every 30 seconds, so the question of whether more hardware is needed is answered from data rather than impressions.

427 commits on 62 working days since 2026-05-31; a transcription cut from 9.3 s to 1.9 s by keeping its model loaded; a batch finished 4.1 times faster when spread across idle machines.

What the measurements mean

Only what is unusual for this project. Every sentence names the field it came from; nothing here is asserted that cannot be checked against the data.

How it works

It began with a practical problem. I was running dozens of AI coding agents at once, and a wall of terminal windows made it hard to see which of them needed me. So I wrote a terminal that sorts each session's output into approvals, questions and errors, turning the wall into a queue. That tool is still here, but it is now one small part of a larger system. The larger system is a gateway. Applications talk to one standard endpoint (the same interface OpenAI uses), and the gateway decides which machine should answer. Quick requests go to the fastest machine that is good enough; harder ones go to the most capable. A machine that already has the right model loaded is preferred, and the local network is always tried before the remote tunnel, which is more than a hundred times slower. Two measurements show why this matters. Keeping the speech model loaded where it runs cut a transcription from 9.3 seconds to 1.9. A ten-minute recording split across six machines finished in 18.8 seconds, where a single machine took more than two minutes and quietly returned only 14% of the text. Most of the remaining work is about failing loudly rather than quietly. A graphics card that runs short of memory raises no error; it simply slows to a third of its speed, so the scheduler refuses any load that would cause that. Idle models are put away to free memory and brought back when they are needed. Each worker reports exactly which version of the code it is running, because I once had five machines serving stale code while every health check passed. And every machine records its load, memory and temperature every 30 seconds, so decisions about capacity come from evidence rather than impressions.

What kind of engineering this is

Six signals counted from the source: files that run models locally, that act without being asked each time, that check their own output, that survive failure, that touch parsers and protocols, and that were measured then improved. Every axis carries its file count.

Depth profileDepth signals: Local inference 54 files, Autonomy 21 files, Verification 42 files, Resilience 143 files, Low level 37 files, Iteration 0 filesLocal inference54 filesAutonomy21 filesVerification42 filesResilience143 filesLow level37 filesIteration0 files

What it is written in

Share of code bytes. Vendored bundles and generated output are set aside before this is computed, which is why it differs from a simple file count.

Language mixPython 92.5%, PowerShell 4.7%, Shell 1.5%, HTML 1%, Batchfile 0.3%Python 92.5%

What stands out

Capabilities

Grade

Every check names the field it measured. Checks that cannot apply are excluded, never counted as failures.

B
85.7% over 19 of 19 checks100% coverage

Not met

Architecture

Directories carrying real modules, largest first.

Data model

Typed structures and tables found in the source.

Vulnerable dependencies

2 declared dependencies match a published advisory. Checked offline against the OSV database; only pinned versions can be checked, so anything unpinned here is unknown rather than clean.

Vocabulary

Parsed 193 of 193 Python file(s). Counts are exact; the names below are a sample.

1,918functions
1,537methods
232classes
191documented modules

Classes

Functions

Command line

Depth

Signals counted from the code, not asserted.

442 commits across 69 separate working days over 5.4 months, 50 of them revising existing behaviour

Built from scratch

Closes its own loop

Proves itself

Survives failure

Local inference

Systems

Distributed systems

Working within limits

Environment engineering

Operating-system internals

GPU & memory management

Languages

Built with

Recurring themes in the commit history

Evidence

Taken from the code itself: a module docstring or the opening of the README.

Application entry point. Initialises configuration, logging, and launches the main window. Includes global crash handler that writes tracebacks to logs/crashes/.

At a glance

Status
active
Primary language
Python
First commit
2026-05-31
Last activity
2026-11-11
Domain
Desktop applications
Agent docs
CLAUDE.md, AGENTS.md, agent.md, PROJECT_KNOWLEDGE.md, .claude