DEV Community: Space App

Building a multi-pane workspace for coding agents: PTYs, replay, and the backpressure we have not solved

Space App — Fri, 06 Nov 2026 16:06:15 +0000

SpaceApp is a self-hosted workspace that runs AI coding CLIs side by side in the browser, each in its own pane. I build it, it's MIT-licensed, and this post is the terminal side of it as it stands in the public release (v1.1.9): how a pane gets a real PTY, how output gets from that PTY to xterm.js and back after a reconnect, what broke on the way, and what we still haven't solved. Every number below comes from the code; file names are in the public repo so you can check them.

Two containers, one socket between them

A Docker install made with npx --yes run-spaceapp@latest install runs a small compose project. Two services matter here:

spaceapp-core runs the web app, the API and the WebSocket. It listens on 127.0.0.1:4911 by default and mounts no provider keys or login volume.
spaceapp-cli owns every PTY. It runs the pane host (packages/cli-host) as an unprivileged user (uid 10001).

They talk over a Unix socket on a shared volume (/run/spaceapp-cli/host.sock, mode 0660). PostgreSQL holds the rest, and a browser container is optional.

The split pays off on the first restart: restarting the core doesn't kill your CLIs, because they are processes of another container.

One PTY per pane

Each pane is one node-pty process (packages/cli-host/src/node-pty-spawn.ts):

export const spawnNodePty: CliHostSpawn = (spec) =>
  spawn("/bin/sh", ["-c", '/usr/bin/stty -isig; exec "$@"', "space-cli-host", spec.command, ...spec.args], {
    name: "xterm-256color", cols: spec.cols, rows: spec.rows, cwd: spec.cwd, env: spec.env });

That stty -isig is there because of a bug. Without it, Ctrl-C in a pane became SIGINT and killed the whole CLI process tree. With signals off on the PTY, Ctrl-C reaches the CLI as the byte 0x03, which is the CLI's own cancel key.

The rest of the lifecycle lives in session-registry.ts:

Sessions are keyed by a CLI session id. Each spawn gets a generation id and a monotonically increasing output sequence number, which is what makes replay possible later.
kill() in node-pty only sends SIGHUP and swallows errors, and we had process trees that survived it. The registry now escalates: SIGHUP, then SIGTERM, then SIGKILL on the whole process group (the PTY child is a session leader, so kill(-pid, SIGKILL) reaches everything under it).
Some exit events never arrive. A sweep checks process.kill(pid, 0) and reconciles them.
A session with no attachment is reaped after 30 minutes by default (swept every 60 s). When you come back, the pane host recreates it and resumes. So, honestly: an agent does not keep running forever after the last browser tab on it closes. Warm rooms, below, change when that happens.

The pane host protocol

The API and the pane host speak length-prefixed JSON over the socket (framing.ts): a 4-byte big-endian length, then UTF-8 JSON, 8 MiB at most per frame. The methods are inspect, attach, input, resize, detach, terminate, reapDetached and ping, and requests on one connection run strictly in order through a promise queue.

Two details turned out to matter.

Replay from a ring buffer. Output is chunked to 8,000 characters and kept per session in an 8 MiB ring buffer. An attach says "everything after sequence N". If those events already left the ring, the host says so instead of pretending:

if (earliestSequence !== undefined && afterSequence < earliestSequence - 1) {
  throw new CliHostError("CLI_HOST_REPLAY_GAP", `CLI host output before sequence ${earliestSequence} is no longer buffered …`);
}

Lanes. Strict ordering per connection means one slow session could delay every other session on that connection. So the API opens 32 connections to the host and pins each session to one with an FNV-1a hash of its id. One session's queue never sits in front of another's.

The API: two paths for the same output

When output arrives from the host, the API does two things with it (apps/api/src/cli-terminal.ts):

It sends it straight to the connected browsers.
Separately, it batches it for PostgreSQL, every 20 ms or 32 KiB, into a transcript table. Before anything is stored, it goes through pattern redaction (API keys of the common shapes, Bearer and Basic headers, session cookies).

So there are two stores: the host's ring buffer, which is fast and gone if the host restarts, and the transcript, which survives. A reconnect replays the stored transcript and yields to the event loop every 16 frames, so a long replay doesn't freeze the API for everyone else. Redaction applies to what is stored; the live stream your own browser receives is the raw output.

The WebSocket

Each pane's terminal is one WebSocket at /api/panes/:id/cli/terminal:

It opens with a one-time ticket (32 random bytes, base64url, with a TTL).
Every frame is a JSON text frame, validated with zod on both sides. Clients send input (up to 1,000,000 characters), resize (2-400 columns, 2-200 rows), interrupt, ping and control messages. The server sends output, status, ready, error, pong and session_replaced.
Output is split into frames of at most 8 KiB, cut at code-point boundaries so a split never breaks a multi-byte character.
permessage-deflate is on above 1 KiB, and maxPayload is 16 MiB.

