Our own · CockpitIn build
Cockpit.
One screen for every coding session OCTYN has open at once, built because the hard part stopped being the work and became knowing which session was waiting on a person.
For your engineering teamInside: session monitor · waiting-on-a-person alerts · one screen
The screen, as it is today.
In build. This is the working prototype in its own colours, with sample data in it. The terminal pane is a mock, labelled as one in the capture.
In shortOne screen for every coding session open at once, built to answer the one question that matters when there are eighteen: which session is waiting on a person.
- Every session, grouped by project.Each project counts its sessions: running, total and waiting.Read how
- The session is a real terminal.In this capture the pane is a mock, and says so.Read how
- One session in focus, with why it stopped.An error takes this slot.Read how
- A waiting session says what it waits for.Asked wants an answer. Review wants a look.Read how
- Three counts for the whole fleet.Needs you is the only urgent one. The daemon sits on 127.0.0.1.Read how
The deep dive.
The same screen, taken apart: what each region holds, the rules behind it as drawings, one session walked from running to picked up, and where the screen can be wrong.
Eighteen sessions, and one question.
OCTYN runs around eighteen coding sessions at once across twenty-one codebases, as recorded on the work page on 2026-09-14. Every existing way of running those sessions is built for running one. There is a terminal, there is a conversation, and there is 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 nobody was looking.
Cockpit is OCTYN’s own internal system, in build and used while it is being built. The picture on this page is the working prototype with sample data in it, not a design.
The screen, taken apart.
The screen has three columns and a footer: projects on the left, the session in the middle, and on the right the rail of what needs a person. Here is each region in turn, and what it holds.
One screen over every session.
Three columns over a footer. Projects on the left, the session in the middle, and on the right the rail, which is the actual point. Everything in this capture is sample data: seven sessions across four projects.
- The screen
One screen over every session.
Three columns over a footer. Projects on the left, the session in the middle, and on the right the rail, which is the actual point. Everything in this capture is sample data: seven sessions across four projects.
- Left · Projects
Projects, each with its own count.
Every project shows how many of its sessions are running, how many exist and how many are waiting. A session sits under the project it belongs to.
- Middle · The session
A real terminal, not a rendering of one.
The moment action is needed, the real thing is what is needed, with its colours and its control characters intact. The pane in this capture is a mock and says so. The real one is a full terminal.
- Right · Focus
One session in focus, and why it stopped.
The rail opens with one session in focus. An error is a third thing again, neither asked nor review, and it takes this slot. In the capture it is a migration script, with a button to open the session.
- Right · Also waiting
Everything else waiting, tagged by what it waits for.
Asked means the session wants an answer. Review means it has finished something and wants a person to look. Each card also carries the skill the session ran and its task, so the tag and the reason sit together.
- Right · Running and activity
Then everything still running, then recent activity.
A running session gets a name and a line, and nothing that asks for attention. Recent activity sits under them. Read top to bottom, the rail answers the question the screen exists for.
- Bottom · The counts
The whole fleet in three counts.
Fleet, running and needs you. Only the last is urgent, and it is how many sessions need a person. At the right, the address of the local program that holds the sessions: 127.0.0.1.
How each region is meant to work.
Cockpit is in build, not finished. These drawings are ours, from the write-up and the capture. Nothing in them was recorded from a running fleet, and the sessions in them are the sample fleet.
How a session's state is worked out.
Every session is printing.
How the rail puts the fleet in order.
Needs a person: 0 · Running: 6
What stays up when the view goes down.
A session that stops and waits.
One session through the screen, from running to picked up. The real pixels are the capture's own. The first steps happen before the screen has anything to show, so they are drawn.
A session is running.
It is counted in its project, listed under Running in the rail, and counted as running in the footer. Nothing about it asks for a person.
Where the screen can be wrong or out of reach.
A status that is stale.
A session shown as running when it has stopped and asked a question is worse to trust than no monitor at all. It answers the question wrongly and gets believed. Working state out from output is a guess, and the prototype has no confidence signal yet.
An error is not a question.
A session that hit an error and one that asked something both stop printing. The screen keeps them apart: asked and review are tags, and an error is its own thing that takes the focus slot.
Nothing to open from a phone.
Staying local removes a class of problems and adds one. Nothing is exposed and nothing needs a login, and there is no way to see the fleet from a phone, which is where the person is when a session has waited twenty minutes.
- Answer a session that askedthe person it watchesAsked means the session wants an answer, and only a person can give it.
- Look at a session in reviewthe person it watchesReview means it has finished something and wants a person to look.
- Take an errorthe person it watchesAn error takes the focus slot and waits for a person to open the session.
What is written down, and what is not.
- 14 September 2026
- In build. The working prototype is what is pictured. Source: status on octyn.co/work.
- 14 September 2026
- Around 18 sessions at once across 21 codebases. Source: stated on octyn.co/work.
- 14 September 2026
- Local daemon on 127.0.0.1, no remote surface. Source: status bar in the prototype capture.
- 14 September 2026
- No timing instrumentation yet. Source: nothing in the prototype records how long a session waits.
- The line it holds
- One program holds every session, bound to the local machine only. That is the whole security model: no remote surface, no login, no account.
- What we did
- One program that holds every session, and one screen over it. Waiting sessions are tagged with what they wait for: asked, review, and error as a third thing that takes the focus slot.
- What we did not
- Measure it. There is no figure for how long a session sits waiting before it is picked up, which is the number the system exists to reduce. There is no confidence signal on a session’s state, no view from a phone, and no measurement of many terminals streaming at once.
- If it breaks
- The program holding the sessions is the single point of failure, by design. If it dies, the sessions are separate processes and keep running, and only the view over them is lost.
- In six months
- Which projects are in the fleet is configuration. Another waiting category, another column in the rail or another shortcut is a small code change. A second kind of session process is a larger one. Making it remote is a different system.
- What we would do differently
- Record the waiting time from the first commit, treat status inference as a first-class problem, and write down what a session state means before drawing the screen.
- Left out
- The capture is sample data, and the terminal pane in it is a mock, labelled as one. It is the only image of the system.
Something like this, for your company?
The first conversation is with the people who would build it. If there is a fit, the Consult comes next.