Kilo Code’s most revealing signal is a mismatch. ToolVitals records 2,194 GitHub commits in the last 30 days, 30 GitHub releases in 90 days, a shipping score of 99, and a health score of 98. Yet the same snapshot reports 0 release events in the last 30 days. The supplied event list ends with v7.4.23 on August 20, 2026, while the local fact-check snapshot was generated on September 22. That does not describe a dormant project. It describes a codebase with heavy visible activity whose recent work is gathering around agent sessions, worktrees, terminals, and pull-request review rather than only chat responses.

Kilo’s product is an agent surface, not just an editor plugin

The official Kilo site presents Kilo as an open source AI coding agent for VS Code, JetBrains, the CLI, and cloud workflows. Its central product claim is one agent across the places where developers work. The site also describes access to more than 500 models, local-model support, and the ability to inspect prompts, context, and agent decisions in MIT-licensed source.

The GitHub repository describes the same product in more operational terms. It lists code generation across multiple files, inline autocomplete, self-checking, terminal and browser control, an MCP marketplace, and model switching during a task. It also documents specialized modes named Code, Plan, Ask, and Debug, along with support for custom agents.

That combination matters. Kilo is not positioning itself as a single completion box inside an editor. It is trying to keep the same agent state available across an IDE, a command line, and managed cloud workflows. The repository also identifies Kilo CLI as a fork of OpenCode, which helps explain why the project includes both Kilo-specific product surfaces and upstream core changes.

The repository documents kilo run --auto for unattended operation in CI/CD. The same documentation says that this mode auto-approves permission prompts unless a rule explicitly denies the action and should only be used in trusted environments. That warning is more useful than the feature label. Autonomous execution is a control-plane decision, not just another convenience feature.

ToolVitals classifies Kilo as OSI-approved open source and labels the license MIT. The repository also includes an MIT license statement. That establishes the source-availability and reuse terms. It does not establish that the agent is accurate, safe by default, or suitable for production automation.

What the ToolVitals metrics actually show

The ToolVitals snapshot gives Kilo a hot score of 226.5, a health score of 98, a shipping score of 99, and an overall ToolVitals score of 98. The data confidence value is 90. On GitHub, the project has 27,380 stars, 2,194 commits in the last 30 days, 30 releases in the last 90 days, and 12 active contributors. The release-events count for the last 30 days is 0.

These numbers support a narrow conclusion. Kilo has strong public repository activity and a substantial recent release history, while the latest measured release window contains no counted release event. The 0 does not mean that development stopped. The commit count makes that clear. It means the public release cadence and the repository’s current work are not moving in lockstep in this snapshot.

The 2,194 commits deserve careful handling. A commit is not a feature, a fixed bug, or a successful user task. It can be a small change, an upstream synchronization, or a maintenance update. Kilo’s repository says its CLI is a fork of OpenCode, and the v7.4.22 notes include a long list of upstream OpenCode changes. ToolVitals does not separate Kilo-authored work from upstream integration in the commit total.

The 27,380 stars are a cumulative attention signal. They do not show how many developers use Kilo today, how often they use it, or whether they keep it installed. The 12 active contributors describe measured activity in the relevant window, not the full maintainer group, the distribution of ownership, or the project’s bus factor.

The health score of 98 and shipping score of 99 are useful dashboard signals, but the payload does not expose their formulas. They should not be read as test pass rates, uptime, or a guarantee of code quality. ToolVitals can measure visible project evidence. It cannot turn those measurements into proof that Kilo’s agent behavior is correct.

The release notes show a move toward coordinated agent work

The recent first-party releases make the product direction clearer than the headline description does. In v7.4.23, Kilo added display settings for the default open or collapsed state of MCP and generic tool blocks. That is a small interface change, but it addresses a real problem in long agent sessions: tool output can overwhelm the working context.

The same release substantially reworked pull-request review comments in Agent Manager. Resolved threads now collapse into a dedicated group, replies are visible, and review cards expose actions such as sending comments to the agent, resolving them, copying content, opening the file, and opening the discussion on GitHub. Unresolved comments can be sent to the agent as structured review comments rather than pasted text. This is a shift from showing an agent transcript to managing an engineering workflow around it.

The v7.4.23 release also added delegated subagent sessions to Agent Manager inspector tabs. Other changes in the release address project loading, terminal context, branch selection, worktree state, streamed assistant text, and session lifetime. Taken together, these changes focus on keeping many concurrent pieces of agent work understandable and recoverable.

v7.4.22 added clickable file references when an inline code span matches a real file in the workspace. It also added pull-request comment actions, exposed model reasoning variants, improved AWS and Google Cloud credential inputs, and corrected permission handling between parent and delegated subagents. The release notes also list upstream core work covering MCP code mode, provider routing, reasoning settings, and model-specific behavior.

v7.4.21 pushed Agent Manager further into daily use. It improved terminal keyboard navigation, repository selection for multi-project worktrees, model catalog browsing, review slash commands, and session setup. It also reduced background Git polling, deferred file indexing until search is used, and reduced unnecessary file watchers. Those are not flashy additions. They target the cost of operating several agent sessions at once.

The JetBrains releases point in the same direction. The JetBrains 7.1.0-rc.2 release adds an Agent Manager beta for creating, opening, organizing, renaming, and deleting worktree-based tasks and sessions from the IDE. It adds worktree activity, change, ahead or behind, and pull-request badges, plus options to open worktrees in new windows or dedicated terminal tabs. Because this is a release candidate and the feature is explicitly labeled beta, teams should treat it as an evaluation surface rather than a settled interface.