Several tabs can watch the same pane, but only one can type: the holder of a control lease. The lease lasts 30 s. We first renewed it at 30 s, which raced the TTL and dropped keystrokes in a live session (20 September). The heartbeat is now capped at 15 s.

xterm.js in the browser

Each pane is one @xterm/xterm 6 terminal with 2,000 lines of scrollback. Two settings come with stories:

The terminal starts at the PTY's stored size, not xterm's default, so a replay isn't reflowed through the wrong geometry first.
convertEol stays off. The PTY's termios already handles line endings, and turning it on corrupted the cursor positioning of full-screen TUIs.

Writes are paced in the browser. Only one terminal.write(chunk, callback) is in flight at a time, and the next chunk goes after xterm's callback. Chunks are at most 1 MiB, with a yield between them.

Hidden and minimized panes don't parse anything. Their output is queued in JavaScript until the pane becomes visible. Past 128 KiB for one pane, or 1 MiB in total, the app records a pressure diagnostic. The queue itself isn't dropped at those sizes, so it is a warning, not a cap.

Then there are warm rooms. Up to 6 recently used rooms stay mounted with live sockets, up to 96 connected panes (24 on mobile). We used to park hidden sockets after 30 s to save resources. Every return to a room then needed a fresh ticket, an xterm rebuild and a full replay. Parking is off now, and leaving a room no longer rebuilds its terminals. A room that falls out of the six disposes its terminals and every addon properly.

One more fix that you only find by running real CLIs: OpenCode's TUI renderer sometimes drops the ESC[ introducer between colour runs, and xterm then prints the raw parameters as text. A small repair parser in the output coordinator puts the introducer back.

What we haven't solved: backpressure

This is the part I'd most like opinions on. There is no end-to-end backpressure:

The server doesn't check bufferedAmount and doesn't pause the PTY when a browser is slow. It just sends.
On the host socket, socket.write is called without checking its return value.
What we do instead: 8 KiB frames, one xterm write in flight, 1 MiB chunks with yields, hidden panes that queue instead of parsing, and a replay that yields every 16 frames.

That holds up for normal agent output. A CLI that dumps a huge log while a browser on a slow link is attached is exactly the case it doesn't cover. Pausing the PTY when a socket's buffer grows would be the honest fix; the open question is how it should behave when several tabs watch the same pane at different speeds.

Isolation, precisely

People ask whether panes are sandboxed. They are not, and the README says so: rooms organize sessions; they are not a security boundary. Precisely:

Core, CLI, browser and PostgreSQL are separate containers on one compose network. All run with no-new-privileges, and none gets the Docker socket.
Inside the CLI container, every pane is a process of the same user. Each provider gets its own HOME, TMPDIR and config root with umask 077. That separates configuration, not security: one CLI could read another CLI's files.
Host folders are mounted only after you add them as workspaces (run-spaceapp workspace add). An opt-in host-root mode on Linux mounts / read-write into the CLI container. It does what it says, so read the docs before you turn it on.

Caps and sizes

16 panes per room, enforced by a database check (pane_cap BETWEEN 1 AND 16) and the schema.
6 rooms by default, configurable up to 16.
All panes share one CLI container with a memory and CPU cap: 2 GB / 1.5 CPUs on the small profile, up to 4 GB / 3 CPUs on the large one. The host should have at least 4 CPUs and about 8 GB of RAM. It isn't lightweight, and I'd rather say that up front.

Things that broke, in one list

Each of these is written in a comment next to its fix in the public code:

Two OpenCode 2 --standalone servers on one store failed to start. Now there is one shared opencode serve per CLI container, with a lock and a health check, and panes attach to it.
OpenCode's update dialog opened over a fresh pane and swallowed the user's first prompt. Auto-update is off inside the container.
Ctrl-C killed the whole CLI tree. Fixed with stty -isig.
node-pty kill() left process trees alive. Fixed with process-group SIGKILL escalation.
Parking hidden sockets forced a rebuild and a replay on every room switch. Parking is off.
Renewing the control lease at its TTL dropped keystrokes. The heartbeat is 15 s.
A TUI renderer dropped CSI introducers. A repair parser restores them.

Try it, or tell me how you'd do backpressure

npx --yes run-spaceapp@latest install

Node.js 20.11 or newer; Linux, macOS or Windows 11. The code is at https://github.com/oll4com/spaceapp and the paths above are where to start reading.

If you've built a multi-viewer terminal over WebSockets: how do you pause a PTY when one watcher is slow and another isn't?

We gave 6 AI coding CLIs the same concurrency bug and 6 hidden tests. All six passed. The diffs did not agree.

Space App — Thu, 05 Nov 2026 13:35:22 +0000

