Cockpit

Cockpit is OCTYN's own internal tool. It is in build, it is used while it is being built, and the picture on this page is the working prototype with sample data in it rather than a design.

1. The situation

OCTYN runs around eighteen AI coding sessions at once across twenty-one codebases, as recorded on the work page on 2026-09-14. Every tool for running those sessions is built for running one. You get a terminal, you get a conversation, and you get no answer at all to the only question that matters when there are eighteen of them: which one is stopped, waiting for a person, right now.

The failure is not dramatic. A session asks a question and then sits there. Nobody notices, because noticing means checking eighteen windows, and the cost is not a crash, it is an hour of nothing happening in a place you were not looking.

2. Why it was hard

The state a session is in is not a status field anybody publishes. It has to be inferred from output, and the categories that matter are not the ones a process reports. A session that is running and a session that has finished and is idle look identical from the outside. A session that has asked a question and a session that has hit an error both look like a session that has stopped printing.

The second problem is that a dashboard which summarises a terminal is useless. The moment you need to act, you need the real thing, with its colours and its control characters intact, and a pretty summary means switching tools at exactly the wrong moment.

The third is that this has to be cheap. A monitor that costs as much attention as the thing it monitors has not helped.

3. What was built

A local daemon that holds every session, and one screen over it. The status bar in the prototype capture shows the daemon bound to 127.0.0.1, which is the whole security model: it runs on the machine the sessions run on and has no remote surface to attack.

The screen is three columns. On the left, projects, each one showing how many of its sessions are running, how many exist and how many are waiting. In the middle, the session itself, in a real terminal rather than a rendering of one. On the right, the rail that is actually the product: one session in focus with why it stopped, then everything else that is waiting, then everything still running, then recent activity.

The vocabulary is the part that took the thinking. A waiting session is tagged with what it is waiting for, and those tags are distinct: asked, meaning it wants an answer, and review, meaning it has finished something and wants a person to look. An error is a third thing again and takes the focus slot. The footer reduces the whole fleet to three numbers, and the only one that is urgent is the count of sessions that need you.

4. What it does under load

Not measured. There is no timing instrumentation in the prototype, so there is no figure for how long a session sits waiting before it is picked up, which is the number this tool exists to reduce and the obvious thing to record first.

What can be said with a date, from the capture taken on 2026-09-14: the prototype holds a fleet of seven sessions across four projects in its sample state, with two running and four needing a person. The terminal pane in that capture is a mock, labelled as one in the capture itself, with the real one being a full terminal emulator. The load question for this design is not sessions, it is bytes: a fleet of terminals all streaming at once is a lot of output to hold, and nothing here has been measured against that yet.

5. What happens when it breaks

The honest answer, and the reason this is a write-up of something in build rather than something finished: the failure modes are understood and not all of them are handled.

The daemon holding every session is the single point of failure by design. If it dies, the sessions themselves are what matter and they are separate processes, so the work survives and the view over it is what is lost. That is the right way round, and it is the reason the daemon holds sessions rather than owning them.

A stale status is the failure that costs the most, because it is silent. A session shown as running when it has actually stopped and asked a question is worse than no dashboard at all: it is a dashboard that answers the question wrongly and gets believed. Inference from output is inherently a guess, and there is no confidence signal in the prototype yet.

Being local removes a whole class of problems and adds one. Nothing is exposed and nothing needs auth, and there is also no way to see the fleet from a phone, which is where the person is when a session has been waiting for twenty minutes.

6. Who maintains it, and what that costs in attention

The person whose sessions it is watching, which is the correct incentive: a monitoring tool maintained by somebody who does not depend on it goes stale without anyone noticing.

Its steady-state cost is unusual in that it is the one internal tool where neglect is visible immediately. If the status inference drifts, the person using it finds out within a day, because a session they were told was busy turns out to have been waiting since the morning.

7. What changes when requirements change in six months

Configuration, no code: which projects are in the fleet.

A small code change: another waiting category, another column in the rail, another key to jump between sessions. The vocabulary of session states is data, and adding a state is adding a row to it.

A larger code change: supporting a second kind of session. Everything here assumes one shape of agent process, and a second one means the state inference stops being a single implementation.

A rebuild: making it remote. Local-only is not a shortcut taken here, it is the reason the tool needs no authentication and no encryption and no account. Putting the fleet on a phone means all three of those, and it is a different product.

8. What we would do differently

Record the waiting time from the first commit. The entire argument for this tool is that sessions sit idle unnoticed, and the prototype cannot yet show that number going down.

Treat status inference as a first-class problem rather than as plumbing. It is the thing most likely to be quietly wrong, and it is currently the least defended part of the design.

And write down what a session state means before drawing the screen. The tags in the rail are the good part of this tool, and they were arrived at by drawing it twice.