The earlier JetBrains 7.0.15 release adds editor context to prompts, including the active file, visible files, selected text, and shell context when available. It also makes attached files and selections visible as prompt attachments. JetBrains 7.0.16 focuses on download reliability, transient failure retries, and keeping the plugin’s Kilo Core version aligned. The 7.0.13 release adds clearer diff rendering, more reliable file attachments, reduced watcher activity, and better handling of SQLite locks.

The visible roadmap is coordination, not just generation

Kilo does not publish a formal roadmap in the supplied material, so this is an interpretation of the release sequence rather than a roadmap claim. The repeated appearance of Agent Manager, worktrees, delegated sessions, pull-request comments, terminals, model catalogs, and project-level state points toward an orchestration layer for software work.

The underlying problem is coordination. An agent that edits one file is easy to understand. Multiple agents operating in separate worktrees, opening terminals, receiving review comments, and handing off sessions create state that must be displayed, synchronized, and cleaned up. Kilo’s recent releases spend more effort on that state than on basic code generation.

This direction also explains the importance of the JetBrains work. Supporting VS Code alone would let Kilo optimize one surface. Adding JetBrains Agent Manager, editor context, CLI pinning, and worktree controls suggests an attempt to preserve the same workflow model across different developer environments. Whether that model works well is still an empirical question, but the product direction is visible.

What ToolVitals cannot tell you

ToolVitals can report repository activity, stars, contributors, releases, license signals, and public project evidence. It cannot tell you whether Kilo produces correct patches, understands a large codebase, handles ambiguous requirements, or recovers well after a failed tool call. It also cannot measure user satisfaction, revenue, support quality, or production adoption from the supplied metrics.

The official site advertises local models and code privacy, but the supplied excerpt does not provide an independent security review, a detailed threat model, telemetry findings, or an audit of data flows. Those questions require separate technical validation. The MIT license tells you how the source may be used and distributed. It does not guarantee that every hosted or connected service has the same properties as the repository.

The release notes show fixes and feature work, but they do not report task-success rates, regression rates, latency, or model evaluation results. A high shipping score can coexist with a frustrating product if new changes create instability. A quiet release window can also be healthy if the team is consolidating work before publishing it. The snapshot cannot resolve that distinction.

Do not confuse the data confidence score of 90 with a product quality score. It describes confidence in the ToolVitals snapshot, not confidence that an autonomous coding session will make a safe change.

How Kilo compares with nearby developer tools

The related_tools data places Kilo’s hot score of 226.5 near two much larger developer-tool projects. Hermes Agent has a hot score of 229.5 and 247,648 GitHub stars. OpenClaw has a hot score of 224.5 and 390,185 stars. Kilo’s 27,380 stars are far below both counts, yet its hot score is in the same range.

All three entries have a shipping score of 99 and 0 release events in the last 30 days in the supplied data. The comparison shows why hot scores and stars should not be collapsed into one popularity claim. Kilo’s public activity signal is strong relative to its cumulative star count, but these figures do not establish that it has the same user base, feature scope, or operational maturity as either related project.

What a skeptical buyer should test

A team evaluating Kilo should start with the read-only modes documented in the repository. Use Ask to test codebase questions without file changes and Plan to test whether the agent can produce useful implementation plans before it edits anything. Then move to Code inside isolated worktrees, where the team can inspect diffs, run its own tests, and verify that Agent Manager keeps sessions and repository state understandable.

The next test should cover the workflow Kilo’s recent releases emphasize: import a pull request, send structured review comments to an agent, open referenced files, delegate a bounded task, and recover from a failed terminal or provider call. Teams using JetBrains should treat Agent Manager in 7.1.0-rc.2 as beta. Teams considering kilo run --auto should use a trusted, isolated environment and verify permission rules before allowing unattended execution.

Measure patch correctness, test pass rate, review usefulness, context leakage, recovery behavior, and operator workload. Those measurements answer the questions ToolVitals cannot. The repository metrics justify a serious evaluation. They do not justify skipping one.

What maintainers should make legible

For maintainers, the main opportunity is to connect the project’s high internal activity to a clearer external release story. A snapshot with 2,194 commits in 30 days, 30 releases in 90 days, and 0 release events in the latest 30-day window can look contradictory to someone discovering the project. Clear separation between core, VS Code, JetBrains, CLI, and beta release streams would help readers understand what is stable and what is still moving.

The changelog should keep explaining upstream OpenCode changes alongside Kilo-specific behavior, especially where provider support, permissions, MCP execution, and model routing affect safety or compatibility. The project would also benefit from publishing outcome measures around Agent Manager, worktree reliability, and autonomous runs. Repository velocity is already visible. The missing evidence is whether that velocity produces dependable engineering results.

Recommendation

If your team wants an MIT-licensed open source coding agent that spans VS Code, JetBrains, and the CLI, evaluate Kilo in a controlled pilot. It is a particularly relevant candidate for teams managing parallel agent tasks, worktree-based development, and pull-request review inside one workflow, because those are the areas receiving repeated recent changes.

Do not select it because the star count is large or because ToolVitals assigns a 98 overall score. Select it if Kilo passes your own tests for patch quality, permissions, context handling, and recovery. Keep autonomous mode confined to trusted environments until those tests show that its operational controls match the risk of the code it can change.

Sources