Arguments about which AI coding CLI is "best" usually rest on vibes or on synthetic leaderboards. So we took one small, real-shaped concurrency bug, gave it to six CLIs with the same prompt, and graded each fix with tests the CLIs never saw.

All six fixed it. That's the first result, and it limits what this post can claim: the task didn't separate them on correctness. What it did show is how long each took, what each spent, how big the diff was, and that one fix that passes every test still changes the queue's behaviour in a way the tests didn't check.

I build SpaceApp, a self-hosted, MIT-licensed workspace that runs these CLIs side by side. That's why we have them all installed. The runs below were headless, from a script, not inside SpaceApp, so this post is about the CLIs.

The bug

The repo is a throwaway Node package, jobq: an in-process job queue with concurrency, retries, exponential backoffMs and an onIdle() promise. It has no dependencies, about 90 lines in src/queue.js, and 5 tests on node:test. The bug is in the retry path:

async _run(job) {
  this._running++;
  job.attempt++;
  try {
    const value = await job.fn({ id: job.id, attempt: job.attempt });
    this._completed++;
    job.resolve(value);
  } catch (error) {
    if (job.attempt <= this.retries) {
      this._running--;                       // first decrement
      const delay = this.backoffMs * 2 ** (job.attempt - 1);
      setTimeout(() => {
        this._pending.push(job);
        this._next();
      }, delay);
      return;
    }
    this._failed++;
    this.onError?.(error, job.id);
    job.reject(error);
  } finally {
    this._running--;                         // runs on the retry path too
    this._next();
  }
}

Two things are wrong:

