Kun: A local-first agent workspace that shares one runtime between GUI and TUI

What Kun actually solves

The local-first claim needs a precise reading. The README says sessions, preferences, logs, and runtime data are stored locally by default. But it also says that if you choose a cloud model, prompts, attachments, and task context are sent to that provider. So "local-first" does not mean offline-only. It means the workspace and its metadata stay on your machine, while model calls may leave it. That distinction matters for anyone handling sensitive code or documents. The project does not force a single model vendor; presets cover ChatGPT, Claude, Gemini, Ollama, DeepSeek, and others, and you can configure custom OpenAI-compatible or Anthropic-compatible endpoints. The practical benefit is that you can keep the agent's planning and file operations local while choosing a model that fits your privacy or cost needs. The README is explicit about this trade-off, which is more honest than many tools that call themselves local without clarifying network use.

One runtime, two interfaces: how the architecture works

The core architectural bet in Kun is that a single runtime can serve both a desktop GUI and a terminal TUI. The README describes a local `kun serve` runtime that both interfaces connect to. This is different from building a separate CLI that talks to a remote service. The shared runtime means tasks, plans, approvals, and background jobs are not duplicated across interfaces. The README gives an example workflow: you clarify a goal, the agent forms a plan, it executes with tools, it checks evidence, and it delivers or continues. Plans and requirements can be saved inside the project, so they can enter version control and be restored later. That is a concrete mechanism for auditability. The GUI is built on Electron and React, based on the repository's package.json and topics. The TUI runs in the terminal, and from version 0.3.8 the project no longer distributes a separate TUI archive; you use the desktop app's built-in terminal command to launch it. The exact command is `kun` in a project directory. This design has a clear advantage: you do not need to sync state between a web app and a local CLI. But it also means the TUI is not a standalone tool. If you only want a terminal agent, you must install the desktop application. That is a constraint worth noting for terminal purists.

Getting Kun running: commands and configuration

The fastest path is downloading a release from GitHub Releases. The README lists .dmg and .zip for macOS (Apple Silicon and Intel), .exe for Windows x64, and .AppImage or .deb for Linux x64. After installation, you choose a language, configure a model provider (subscription, plan, API, or custom), open a local project or create a workspace, and send a task. For the TUI, you run `kun` in the project directory. The desktop and TUI can connect to the same runtime simultaneously. From source, the requirements are Node.js 22.19 or newer, npm, and at least one working model connection. The commands are standard: `git clone`, `cd Kun`, `npm ci`, then `npm run dev` for the Electron app or `npm run dev:tui` for the terminal TUI. Other npm scripts cover typecheck, lint, test, build, and platform-specific distribution packages. For slow networks in China, the README suggests an npm mirror registry. Configuration keys are not shown in the README; you must consult the model provider documentation at docs/model-provider-presets.md. The setup is not turnkey. You need a model API key or subscription before anything works. The README says "at least one available model connection," which is a hard prerequisite. Without a model, Kun is an empty shell.

What the README does not tell you

The README is long on features and short on operational details. It does not specify how the agent executes commands, whether it uses a sandbox, or how it handles destructive operations like deleting files. It mentions tool permissions and sensitive operations are "clearly presented" in the interface, but it does not describe the approval workflow in depth. There is no mention of resource limits, such as maximum task duration, memory usage, or concurrent task handling. The release notes for 0.3.7, 0.3.8, and 0.3.9 are not included in the provided material, so we cannot confirm bug fixes or stability improvements. The project is young: the repository shows a last push in September 2026 and releases in August and September 2026, indicating rapid iteration but also a short track record. There is no stated support policy, no migration guide for upgrading between versions, and no documented backup procedure for the local runtime data. For a tool that stores plans and approvals in your project, that is a real gap. If a future version changes the data format, you may not have a clear path to recover old tasks.

License and maintenance costs that shape adoption

The license is PolyForm Noncommercial 1.0.0. The README is direct: use is limited to learning, research, and noncommercial purposes. Commercial use, distribution, SaaS or hosting, resale, or integration into commercial products requires separate written permission from the author. That is a hard boundary. If you are an engineer at a company evaluating Kun for internal tooling, that counts as commercial use in most interpretations, so you need that written permission. The repository metadata shows the license field as NOASSERTION, which means the GitHub API did not recognize the license identifier, but the README and the badge clearly state PolyForm Noncommercial. This mismatch is a warning sign: the project has not yet updated its package metadata to reflect the actual license. For contributors, the project requires a CLA before external contributions are accepted. That is a legal overhead that some open source contributors avoid. Maintenance cost is not documented. There is no stated release cadence, no security policy, and no list of known issues. The project has a develop branch for integration, and PRs should target that branch. But there is no information on how long the maintainers intend to support the project or how breaking changes are communicated.

Where Kun is the wrong tool

Kun is the wrong choice if you need a purely terminal-based agent without a desktop dependency. Since version 0.3.8, the TUI is not distributed separately; you must run it through the desktop app. That adds a heavy Electron layer to what could be a lightweight CLI workflow. It is also wrong for commercial work unless you obtain a separate license, which the README says requires the author's written authorization. That process is undefined, so commercial adoption carries legal uncertainty. For teams that already use a specific agent framework like LangChain or a specific coding agent like GitHub Copilot, Kun's value proposition is unclear. It does not claim to integrate with those ecosystems. It has its own extension platform, MCP support, and Skills, but the README does not describe how those compare to existing standards. Another wrong case is when you need strict data isolation. Kun sends task context to cloud providers if you choose them; only a fully local model like Ollama would keep everything on your machine. The README does not guarantee that local models are equally capable for all tasks. If your work involves sensitive data and you cannot use a local model, Kun is not a safe default.

A real alternative: separate GUI and CLI agents

A direct alternative is to use a dedicated coding agent in the terminal, such as the open source project OpenHands (formerly OpenDevin), which runs as a CLI or a web interface but does not share a single runtime between a desktop GUI and a TUI. The difference in approach is that OpenHands treats the terminal as the primary interface and does not offer an Electron-based GUI for the same session. Another alternative is to use a GUI-only agent like Cursor for coding and a separate document tool like Notion AI for writing, but then you have two disconnected systems. Kun's advantage is the shared runtime, which eliminates session fragmentation. The trade-off is that Kun is a single project with a specific license, while OpenHands is MIT-licensed and allows commercial use. If you need a terminal-first agent that can be embedded in a commercial product, OpenHands is more permissive. If you value a unified interface for both code and documents and you can live with the noncommercial license, Kun offers something that separate tools do not. The comparison shows that Kun's differentiation is not raw capability but the integration of GUI and TUI on one local runtime.

Editorial conclusion

Adopt Kun if you need a local-first agent workspace that unifies GUI and TUI on one runtime and you work on noncommercial projects, because the PolyForm Noncommercial 1.0.0 license forbids commercial use without separate written permission. Do not adopt it for commercial product integration, SaaS, or resale. Before adopting, verify the license terms with your legal counsel, confirm that your model provider's data policy matches your privacy needs, and test the 0.3.9 release for stability, since the project is young and the last push was September 2026 with no long-term maintenance record.

Official sources

1. Issues
2. KunAgent/Kun on GitHub
3. Project website
4. README
5. Releases