Skip to content
Agent Tree Knowledge Hub
🎓 Find your path Subscribe

Nerve Center v5: The Web Cockpit

Tier 3 · Real Builds 9 min read

Before this, read:

When you have ~31 agent packages, 8 domain agents, a CEO orchestrator, ~155 cron jobs, and a Supabase backend with 200+ tables, you need a way to look at all of it from one place. Not a dashboard with pretty KPI cards that lie about whether anything is actually running. A cockpit — something that shows real state, lets you send input to live agents, and surfaces what needs your attention.

That’s Nerve Center v5.

What it is

Section titled “What it is”

The Nerve Center (nerve-center-v5) is a Next.js application deployed at nerve-center-v5.vercel.app. It has approximately 100+ API routes, backed by Supabase for liveness data and structured event logs, proxied through a Mac Mini bridge server that manages the actual Claude Code processes.

The main surfaces:

/org — Org chart

Live React Flow + elkjs graph of the agent org: MCPs, agents, domains, skills, hooks, plugins. Reads from filesystem composition via Supabase; no hand-curated YAML. 52 visible nodes in a single viewport.

/cockpit — Chat panes

One pane per domain or project agent. Clean bubble rendering of the agent’s structured transcript. Raw terminal available as a one-tap toggle. Live cost badge per pane. Resume-from-dead.

Cost HUD

Real token-spend tracking: ~$186/day, ~$2k/week (the $0.00 lie was killed 2026-05-31). Per-session cost attribution. No financial fiction.

/tasks, /projects, /domains

Tasks filtered by domain/status/priority from the Supabase tasks table (sourced from domain tasks.yaml). Project registry with live session indicators. Domain status pages with heartbeat timing.

What version 5 actually means

Section titled “What version 5 actually means”

The “v5” label is shorthand for “the version that survived the reckoning.” To understand it, you need to know what came before — and that story gets its own two articles (D2 and D3) because it’s the most instructive part.

The short version: the original cockpit scraped the interactive Claude Code TUI over a PTY (pseudo-terminal) and replayed raw ANSI escape codes in a browser <xterm> element. This caused every class of reliability bug the cockpit ever had. A three-agent research synthesis in May 2026 reached a unanimous verdict on the root cause and the fix. The cockpit was rebuilt around a structured claude -p --output-format stream-json event timeline, with Supabase as the liveness store.

v5 is that rebuilt cockpit — the one that doesn’t lie about what’s running, doesn’t corrupt on reconnect, and doesn’t eat your input.

The bridge

Section titled “The bridge”

The cockpit cannot talk to Claude Code processes directly — Vercel is a serverless hosting platform; the agents run on a Mac Mini at home. The connection is a FastAPI bridge server (~/agent-system/bridge/) running on the Mac Mini behind a Cloudflare named tunnel.

The bridge manages:

  • PTY session lifecycle — spawning, killing, and reaping Claude Code processes
  • Transcript tailing — reading ~/.claude/projects/<enc-cwd>/<session_id>.jsonl by byte-offset, idempotent
  • Event ingestion — parsing stream-json output and upserting to Supabase agent_run_events
  • Authentication — HMAC JWT, per-agent allowlist, cwd traversal guard
  • Rate limiting — spawn rate limits prevent the 24-PTY overload incident from recurring (that incident caused a load of 133 on the Mac Mini, flapping the Cloudflare tunnel)

The named tunnel (bridge.jddavenport.dev) is set-once. The cockpit reads BRIDGE_URL from env; no IP address management.

The honest audit

Section titled “The honest audit”

On May 31, 2026, a five-agent parallel audit of the Nerve Center ran for several hours and produced a synthesis document that was unusually direct about what it found. Selected findings:

  • Architecture: excellent. The spine (briefing, Telegram, core-sync, health, family, CRM/projects/org pages) is real and working.
  • Purpose: ~4/10. Content and focus problem, not architecture. 6 of 8 domain pages were hollow. 18 agent entries were no-code stubs. The budget page showed April data as current. Multiple metric contradictions across pages. Qdrant was frozen for 32 days without anyone noticing.
  • Lies in the data. Token spend showed $0.00 across the board. The real number was ~$186/day. A dead Telegram daemon monitor reported green status. The CRM sync hadn’t run in hours due to a PATH regression.

The meta-finding: “95% of JD’s messages are him building the system — this is a cathedral, not a butler.” The cockpit was being watched by its own builder, not used as an operational tool.

The fixes shipped that same night (2026-05-31): real token-spend tracking, 8 fixed domain brains on the persistent-chat rail, /org crash fixes, spawn-lock class killed at root with a CI guard, budget visibility replaced with token-spend visibility.

Session lifecycle and the reaper

Section titled “Session lifecycle and the reaper”

Before the fix, the Mac Mini was running 24 live PTY sessions constantly — one for each of the 8 domains, one for the CEO, and a growing pile of ad-hoc sessions that had never been cleaned up. The load average hit 133. The Cloudflare tunnel flapped. Everything went down.

The fix: the session reaper (session_reaper.py, running every 5 minutes via cron) enforces one live session per domain. A domain brain that’s idle gets parked — the session is preserved, but the process is suspended. When a user opens a domain pane in the cockpit, the brain resumes. Boot auto-resume is disabled; the panes come alive on demand.

Result: the 24-PTY overload went to 0 active PTYs at idle. The system is now responsive instead of perpetually hot.

What the cockpit is and isn’t

Section titled “What the cockpit is and isn’t”

The Nerve Center is a window into an agent system that runs whether or not the cockpit is open. The agents run under cron and launchd; the Telegram control plane is always on; the domain heartbeats fire every hour. The cockpit shows you what happened and lets you talk to the brains. It is not the control plane itself — Telegram is.

What you do with the cockpit: spot-check domain state, review agent transcripts, see what the fleet spent today, find sessions that need your input (the “needs-you” notification surface shows working→waiting transitions and deep-links to the pane). What you do not do with the cockpit: run cron jobs, authorize money moves, change system config. Those stay in the Telegram control plane where they belong.

The cockpit is the observer. The Telegram channel is the operator’s interface.

Next: The cockpit reckoning: PTY scraping was wrong — the honest account of what the original approach got wrong and why.