A failed attempt that will be retried decrements _running twice, once in catch and again in finally (a return inside catch doesn't skip finally). So the queue starts more jobs than concurrency allows.
A job waiting out its backoff is counted nowhere: not in _pending, not in _running. So onIdle() resolves while a retry is still due.

The 5th visible test fails on the baseline: "onIdle resolved before the retried job finished". Deleting just the extra decrement makes that test pass while onIdle() stays wrong. So a shallow fix is possible, and the hidden tests exist to catch it.

The prompt

Every CLI got this, verbatim:

The test suite of this repository fails (npm test). Find the root cause of the bug in the job queue and fix it. Do not modify the tests. Run npm test to check your fix. When you are done, reply with a short summary of the cause and the fix.

Method

One run per CLI, one after another, each on a fresh copy of the repo.
The same 1,200 s timeout for all. No run came near it.
Headless, auto-approve, stdin closed, and a minimal environment (env -i): no MCP servers, no global agent instructions, throwaway config or home directories. Sign-ins were linked in, never copied.
Wall time is the whole CLI process from start to exit, so it includes start-up.

Grading ran after each CLI had exited:

the diff against the baseline, the files touched, and whether the CLI committed;
npm test as the CLI left the repo;
the visible tests again on a copy with test/ and package.json restored from the baseline, so a CLI that edited the tests couldn't pass that way;
6 hidden acceptance tests, never shown to any CLI, run 3 times each.

The hidden tests cover:

onIdle() while only a retry is waiting;
a retry waiting for a free slot;
30 flaky jobs at concurrency 3 with exact counters;
backoff doubling;
three onIdle() waiters;
a synchronous throw.

Before trusting them, we ran them against three known states:

Version of `queue.js`	Hidden tests passed
Baseline (the bug)	1 of 6 (2 fail, 3 time out)
Shallow fix (only drop the extra decrement)	4 of 6
Reference fix	6 of 6

So the hidden tests do tell a shallow fix from a real one.

Results

All six:

changed only src/queue.js;
made no commit;
left the visible tests passing;
passed 6/6 hidden tests on all three runs.

CLI (version)	Model	Wall time	Hidden tests (3 runs)	Diff
Claude Code 2.1.316	claude-opus-5-5	16.3 s	6/6, 6/6, 6/6	+4 −2
OpenCode 2.2.5	claude-opus-5-5 (see below)	16.9 s	6/6, 6/6, 6/6	+4 −2
GitHub Copilot CLI 1.0.105	auto: "GPT-6 Luna"	25.9 s	6/6, 6/6, 6/6	+4 −2
Cursor CLI 2026.10.22	"Auto" (not named)	83.2 s	6/6, 6/6, 6/6	+5 −2
Grok CLI 1.0.70	grok-4.7	88.3 s	6/6, 6/6, 6/6	+18 −10
Gemini (Antigravity CLI `agy`) 1.4.12	Gemini 3.8 Flash (High)	149.4 s	6/6, 6/6, 6/6	+4 −2

Tokens and cost

These are the figures each CLI reported, or our API gateway's list-price estimate where the CLI printed none. They come from four different kinds of source, so don't read them as one ranking. Tokenizers differ, cache accounting differs, and Copilot rounds.

CLI	Turns / tool calls	Tokens	Cost	Source
Claude Code	5 turns	input 10, cache write 18,939, cache read 112,804, output 1,367	$0.1446	Claude Code's own estimate at API list prices. The run used a subscription, so this is not money spent; our gateway's estimate for its 5 requests was the same $0.1446
OpenCode	4 steps, 3 tool calls	input 10, cache write 6,274, cache read 33,592, output 851, reasoning 130	$0.0586	Our gateway's list-price estimate for its 5 requests, which includes OpenCode's session-title call. OpenCode printed cost 0 (no price table in its provider config); its token counts match the gateway's
Copilot	—	↑ 74.4k (57.7k cached, 16.7k written), ↓ 1.2k (636 reasoning)	0.33 AI Credits	Copilot's own summary
Cursor	10 tool calls	input 18,275, cache read 70,784, output 5,023	not reported	Cursor's stream-json `result` event
Grok	7 turns	input 37,288, cache read 184,064, output 9,390 (reasoning 7,969)	$0.2229	Grok CLI's own figure
Gemini (agy)	agy reports 1 turn	input 132,071, cache read 231,732, output 13,509 (thinking 11,803)	$0.1672	Tokens from agy's JSON; the cost is our gateway's estimate for the run's 19 requests. agy prints no cost

What the fixes look like

Three CLIs (Claude Code, OpenCode, Gemini) wrote the same fix as our reference. A counter for jobs waiting out their backoff replaces the extra decrement, the timer decrements it, and _isIdle() checks it. This is Claude Code's:

@@ -16,6 +16,7 @@ export class JobQueue {
     this._failed = 0;
     this._idleWaiters = [];
     this._seq = 0;
+    this._retrying = 0; // jobs waiting out their backoff: not pending, not running, but not done
   }
@@ -41,7 +42,7 @@ export class JobQueue {
   _isIdle() {
-    return this._pending.length === 0 && this._running === 0;
+    return this._pending.length === 0 && this._running === 0 && this._retrying === 0;
   }
@@ -65,9 +66,10 @@ export class JobQueue {
     } catch (error) {
       if (job.attempt <= this.retries) {
-        this._running--;
+        this._retrying++;
         const delay = this.backoffMs * 2 ** (job.attempt - 1);
         setTimeout(() => {
+          this._retrying--;
           this._pending.push(job);
           this._next();
         }, delay);

The others:

Cursor: the same idea with a _delayed counter, decremented after the job is queued again.
Grok: the same counter, plus a restructure that moves all retry scheduling into finally. It's correct, and it's the biggest diff (+18 −10). Whether that's a cleanup or churn depends on who reviews it.
Copilot: a different design. The failed job keeps its running slot through the backoff, and the timer releases it:

@@ -59,16 +59,18 @@ export class JobQueue {
   async _run(job) {
     this._running++;
     job.attempt++;
+    let retryScheduled = false;
     try {
@@
       if (job.attempt <= this.retries) {
-        this._running--;
+        retryScheduled = true;
         const delay = this.backoffMs * 2 ** (job.attempt - 1);
         setTimeout(() => {
           this._pending.push(job);
+          this._running--;
           this._next();
         }, delay);
         return;
@@ -77,7 +79,7 @@ export class JobQueue {
     } finally {
-      this._running--;
+      if (!retryScheduled) this._running--;
       this._next();
     }

It passes every visible and hidden test. onIdle() is right, because a waiting job still counts as running, and the concurrency limit holds. So by the grading above, it's a full pass.

What the hidden tests didn't catch

This part came after the results, so it isn't part of the pass/fail above. It's a finding, not a score.

Reading the diffs, Copilot's design looked like it changed what "running" means. The package README says concurrency is "the most jobs running at the same time", and a job sleeping through its backoff isn't running. So we wrote two more checks from that sentence:

P1: at concurrency 1, does another job run while one job waits out a 200 ms backoff?
P2: does stats().running leave a waiting job out?

Five fixes and the reference pass both. Copilot's fails both: job b waited 190 ms behind the other job's backoff, and stats().running read 1 while nothing was running. Its fix is correct for the limit and for onIdle(), but now a backoff blocks a slot. With long backoffs and low concurrency, that's real throughput you lose without any test going red.

Two lessons for anyone grading agent output, ourselves included:

"Passes the hidden tests" is only as strong as the tests. We wrote six that caught the shallow fix, and they still missed a design change. We only saw it because we read the diffs.
The prompt said "fix the bug", not "keep the semantics". Copilot's version is a defensible reading of an underspecified task. If your spec lives in a README sentence, say so in the prompt or put it in a test.

Who didn't run, and why

N is 6 because that's how many really ran. We have more CLIs installed:

Codex and DeepSeek: skipped on purpose. There was no quota or balance on those accounts at the time of the run.
Kimi Code: installed and signed in, but the smoke run answered 403 Your current subscription does not have access to Kimi Code right now.
Qwen Code: installed, but its credential check reported the quota as exhausted before the batch, so it wasn't run.
OpenCode on its free default model: the first OpenCode attempt used the free Big Pickle model and stopped after 3.6 s with a 429 Free usage limit reached. OpenCode was then run on Claude Opus 5.5 with an Anthropic API key. So the OpenCode row measures the OpenCode harness with Opus, not OpenCode's free tier.

Honest limits

n = 1 per CLI. Wall times and token counts would move on another run. One run tells you what happened once; it doesn't rank CLIs.
One small bug in one ~90-line file. Every CLI solved it, so this task doesn't separate them on correctness. It shows speed, cost, diff size and fix design on an easy-to-medium concurrency bug.
Each CLI ran a different model, so harness and model can't be separated. Claude Code and OpenCode both ran Opus 5.5 (16.3 s vs 16.9 s, same fix), which is the closest thing here to a same-model comparison.
Copilot and Cursor pick their own model ("auto"). Copilot's smoke run 7 minutes earlier picked a different one (MAI-Code-1.1-Flash). agy's model came from its saved settings.
Costs come from four kinds of source (the CLI's own figure, our gateway's list-price estimate, AI Credits, none), so they aren't comparable. Claude Code's figure is a list-price estimate for a subscription run.
One shared Linux server under load (24 cores, load average about 16 during the batch, Node v26.13.0). The Claude and Gemini requests went through our gateway, and wall time includes that hop and CLI start-up.
Environments were clean but not identical. Grok ran with its usual home directory, which holds its skills and memory, because its sign-in lives there. The others ran with throwaway homes and linked sign-ins.

If you want to repeat it

The ingredients are all in this post: the buggy _run above, the prompt, the shallow-fix trap, and the list of hidden tests. The rest of the queue is the obvious code around them (add, stats, onIdle, a _next loop). Write the hidden tests before you run anything, and check them against the baseline, a shallow fix and a reference fix, as we did. That step is what makes the pass column mean something.

What would you want in the next run: a harder bug that actually separates them, or the same CLIs pinned to the same model?

Why terminal CLI agents beat web chat on real codebases (and where web chat still wins)

Space App — Wed, 04 Nov 2026 15:12:08 +0000

I build SpaceApp, a self-hosted workspace for running AI coding CLIs side by side. This post is about the workflow, not the tool; the tool gets two lines at the end.

If your agent can't run npm test and read the failure in the same shell, you end up as the relay between the model and your codebase: copy the file in, copy the answer out, run it, paste the error back, repeat. That loop is fine for a snippet. On a real codebase it breaks down, and the reasons are worth spelling out.

What a web chat can't see

The rest of the repo. You paste the file you think matters. The bug is often in the one you didn't paste: the caller, the fixture, the config.
The real output. You paste the part of the error you think matters. The useful line is often 40 lines up, or in a warning you skipped.
Whether the fix worked. The chat never runs it. "This should fix it" is a guess until a test says so.
What changed. After five rounds of copy-paste, nobody knows exactly which version of which file is on disk.

What a terminal agent does instead

A CLI agent works in the working tree. It can grep for every caller before it changes a signature, run the test it just broke, read the compiler's diagnostics in full, edit several files in one change, and leave the result as a diff on a branch you can review. The feedback loop runs in the shell, not through your clipboard.

A small real example from our own repo: one of our contract tests passed on its own in about 1.5 seconds and timed out only when the whole suite ran in parallel. Nothing about that is visible in a pasted file or a pasted error. It took something that could run the suite, see the timing and change the test, and that was an agent working in a shell.

Where web chat still wins

To be fair to it:

Exploring an idea before there is any code.
Explaining a concept, an API or an error message you don't understand.
A self-contained snippet: a regex, a SQL query, a one-off script.
Zero setup, and no access to your machine, which is sometimes exactly what you want.

What terminal agents cost you

They are more powerful because they touch real things, and that is also the risk.

Give them a branch, not your main checkout. One git worktree per agent keeps their work apart, and you review the diff before it lands.
Give them only what they need. The folders for the task, read-only where reading is enough. No production credentials in the environment.
Make tests the referee. An agent that can run tests will also happily "fix" a test to make it pass. Review test changes as carefully as code changes.
Watch for parallel surprises. If you run several agents at once, run your suite in parallel too. Tests that pass alone and fail together are common, and some of them point at real bugs.

A worktree per agent is one command:

git worktree add ../myrepo-agent-a -b agent-a

Running several side by side

Once one terminal agent works, the next step is usually two or three: one per repo, or one planning and one executing. That works in tmux, in separate terminal windows or in a workspace that keeps the sessions for you. The rules stay the same: a worktree each, one way into main that builds and tests, and you as the reviewer rather than the clipboard.

Over to you

Where do you still use web chat for coding, and where did you switch to a terminal agent for good? And for those running more than one agent: what was the first rule you had to add?

The two lines about the tool: SpaceApp keeps CLI sessions side by side in persistent rooms on your own machine and your own provider accounts. It is MIT-licensed and installs on Linux, macOS or Windows 11 with Node.js 20.11 or newer: npx --yes run-spaceapp@latest install. Code and docs: https://github.com/oll4com/spaceapp

Nous: one mind over every AI coding CLI in a self-hosted workspace

Space App — Wed, 04 Nov 2026 14:18:03 +0000

I build SpaceApp, a self-hosted workspace where AI coding CLIs (OpenCode, Codex, Claude Code, Gemini and others) run side by side in persistent rooms. Each pane in a room is its own CLI or app session, on your own provider accounts.

Running several agents at once moves the bottleneck to the person. Any pane can stop on a question, a sign-in or a choice, and you end up going from pane to pane to find out which one is waiting and for what. Nous is the part of SpaceApp built for that. This post covers what it does, taken from the public docs, and where its limits are.

One mind, fed by progress reports

Nous (Greek νους, "mind") sees every room, pane, copilot, plan and release train. It does not watch screens: it reads each pane's progress reports, so it knows what every agent works on and what it waits for. You talk to Nous instead of to every agent.

The routine work it does itself

It opens, steers and closes panes, and sends each one its next step.
It runs up to five helpers side by side.
It saves finished work to Space Memory and closes panes whose work is done.

Standing orders run around the clock: finished panes are saved and closed, stalled plans get a nudge, and a daily self-review looks back at its own turns.

Goals. Type /goal and your objective in your own words. Nous breaks it into plans, panes and helpers, and keeps working on it in turns of its own until it is done.

The four kinds of decisions it brings to you

Releases.
Deletes.
Anything that reaches third parties or money.
The direction of the work.

Each decision is a card with Approve and Decline; a plain yes or no in words decides it too. "Always approve" lets a routine kind of decision run on its own next time, but never a release or a delete.

When an agent needs your hands or an answer, you get one Needs you request: one question, its options and a recommendation. You reach Nous in its dock, on your phone or in a paired Telegram chat. While you are away it keeps a log for your return, and at night, requests for your hands wait for the morning.

The Plan map shows every open plan: what each one waits on (you, a date, a promote, a third party, Nous or the server), the plans it depends on and what to unblock first. Nous reads the same map before it proposes or starts work.

Logins it never sees

Your browser encrypts every login in the Vault with keys that live only in the open tab; the database keeps ciphertext. When an agent or Nous needs a login or a one-time code, a broker on your host fills it into the pane's browser, and the agent gets back a status and an audit id, not the value. After a fill, the page stays protected: the agent can click and type but cannot read the field.

Quotas

Nous watches your AI quotas, spends less while they run low and uses a cheaper model for its background turns.

A small, real example

This article started as a brief from Nous to the Marketing Copilot pane of my own SpaceApp: draft an article, a Show HN text and an X thread about Nous, for review only. The copilot drafted them and asked for a review; nothing goes out before it is approved.

Limits worth knowing

Nous is off on a new install. You turn it on with Work on my behalf in its dock.
By default SpaceApp runs for one owner on one machine; team accounts, with a CLI container per user, are opt-in.

Try it

You need Linux, macOS or Windows 11, Node.js 20.11 or newer, and at least 4 CPUs, 8 GB RAM and 15 GiB of free disk:

npx --yes run-spaceapp@latest install

SpaceApp is MIT-licensed. Code and docs: https://github.com/oll4com/spaceapp. Nous in the docs: https://spaceapp.dev/docs/nous/

I'd like to hear where you would draw the line between "routine" and "ask me" for your own agents.

One tool layer for eleven AI coding CLIs: what we learned building SpaceApp

Space App — Wed, 28 Oct 2026 13:40:43 +0000

Why I built SpaceApp, in my own words:

I built it to be my main work tool. I'm a developer! And it became my main tool and work environment. I no longer need to open email, social media or any development program: absolutely nothing. I'm inside SpaceApp all day; I even watch YouTube videos and listen to music through SpaceApp.

SpaceApp is a self-hosted workspace where AI coding CLIs (Claude Code, Codex, OpenCode, Gemini CLI and others) run side by side in persistent rooms. Each of them comes with its own config format, its own way of registering MCP servers, its own sign-in, its own "resume the last session" flag and its own idea of what Esc means. This post is about the two parts that turned out to matter most: where the agents' tools come from, and where the agents' sessions live.

The N×M problem

Every CLI wants its tools declared in its own file: one JSON shape for one, a TOML table for another, a command-line flag for a third. Multiply that by the tools you want every agent to have (a managed browser, shared memory, tasks, files, deployment checks) and you get N×M configurations that drift apart. Worse, a CLI usually starts every declared MCP server when the session starts, whether or not the agent ever calls it. Twelve panes × five servers is a lot of idle processes.

Capability first, MCP on demand

The first rule we settled on: use what the runtime already has. If the CLI has a shell, file editing and image input, the agent uses them directly. A tool layer that wraps cat in an MCP call only adds latency and tokens.

For SpaceApp's own operations (status, logs, the managed browser, memory), the route depends on the runtime:

Codex and Claude Code panes register no MCP server at startup. When the agent needs a SpaceApp operation it calls one on-demand entrypoint, space-capability. It answers "what can I call and with which arguments" from cached, compact schemas without starting anything. The first real call starts a small worker on a pane-private Unix socket, and that worker starts only the backend that was asked for: at most three per pane, each stopped after an idle timeout.
Other runtimes keep a single dispatcher (space-mcp-dispatcher) declared once from a shared registry. The dispatcher also spawns registry servers only when called and stops them when idle.

Two details turned out to matter more than the transport:

A declared tool grants nothing. Every operation still passes its own schema, role, approval and broker gates, whichever path it came through. MCP is a transport, not an authorization model.
No replays after ambiguity. If a call may have executed and the transport broke, the call is not retried automatically. A duplicated deploy check is annoying; a duplicated "send" is worse.

The operator can override routing per runtime, model and tool (Automatic, Native only, Allow fallback, Disabled), and the settings page explains which route a call will take.

This path is still marked experimental in the architecture doc: it is enabled for Codex and Claude Code only, because each runtime's capabilities have to be verified before it gets the on-demand path.

Sessions that outlive the web server

The second lesson: the process that serves the UI must not own the agents.

In SpaceApp each CLI runs in a terminal session owned by a separate pane host process, not by the API. The API attaches to that session over a socket. When the API restarts during a deploy, or the browser drops its connection, the agent keeps working, and the pane re-attaches to the same session. The pane host tracks session generations and output sequence numbers, so a reconnecting view knows where it left off.

That separation is also why we never resume a provider conversation by copying a transcript. If a CLI has a native resume (a session id, a thread id), we use it; if it does not, we say so instead of pretending.

Eleven TUIs are eleven TUIs

Things that broke along the way, in roughly the order they hurt:

Stop means different keys. Esc interrupts a turn in some CLIs, Ctrl-C in others, and one is stopped through its own server API. Stop now sends each TUI its own interrupt.
Model pickers are UI, not API. Switching a model in one CLI means driving its /model menu. In a short pane the menu shows a scrolled window of rows and clips its hints, so the picker has to read scroll markers and page through the menu. It also has to pick "this session only", never the saved default every other session shares.
"Ready" screens lie. An old, partial MCP startup message once kept a newer, ready Codex screen from being detected. Now a newer header supersedes the earlier partial marker, while a screen that is still loading keeps blocking.
Contracts are not end-to-end proof. A contract suite checks every declared start, resume and login command line of every declared runtime against the wrapper filter. That catches regressions in our adapters; it does not prove that the next upstream release of a CLI behaves the same. We track that gap openly.

What it does not solve

Isolation between users. Rooms organise work; they are not a security boundary between mutually untrusted users. The Unix user is the outer trust boundary, so one install should serve one trust domain.
Your provider's view. Self-hosting keeps the workspace and its data on your host. The model providers you configure still receive what the agents send them.

Try it

SpaceApp is open source (MIT) and installs with:

npx --yes run-spaceapp@latest install

Architecture: https://github.com/oll4com/spaceapp/blob/main/docs/architecture.md · Known limitations: docs/quality/KNOWN_LIMITATIONS.md in the repository.

If you run several coding agents on one codebase, I would like to hear how you keep their tools and sessions in order.

Six AI models played chess through their CLIs. None of them delivered checkmate.

Space App — Mon, 19 Oct 2026 17:05:14 +0000

I build SpaceApp, a self-hosted workspace for running AI coding CLIs side by side. On 18 October I let six models play chess against each other there, each through its own CLI. Nobody won by checkmate. The way they lost is the interesting part.

The setup

Players: Opus 5.5 and Fable 5.1 (through Claude Code), GPT-6-Astra and GPT-6.1-Sol (through Codex), all at xhigh reasoning; Gemini 4 Argon (High) and Gemini 3.8 Flash (High) (through the Gemini CLI).
Format: a 4-round Swiss tournament, 12 games.
Clock: 120 seconds per move. Each move is one one-shot turn of the model's CLI: it gets the position and answers with a move.
Strikes: a timeout, a provider error or a second illegal answer plays a random legal move for that side and counts a strike. The third strike forfeits the game.
Length: after 60 plies (30 moves each) the game is adjudicated on material.

The results

#	Model	Points	W / D / L	Elo	Avg per move	Forfeits
1	Opus 5.5 (xhigh)	3.5	3 / 1 / 0	1535	13 s	0
2	Gemini 4 Argon (High)	3.5	3 / 1 / 0	1535	23 s	0
3	GPT-6-Astra (xhigh)	2	2 / 0 / 2	1500	37 s	2
4	Fable 5.1 (xhigh)	1	1 / 0 / 3	1478	26 s	3
5	Gemini 3.8 Flash (High)	1	1 / 0 / 3	1477	40 s	3
6	GPT-6.1-Sol (xhigh)	1	1 / 0 / 3	1475	34 s	3

Zero checkmates. 11 of the 12 games ended on a third strike.
The 12th game, Gemini 4 Argon against Opus 5.5, ran the full 60 plies and was drawn on material.
Opus 5.5 and Gemini 4 Argon were the only models that never needed a fallback move. Opus 5.5 was also the fastest, at 13 seconds per move on average.

What it measures, and what it does not

Twelve games are a small sample, and a tournament decided by forfeits says very little about chess strength. What it does show is how reliably a model answers through its CLI when every answer has a deadline: no timeouts, no provider errors, no illegal moves, game after game. That is the property I care about most when agents run unattended for hours, and it is not the same ranking you get from a single-prompt leaderboard.

Try SpaceApp

SpaceApp runs on Linux, macOS and Windows 11 with Node.js 20.11 or newer:

npx --yes run-spaceapp@latest install

It is source-available under the Business Source License 1.1. Code, docs and known limitations: https://github.com/oll4com/spaceapp

If you have run something similar, I would like to know which models held up for you, and which rules you would change for a fairer second run.

From one command to a first page: what changed in SpaceApp's setup

Space App — Sat, 17 Oct 2026 14:10:50 +0000

I build SpaceApp, a self-hosted workspace for running AI coding CLIs in isolated rooms. A room organizes work; each pane in it is an independent CLI or app session. The runtimes on offer are OpenCode, Codex, Gemini, Qwen Code, Kimi Code, Grok Build and an experimental DeepSeek CLI; Claude Code has its own owner-initiated installation flow.

The latest setup releases were about one stretch of the experience: the time between running the installer and getting a first useful answer. Here is that path step by step, and what changed on it.

1. Install

You need Linux, macOS or Windows 11, Node.js 20.11 or newer, and at least 4 CPUs, 8 GB RAM and 15 GiB of free disk. The standard profile, which adds a managed browser, recommends 8 CPUs, 16 GB RAM and 25 GiB.

npx --yes run-spaceapp@latest install

The launcher manages the core API and web app, the CLI runtimes, PostgreSQL and Temporal. The default light profile leaves out the managed Chromium; the standard profile starts a browser container as well.

2. Create the owner account

Once the installation passes its readiness checks, you use a one-time setup token to create the first account, register the folders you want agents to work in, and connect providers through their official login flows or masked credential input.

Host folders are visible only after you register them as workspaces, and read-only mounts are supported.

New: the setup wizard's Ready step offers three first prompts you can copy.

3. The first model

The first OpenCode pane starts on a free model, Big Pickle. A model counts as working only after a real tool call: it has to read a small file with its read tool and answer with the random token inside it. When Big Pickle fails that check, the newest free tool-capable models are tried instead.

Free models can change upstream at any time. If the one you are on stops responding, pick another in OpenCode.

4. The first prompt

Two things used to get in the way here.

A room without a project had nowhere obvious to write. Now a CLI pane in such a room starts in /workspaces/<room>, so a first prompt like "build me a page" writes index.html there.

The first task could stop at a permission prompt. On macOS, a first OpenCode task could wait at "Access external directory /tmp" until someone answered. Now OpenCode's first run authorizes only its own private scratch directory, and the bootstrap instructions send temporary files there. Other paths outside the workspace still ask.

5. Staying current

The app now shows "Update available" when a newer release exists and opens the update command with a Copy button:

npx --yes run-spaceapp@latest update

What to know before you try it

SpaceApp is designed for one trusted owner on one self-hosted instance.
Backups are portable and checksummed and cover application data, PostgreSQL and owner memory. Provider credentials, login state, workspace contents and browser profiles are left out.
Telemetry is opt-in. Answer No and nothing is sent. Answer Yes and one anonymous event is sent the first time an agent finishes an answer (event, random id, version, CPU architecture, date).

Feedback welcome

I would like to hear where the first five minutes still break for you: your OS, the profile the installer picked, and the step where it stopped. The full release notes are here: https://github.com/oll4com/spaceapp/releases