Kimi Desktop's First Upgrade Is an Approval Check • The Weighted Average

Teams piloting Kimi Code Desktop should update and test approvals before expanding background work: version 1.0.2, dated September 19, fixes subagent approval and question requests not being surfaced. A full acceptance matrix across the 3 published desktop download targets and 3 permission modes has 9 combinations—a proposed test scope, not nine confirmed defects or nine independently verified configurations.

The important feature is the decision you can see

The desktop client puts the Kimi Code agent into a project-oriented graphical interface. Its quick-start guide describes sessions, file changes, tool activity, and a built-in terminal. The built-in browser shares page context with the agent and keeps tabs with the session. This is useful for engineers who want the page, the change, and the verification step together, rather than a claim that a graphical shell improves the underlying model.

The September 19 update makes supervision more concrete. Its changelog adds live browsing activity in the transcript, grouped summaries with sources, and a visual signal while the agent controls a tab. It also fixes page capture when the window is hidden or minimized. These changes matter to anyone supervising work that moves between code and a browser: an interface should show what the agent is doing and surface the decisions reserved for the user.

The approval fix deserves a narrow reading. Moonshot says requests were not being surfaced; the changelog does not establish whether every affected task stalled, continued, or behaved differently in each configuration. Do not infer unauthorized execution from an interface bug description. Equally, do not infer effective oversight merely because the new release says the display path is fixed. Reproduce the approval interaction on the workflow the team plans to use.

The test-matrix arithmetic combines separate official documents. The what’s-new page provides macOS Apple Silicon, macOS Intel, and Windows downloads. The quick-start guide names Always Ask, Ask When Needed, and Never Ask. Three build targets multiplied by three permission modes equals 9 configuration combinations for complete coverage of that stated matrix. A team using fewer targets should narrow it; each additional provider or plugin adds a separate dimension rather than being silently certified by those nine cells.

This is not a recommendation to exercise unrestricted authority against real systems. Test the expected permission behavior with harmless, reversible actions in an isolated project. Verify both the parent session and a subagent request. For an unfamiliar project, Moonshot itself recommends Always Ask. Never Ask deliberately removes proactive approval prompts and should not become a workaround for a supervision interface that the organization has not validated.

The release chronology is compact. The official changelog dates versions 1.0.0 and 1.0.1 to September 17 and 1.0.2 to September 19. AgentRiot’s desktop coverage distinguishes the app from a new model release, and notes the absence of a Linux download on the listed page. The relevant procurement question is whether this client improves review on supported machines—not whether installing it creates a new model entitlement.

One window still draws from the shared allowance

Billing stays outside the desktop metaphor. The membership documentation says CLI, VS Code, Desktop, and third-party tools count toward the same quota. It also distinguishes new plans, which remove the weekly rate window, from legacy plans that retain it. Both retain a rolling 5-hour rate window and a monthly total quota. “No weekly limit” is therefore not an unlimited-compute statement.

The same guide describes Extra Usage as a shared fallback balance and says a monthly spending cap must be enabled to impose that cap. The desktop quick start also permits third-party providers through an API key, base URL, and model configuration. Those routes should be budgeted and governed separately; connecting a provider does not make its traffic part of an assumed free desktop allowance. The retrieved desktop pages do not establish a separate universal desktop subscription price.

Our earlier Kimi K3 analysis separated model economics from operational freedom. The desktop release adds an interface choice, not a reason to reuse old model-price calculations indiscriminately. The account’s current entitlement, selected model, and provider determine what the agent can access. Confirm those settings in the app rather than treating a familiar brand name as a stable cost contract.

The cost of a pilot is modest in scope but real in work: installing the supported client, reviewing shared local configuration, checking provider credentials, and comparing accepted changes with the existing workflow. Moonshot says the desktop and CLI share some account, model, provider, and plugin settings. A reviewer should identify that shared scope before changing a working CLI setup. Convenience is valuable when it reduces context switching without creating configuration surprises.

The strongest adoption case is visual work that benefits from seeing browser context, diffs, and verification output together. The strongest case for waiting is a team already comfortable with a scripted CLI path, unsupported hosts, or a policy requiring controls that have not been demonstrated in this client. The release notes provide no independent productivity benchmark, so no percentage improvement in engineering output can be claimed from the new window.

Evidence that would change the verdict is straightforward: required approvals appear consistently, rejected actions remain rejected, background work preserves visible status, and accepted changes take less total review effort. Repeated missing decisions or unclear provider spending would justify pausing rollout. The approval test is not a permanent objection; it is the shortest path from a promising release note to a client the team can responsibly adopt.

Today’s AI Employees lead argues for proving the surrounding runtime before scheduling a fleet. Apply that principle here. Upgrade an existing desktop pilot to the documented fix, keep authority narrow, and validate the exact supervisory path. A window earns its place when it makes the operator’s decisions clearer—not merely when it makes agent activity more visible.