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, memory, and logs are stored locally. But it also says that if you use a cloud model, the context of that request is sent to the provider you chose. 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 DeepSeek, Kimi, GLM, Qwen, Ollama, and others, OpenAI- and Anthropic-compatible interfaces are supported, and you can define a custom provider. 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 README says threads, plans, and approvals can be continued from either interface. The GUI is an Electron workbench, per the package.json description. The TUI runs in the terminal. With the desktop app running, `kun --no-start` in a project directory connects to its runtime and shares threads and approvals with the GUI; to use it on its own, quit the desktop app and run `kun`, and the TUI starts its own runtime and stops it on exit. This design has a clear advantage: you do not need to sync state between a web app and a local CLI.

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, the first-launch guide asks for an API key or a login to an existing subscription; then you open a project folder in Code or drag material into Work and give it a specific task. For the TUI alongside the running desktop app, you run `kun --no-start` in the project directory, and both share the same runtime. From source, the requirement is Node.js 22.19 or newer. The commands are `git clone --branch develop`, `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. Connecting a model is step two of the README's three-step start. 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 says tool, directory and workspace permissions require approval by default, 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 project is young: the repository shows a last push on 2026-11-02 and releases v0.4.2 to v0.4.4 between 2026-10-25 and 2026-11-01, 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 keeps sessions and memory on your machine, 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, hosted services, 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. 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 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 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 alongside a separate GUI tool, which means the two do not share a single runtime. 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 Kun's PolyForm Noncommercial license: embedding it in a commercial product requires separate written permission from the author. 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 or hosted services without that permission. 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.4.4 release for stability, since the project is young and the last push was 2026-11-02 with no long-term maintenance record.

Frequently asked questions

Official sources

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