Orkas and the Two OpenBots: Three Paths for Desktop Agents and Three Trust Models
Search GitHub for "OpenBot" and you get two completely unrelated projects. Add Orkas, and all three sound nearly identical in their user stories: local-first, multi-agent, their own workspace, connected to your coding tools, no cloud data.
But reading the source reveals they are not three versions of one product — they are three incompatible architectural answers.
> Repository snapshot date: 2026-11-01. All figures below are from local measurement (lines counted over *.ts/*.tsx/*.js, excluding build artifacts).
---
1. First, untangling the names
| Path | Actual repo | Publisher | Form | License |
|---|---|---|---|---|
| Orkas/ | Orkas-AI/Orkas | orkas.ai | Electron desktop app | MIT |
| nightly-lab-openbot/ | nightly-labs/openbot | Individual/small team | Electron desktop + self-hosted server + mobile + Web | PolyForm NC |
| OpenBot/ | CopilotKit/openbot | CopilotKit | Docker/Postgres self-hosted platform, browser-first | MIT |
The third is not a "desktop assistant" — it is an AI-coworker platform for company deployment. It shares no ancestry with the other two; the name collision is a coincidence.
---
2. Three paths: who owns the agent loop
This is the most fundamental divide among the three.
Orkas: builds its own loop.
src/core-agent/ is a standalone harness extracted from the OpenClaw core modules, connecting to models via @earendil-works/pi-ai. runner.ts is 220 KB, session.ts 155 KB, plus layered context compression budgets, loop guards, persistent sessions, execution plans, and workspace state. The toolchain is built in: files, shell, process sessions, run_program (quickjs sandbox), web scraping, memory, metacognition.
nightly OpenBot: borrows the loop. It doesn't write loops; it writes adapters. Codex App Server, Claude Agent SDK, Grok, ACP (OpenCode/Gemini/Cursor/Cline), Pi, and Muse are all execution endpoints; OpenBot itself exposes only about 11 direct tools, injected through an MCP bridge. Its moat lies elsewhere: mailboxes, queues, parking slots, approvals, cross-device support.
CopilotKit OpenBot: wants only the protocol. Any AG-UI endpoint is a Bot. The repo contains 16 framework samples: LangGraph, Mastra, CrewAI, ADK, Pydantic AI, Claude SDK, LlamaIndex, and more. It deliberately does not own the loop, because its product is governance, not intelligence.
One-line summary:
> Orkas sells capability, nightly sells orchestration, CopilotKit sells constraints.
---
3. Same question, three answers: who decides it can act
This is the most interesting part of the comparison.
| | Control point | In one sentence | |---|---|---| | Orkas | User settings | Three permission tiers + per-action popups; risk borne by the user | | nightly OpenBot | Agent configuration | Each teammate has an access tier and approval mode | | CopilotKit OpenBot | Gateway | Target resolution → CEL policy → audit write → only then execute |
CopilotKit's gateway is fail-closed: an empty policy denies, deny is evaluated before allow, and broken rules deny rather than open up. Every bot runs in its own container (Chromium + shell + workspace), egress traffic goes through a filtering proxy, and gVisor can be enabled.
One design the other two should copy: audit rows carry initiator_kind, distinguishing person / routine / responsibility / memory / handoff, with a "Nobody watching" filter directly in the UI.
It answers not "who authorized this" but "who is acting in my name while I'm away" — a question that grows more important in an era of scheduled jobs and agents delegating to each other.
nightly's docs default the CLI to danger-full-access (the README flags the warning itself); Orkas defaults to "full disk access, but sensitive actions require approval." All three trade-offs are honest, but for auditability, only the third holds up.
---
4. Comparison table
| Dimension | Orkas | nightly OpenBot | CopilotKit OpenBot | |---|---|---|---| | Delivery | Electron desktop | Desktop + server + mobile + web | Docker/Compose/Helm; desktop is just a Tauri installer shell | | Agent kernel | Full in-house loop | Host: external CLIs are the engines | Protocol host: any AG-UI endpoint is a bot | | Data | Filesystem JSON/JSONL | Single SQLite (48 migrations) | PostgreSQL + pgvector; sessions/memory in CopilotKit Intelligence | | Collaboration | Single-session group chat: @ mentions + Commander decomposition + task board | Resident teammates + Mailbox/queues + channels + workflow DAG | Bots (coworkers) + channels + team publishing + Responsibilities | | Isolation | In-process sandbox | Workspace limits + browser profiles | One container per person/bot | | Frontend | Handwritten ES modules, no framework, no bundler | SolidJS 2 RC + Vite | React 19 + TanStack + shadcn | | Code size | src 330k / test 350k lines | ~860k lines across three locations | ~470k lines | | Tests | 936 unit + 136 e2e; CI has only 2 jobs | 58 vitest + ~230 on-device e2e; CI 16 jobs | 716 bun tests; CI 6 jobs | | License | MIT | PolyForm NC | MIT |
---
5. Each one's soft spots
Orkas has the most complete deliverable pipeline (video, voiceover, images, Office, e-commerce, site building), but it piles complexity into single files: bus.ts at 552 KB, conversation.js at 825 KB. The main process is not bundled — the package ships tsx and transpiles TypeScript at runtime. CI has only 2 jobs; the 936 tests run locally, and regression relies mainly on manual checklists.
nightly OpenBot has turned the "agent team" into full infrastructure: mailboxes, parking slots, steering, an approval center, Team API capability negotiation, iOS/Android, a self-hosted server. The cost is heavy dependence on external CLIs' versions and behavior — the docs are full of patches like "Codex dynamic tools are fixed at session creation" and "ACP can only do notes," plus a dedicated provider-CLI canary pipeline watching for breakage. Technically it's very前沿: Solid 2 RC, Effect 4, TS 7.
CopilotKit OpenBot has the hardest governance and the most open framework, but it is at v0.2.0, self-described as beta and "a template, not a product." The dependency chain is long: Docker + Postgres + CopilotKit Intelligence (self-hostable, but licensed). Within its "own your infrastructure" narrative, sessions and memory actually live in Intelligence — its softest spot. The configuration surface is also enormous: configuration.md is 92 KB.
---
6. How to choose
- Working alone, want finished products → Orkas.
- Individual/small team directing a squad of coding agents, with mobile and remote access → nightly OpenBot.
- Company-wide multi-user deployment needing "auditable agents" → CopilotKit OpenBot.
- Building your own product on top: Orkas and CopilotKit are MIT; nightly requires negotiating a license.
- Orkas — https://github.com/Orkas-AI/Orkas
- OpenBot (nightly-labs) — https://github.com/nightly-labs/openbot
- OpenBot (CopilotKit) — https://github.com/CopilotKit/openbot
---
7. If you had all three, what should each copy
1. Orkas should copy the gateway: upgrade "three tiers + popups" into a writable, replayable policy layer. The initiator concept would directly fix its blind spot where scheduled jobs get the same permissions as a person at the keyboard.
2. nightly should copy container isolation: it currently gives CLIs full permissions, while CopilotKit proves that "one container per bot + egress allowlist" is engineering-feasible.
3. CopilotKit should copy deliverable capability: it stops at browser + files + React components, with no video/Office pipeline — exactly Orkas's moat.
4. All three handle "unattended operation" in ways worth cross-checking: nightly's silent run + failure reporting, CopilotKit's fatigue rule (10 consecutive failures triggers auto-shutdown), Orkas's automatic project advancement. Three answers to the same question.
---
Closing
All three projects solve the same sentence: keep agents working continuously, rather than vanishing after answering one question.
The difference: Orkas believes "a stronger engine can govern itself," nightly believes "a good scheduler can make other people's engines cooperate," and CopilotKit believes "autonomy without constraints isn't worth trusting."
All three beliefs hold. The first question you must answer isn't "which has more features" but "how much decision-making power am I willing to hand over, and to whom."
---
Repositories