● SINGULARITY CLI
A war-room, not a chat.
Race, vote, relay, and plan across multiple AI coding CLIs from a single prompt bar — with an opt-in governance layer to safely hand the machine over to agents.
Try it in 60 seconds
npx singularity-tui@latest --demo # no API keys needed singularity wizard # add your CLIs (claude, opencode, codex...) singularity # launch the room
The grammar
The first character of your prompt picks the multi-agent topology:
| Type | What happens |
|---|---|
text | dispatch to selected target pane(s) |
!text | broadcast — race every agent in parallel; live race bars |
?text | quorum vote — YES / NO / ABSTAIN tally across panes |
>N text | relay — pipe current target's last response into pane N |
>>N text | artifact-as-callable — dispatch the selected code block as prompt |
@plan goal | plan-execute — planner pane drafts steps; workers run them |
/cmd | slash command (no model call) |
Why this exists
Every AI coding CLI today picks one mental model. Chat. Or pipeline. Or swarm. Or sidebar. The mental model becomes the product.
Singularity is the bet that you actually want all of them, switchable per keystroke, in the same room, with rails that keep things safe enough to leave running.
Governance, not theater
Singularity ships a small but real trust substrate, in dependency order:
- Capability tokens — typed, scoped, expiring grants you issue with
/grant 5 exec:^npm 600. The shell pane starts with zero. - Shadow journal — every write recorded;
/rollbackreverts the whole session. - Sentinel veto — deterministic blocks on writes to
.env,.ssh/,/etc/; demands dual-key forrm -rf,git push --force,sudo. - Dual-key handoff — two distinct panes must independently propose the same action before it executes.
- Trust decay — agents earn or lose autonomy per clean exec / rollback / veto.
How it compares
| Dimension | Singularity | Claude Code | Aider | OpenCode |
|---|---|---|---|---|
| Multi-CLI orchestration in parallel | ✓ | ✗ | ✗ | ✗ |
Dispatch grammar (! ? >N @plan) | ✓ | ✗ | ✗ | ✗ |
| Cross-model quorum voting | ✓ | ✗ | ✗ | ✗ |
| Capability tokens + sentinel + shadow journal | ✓ | partial | via git | 3-state perms |
| Direct provider models (no CLI required) | ✓ | ✓ | ✓ | ✓ |
| MCP server and client | ✓ | client only | ✗ | client only |
| Themes | ✓ (8) | ✗ | ✗ | ✓ (10+) |
| HTTP server + embedded web UI | ✓ | ✗ | ✗ | ✓ |
| OS event triggers (daemon) | ✓ | ✗ | ✗ | ✗ |
| Open source (MIT) | ✓ | ✗ | ✓ | ✓ |
What you actually do with it
1. Race implementations
!implement fizzbuzz in python AND typescript
Three panes produce solutions in parallel. Race bars show progress. The artifact pane collects every code block as a numbered #N.
2. Vote on a decision
?is this PR safe to merge as-is
Each pane votes YES / NO / ABSTAIN on the first line. Live tally appears as they answer. Confidence-weighted aggregation. Cheaper than human consensus.
3. Hand off between agents
refactor the auth flow >2 now write the tests for what pane 1 produced >>3 review the code in artifact #1 for security
4. Plan and execute autonomously
@plan migrate the user table to postgres 17
Planner pane drafts JSON steps; each step auto-dispatches to the right worker pane.
5. Run the OS as a peer
/grant 5 exec:^npm (test|run lint) 1800 5 npm test
The PC pane is slot 5. Sentinel blocks dangerous patterns; /rollback reverts every journaled write since session start.
Architecture
The dispatch pipeline (the single hot path):
capability check → sentinel veto → dual-key check → shadow journal → execute → trust adjust
Every action that touches the OS goes through this. CONTROL.md for the full contract; PATTERNS.md for the 10 design patterns; architecture diagram.
Install
npm i -g singularity-tui # npm brew install singularity-tui/tap/singularity-tui # homebrew (planned) docker run -it singularity-tui # docker nix run github:singularity-tui/singularity-tui # nix npx singularity-tui@latest --demo # zero install
Open source
MIT. Contributing · Security policy · Code of Conduct · Good first issues.