A fleet of agents. One operator.Without giving up control.
Juggling raw terminal sessions, most people top out at six or eight concurrent agents. Panopticon runs each agent in its own container and tmux session, sorts the ones waiting on your judgment to the top, and lets one person run 3× as many.
$ pipx install panopticon-appArtifact
Watch everything. Touch only what needs you.
Every row is one agent, in its own container and tmux session. The turn column is the whole discipline: amber means an agent came back with something only you can decide (red ⚠ if it's hard-blocked); green means it's working; leave it alone. Press t to attach to a session, decide, detach. Two rows need you; the other twenty-four keep working.
panopticon · dashboard
⭘ panopticonstate turn container repo slug[memo]ITERATING user ⚠ live webapp slow-dashboard-query[investigate slow query]PLANNING user live webapp api-rate-limiting[add rate limiting to API]ORCHESTRATING agent live webapp billing-refactor[split refactor into tasks]REVIEW agent live webapp fix-checkout-flake[fix flaky checkout test]MERGING agent live webapp payment-retry-logic[babysitting merge queue]ITERATING agent live docs update-getting-started[refresh setup guide]PLANNING agent live infra rotate-stale-tokens[rotate expiring tokens]REVIEW agent live webapp search-index-rebuild[rebuild stale index]t Attach n New task x Drop / Search d Detail ? Help active agents 23/26
How it works
Isolation by default
Every task gets its own Docker container and its own git branch. Agents cannot step on each other, or on you.
Supervision by exception
Tasks whose turn flips to you rise to the top of the dashboard in amber. One keystroke attaches you to that agent’s live tmux session; detach and you’re back over the fleet.
Built-in workflows: PRs, orchestration, open research
Each task declares a lifecycle. PR workflows walk plan → iterate → review → merge (peer-reviewed, self-reviewed, or local-only): you approve each stage and the agent babysits CI and the merge. Spikes run ungated for open-ended research. The orchestrator turns one goal into a batch of new Panopticon tasks, each arriving pre-planned — you review plans instead of writing tasks.
A control plane that never calls a model
The runner, task service, and dashboard are deterministic. Every LLM token is spent inside an isolated, per-repo-credentialed task container.
Quickstart
Install it, point it at a repo, start the fleet.
terminal
$ pipx install panopticon-app$ cd ~/code/my-project # the repo you want agents to work on$ panopticon quickstart # checks prereqs, mints a repo token, opens the dashboard
Runs locally with Docker and tmux. Drives Claude Code today; other agent CLIs are on the roadmap.
Or let your agent run the fleet.
The dashboard is one client of Panopticon's HTTP API; the agent you already work in can be another. The easiest first run is to ask your harness to farm its next batch of subtasks out to Panopticon: you watch each delegated task on the dashboard instead of losing them in one agent's transcript, and the agent gets a system for organizing its own work.