Orkas: a local-first multi-agent desktop client where a Commander LLM dispatches specialist agents
Open-source multi-agent AI desktop client — build and command your AI agent team through conversation. A commander LLM dispatches sub-agents in parallel or in series; agents self-evolve via reflection and skill crystallization. Local-first, BYO LLM keys (Claude · OpenAI · Gemini · DeepSeek · Kimi · GLM · Qwen). macOS / Windows / Linux.
At a glance
- What is it?
- Orkas is an MIT-licensed Electron desktop app in TypeScript that turns one chat window into a coordinated agent team, with nine specialist agents bundled and model calls going directly from your machine to the provider. The main thing to verify before adopting it is whether the orchestration model fits work you would otherwise script yourself.
- Who is it for?
- Adopt Orkas if you want multi-agent orchestration without writing orchestration code, you already hold your own provider keys, and the nine bundled agents map onto work you actually do: research reports, written drafts, slide decks, office documents, code changes. Do not adopt it if you need a headless, scriptable pipeline that runs in CI, or if you require a packaged Linux installer, since the README says glibc-based Linux x64/arm64 runs from source today.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Orkas targets: orchestration without writing orchestration code
Frameworks such as LangChain and CrewAI already let you build multi-agent systems, but they assume you are writing the orchestration layer yourself, in Python or JavaScript, inside your own application. Orkas takes the opposite position. The README describes it as a local-first multi-agent desktop app that you direct through chat rather than through code, and the comparison table in the repository states this difference directly: Orkas is a desktop app you direct through chat, not a library embedded in your own program.
The audience follows from that. If your work is research, writing, slide decks, document handling, or repo-aware coding tasks, and you would rather describe a goal than wire up agent roles, tools, and handoffs, this is aimed at you. If you are building an agent system that ships inside a product, a desktop chat client is the wrong shape entirely. The project is also explicitly bring-your-own-key: the README lists Claude, OpenAI, Gemini, DeepSeek, Kimi, GLM, Qwen, MiniMax, and Doubao as supported providers, with no Orkas-run inference in the path.
How the Commander dispatches sub-agents, and where the data lives
The mechanism described in the README is a commander-and-specialists pattern. You describe a goal. A Commander LLM plans the work, handles the general parts itself, and coordinates specialist agents either in parallel or in sequence. The README's worked example is a three-step request: research the top five competitors, write it up, turn it into a deck. The Commander breaks that into steps and routes them to DeepResearcher for sourcing, ContentWriter for the draft, and PptMaker for the slides, with the finished files landing on your disk.
The nine agents that ship with the app each carry their own skills, memory, and tools: DeepResearcher, ContentWriter, PptMaker, ProductDeveloper, OfficeWorker, VideoStudio, ImageStudio, UIDesigner, and SeoGeoAgent. The README states there are thirty agents in the marketplace, and that the Commander can build a custom agent when you describe what you need.
The data flow is where Orkas makes its clearest design commitment. Conversations, files, API keys, knowledge bases, and custom agents stay on your disk, and model calls go straight from your machine to the provider rather than through Orkas servers. That is a claim about routing, not about encryption, so it is worth reading as a statement about who sits in the request path. The README also states that you can mix providers across agents, so one agent can run on Claude while another runs on DeepSeek or a local endpoint.
The self-evolution loop: reflection and skill crystallization
The repository description states that agents self-evolve via reflection and skill crystallization, and the README repeats the shorter version: each agent has its own private skills and memory, and improves through reflection after each task. That is the least specified part of the project. The material does not describe the storage format for crystallized skills, whether a skill is a prompt fragment, a tool definition, or something else, how conflicts between an evolved skill and a later task are resolved, or whether you can inspect and delete a skill an agent has written for itself.
This matters because an agent that rewrites its own operating instructions after each task is harder to reason about than one that does not. If you are evaluating Orkas for work where reproducibility matters, the honest position is that the self-evolution behavior is documented as a feature but not documented as a mechanism. The README says skills and memory are private to each agent; it does not say where they are stored or how to reset them. Treat that as an open question to answer by inspecting the app's local data directory after a few runs, not as something the public documentation settles.
Getting it running: installers, source builds, and the Linux gap
Packaged installers cover macOS and Windows. The README links Orkas-mac-arm64.dmg, Orkas-mac-x64.dmg, and Orkas-Setup.exe for Windows x64. For Linux, the README is direct: glibc-based Linux x64/arm64 runs from source today, and it points to the Quick start section rather than offering a binary. The repository is TypeScript, so a source build means the usual Node toolchain, though the README excerpt provided here does not include the actual Quick start commands, and I will not invent them.
Configuration is bring-your-own-key. You supply provider credentials for whichever of the nine listed providers you intend to use, and the README states those keys stay on your disk. Because agents can be assigned different providers, the practical setup step is deciding which agent runs on which model rather than picking one global default. The README also mentions MCP in the repository topics and describes plugging in external CLI coding agents such as Claude Code, Codex, OpenCode, and Cline, plus onboarding open-source projects like HyperFrames as local tools, all coordinated by the same Commander. Those integrations are described at the level of intent; the README excerpt does not give the configuration keys for wiring them up.
Where Orkas is the wrong tool
The clearest limitation is platform packaging. If your team runs Linux workstations and you need a signed installer rather than a source build, the README itself says Linux is a from-source path right now. That is a real operational cost: you own the toolchain, the build, and the upgrade process on those machines.
The second limitation is architectural. A desktop chat client is interactive by nature. The README frames Orkas around you describing a goal and the Commander planning it, which is a human-in-the-loop shape. If you need an agent pipeline that runs unattended on a schedule and reports into an existing system, the desktop client is the wrong layer, and a framework like CrewAI or LangChain is the better fit because the orchestration lives in your code and can be invoked headlessly.
The third is the self-evolution behavior described above. Agents that modify their own skills after each task introduce drift. The documentation does not describe a mechanism for pinning an agent to a fixed behavior, so if you need byte-identical outputs across runs, this is not the tool for that job.
How it differs from CrewAI and from hosted agent platforms
CrewAI is a Python framework for orchestrating role-playing autonomous agents, and you define crews and agents in code. Orkas puts a comparable idea, a planner plus specialists, behind a chat window and ships the specialists pre-built. The difference in practice is where the definition lives: in CrewAI your agent roles are source files in your repository, reviewable and versionable; in Orkas they are app state you configure through the interface. That trade favors speed of setup over auditability of configuration.
Against hosted SaaS orchestrators, the difference is where the data sits. The README states that on cloud agent platforms conversations, files, and API keys live on the vendor's infrastructure, whereas Orkas keeps them on your machine and sends model calls directly to the provider. That is a routing distinction, and it is the strongest concrete argument in the README for the local-first design, because it removes the vendor from the request path rather than merely promising not to look at the contents.
The README also contrasts Orkas with OpenClaw, described as a single always-on personal assistant reachable across messaging channels. Orkas is the opposite shape: a desktop application you open and work inside, with a team rather than a single assistant. The excerpt cuts off mid-sentence in that row, so the full comparison is not available here.
Licence, release cadence, and what upgrades cost you
The licence is MIT, which permits commercial and private use, modification, and redistribution provided the copyright notice and permission notice are retained. That is a permissive arrangement with no copyleft obligation on your own code. This is a description of the licence text, not legal advice; if you are embedding Orkas in a product, have counsel read the LICENSE file in the repository rather than relying on a summary.
The release history shows a fast cadence: v2026.8.11, v2026.8.25, and v2026.8.29, roughly weekly during August 2026, with the last push to main on 2026-09-09. Frequent releases cut both ways. You get fixes quickly, and you also get churn. Because the app stores conversations, files, API keys, knowledge bases, and custom agents locally, an upgrade that changes the on-disk format is the scenario to plan for. The material does not describe a migration path or a data-format version field, so the concrete thing to verify before upgrading is whether your local data directory survives the jump, which in practice means backing it up first.
The self-evolution feature adds a subtler upgrade cost: if agents accumulate crystallized skills over time, those artifacts are part of your local state, and their compatibility across versions is not documented. That is a cost you carry on every release, not a one-time setup fee.
Editorial conclusion
Adopt Orkas if you want multi-agent orchestration without writing orchestration code, you already hold your own provider keys, and the nine bundled agents map onto work you actually do: research reports, written drafts, slide decks, office documents, code changes. Do not adopt it if you need a headless, scriptable pipeline that runs in CI, or if you require a packaged Linux installer, since the README says glibc-based Linux x64/arm64 runs from source today. Before committing, verify two things on your own machine: that the provider you intend to use is reachable from your network without a proxy, and that the packaged build for your platform is current relative to the main branch.
Community notes