One runtime instead of five AI tabs
Kun tries to make an AI task feel like a piece of work rather than a chat transcript. Its desktop GUI and terminal TUI connect to the same kun serve process, sharing threads, plans, approvals, provider settings, usage, and background jobs. A developer can begin in a visual workspace, continue from a terminal, and inspect the same changes and evidence. That continuity is Kun's strongest idea.
The scope is much broader than coding. Separate Code, Write, Design, and Research spaces can produce source changes, Markdown, PDF, DOCX, editable presentations, HTML prototypes, and structured notes. Scheduled jobs, loops, hooks, skills, extensions, MCP integrations, browser control, and subagents push it toward a general personal automation environment. People who currently shuttle context among an editor agent, document tool, research chat, and terminal can see the appeal.
Breadth also creates risk. Every additional surface needs consistent permissions, provider behavior, persistence, recovery, and documentation. Kun is at version 0.2.37, and its advanced Agent Graph is explicitly experimental. Treat the product as an energetic early platform, not a finished replacement for several established applications.
The workflow has useful discipline
Kun organizes work from requirements through a plan, execution, review, testing, and acceptance. Plans and requirements can live inside the project, so they can be versioned rather than disappearing into an account's chat history. File diffs, tool output, tests, browser actions, and review findings remain beside the task. This helps a human determine whether the agent actually completed the work.
Direct mode handles focused tasks. Agent Graph lets a lead agent build a dependency graph, assign bounded subagents, request evidence, trigger rework, and approve handoffs. The documentation says child agents inherit only the files, tools, network access, skills, and MCP permissions allowed by the parent task. It also says nodes need real validation and explicit acceptance before downstream delivery. Those are sensible constraints, although the experimental label should govern expectations.
Model choice is broad. Kun describes subscription logins, coding and token plans, direct APIs, OpenAI-compatible and Anthropic-compatible services, and self-hosted models. Presets cover many popular ecosystems. A preset does not guarantee account access, regional availability, quota, or full protocol compatibility, and the README says so.
Local-first needs careful interpretation
Sessions, preferences, logs, and runtime data stay on the machine by default. Prompts, attachments, and task context still go to a cloud provider when the selected model is remote. Local storage therefore improves control over the workspace record, but it does not make cloud inference private. Users handling client material must check the chosen provider's terms and understand exactly which tools can read which directories.
Current issue 1152 makes storage management a practical concern. A Windows 11 user reports that v0.2.37 consumed more than 10 GB after over a day of heavy use, apparently through repeated full backups retained for three days. The same report says an attempted storage migration damaged configuration and lost sessions. One report does not establish universal behavior, but anyone running long or token-heavy tasks should watch disk growth and back up important workspace state before moving it.
Tool approval matters just as much. Terminal commands, browser control, file edits, schedules, and remote MCP tools can all produce durable effects. A local runtime limits where the coordinator lives, not what an approved tool can reach. Start with a disposable repository, narrow filesystem access, review diffs, and avoid unattended schedules until the permission model is familiar.
Provider flexibility still has edges
Issue 1151 reports that a provider's default model overrides the model selected for a subagent in v0.2.37. That undermines cost and capability controls in multi-agent work: a carefully assigned cheaper model may never be used. Issue 1150 reports GLM 5.1 and 5.2 requests failing with an unknown thinking.clear_thinking field because one reasoning configuration is being applied across differing model APIs. These are precise, current compatibility faults, not vague complaints about AI quality.
The upside is visible maintainer speed. Release 0.2.37 was published August 7, 2026, and the repository was pushed again on August 12. Open issue and pull-request count was six, while new reports and a memory-control pull request were receiving same-day activity. The latter says declared limits and scope allowlists for memory injection had not actually been read at several call sites, then adds tests for the correction. That is healthy response work, but it also illustrates how quickly configuration promises and runtime behavior can diverge.
The license changes the recommendation
GitHub cannot identify the license with a standard SPDX value because Kun uses PolyForm Noncommercial 1.0.0 plus project-specific notice text. Personal research, study, experiments, education, and qualifying noncommercial organizations have broad permission. Commercial use, SaaS, hosted services, resale, distribution, and integration into commercial products require a separate written commercial license. Internal enterprise productivity use also requires written authorization, even though the notice says that authorization can be free.
That makes Kun source-available, but not open source under the usual commercial-use definition. A developer can inspect and modify it for allowed purposes; a company cannot quietly standardize on it merely because the repository is public. Get the required permission in writing before a workplace pilot.
Should you use Kun?
Kun is worth watching because the shared local runtime gives its many modes a believable center. The documentation is unusually clear about cloud data flow, experimental orchestration, model availability, and licensing, with a complete English track alongside the Chinese-first README. Desktop packages reduce the initial friction, while source development requires Node.js 22.19 or newer.
For a personal project, install it in a contained workspace, connect one provider, and test a bounded task while watching disk use and approvals. For business adoption, the answer is no by default until licensing is settled and current storage and provider-routing bugs are verified fixed. Kun's direction is compelling; its present release still asks users to participate in stabilization.