Kilo Code’s most interesting signal is a mismatch. ToolVitals records 1,858 GitHub commits in the last 30 days and a 99 shipping score, but it also records zero release events in the same period. The supplied first-party release pages show work on Agent Manager, worktrees, pull-request review, model controls, and JetBrains support. The strongest reading is not that Kilo stopped moving. It is that the project is doing substantial engineering beneath a quiet public release channel in this snapshot, while turning an AI coding agent into a cross-editor system for managing agent work.

That distinction matters because release frequency is only one view of a software project. Kilo’s repository activity suggests a team working on product breadth and internal coordination, while the public release signal is currently less clear. The result is a tool that deserves a technical evaluation, but not a conclusion based on shipping scores alone.

Kilo is defining a workflow, not just a chat panel

The official Kilo site describes the product as an AI coding agent for VS Code, JetBrains, the CLI, and Cloud. Its central promise is one agent that follows developers across those environments. The GitHub repository presents the same product as an open source coding agent for VS Code, JetBrains, and the CLI, with a web entry point and automated pull-request code reviews also documented in the setup material.

That surface coverage gives Kilo a more ambitious job than generating code inside one editor. The repository lists specialized modes for Code, Plan, Ask, and Debug, along with support for custom agents. Code edits files, Plan produces an implementation plan before changes are made, Ask answers questions without touching files, and Debug focuses on tracing problems. The distinction is practical. It gives a team a way to separate exploration, design, implementation, and diagnosis instead of sending every request through the same mode.

The repository also lists multi-file code generation, inline autocomplete, self-checking, terminal and browser control, and a marketplace for agents, skills, MCP servers, and plugins. It documents support for more than 500 models with switching during a task. The CLI can run an autonomous command through kilo run --auto, which is aimed at CI/CD use but automatically approves permission prompts unless a rule explicitly denies the action. The repository tells users to use that mode only in trusted environments.

ToolVitals marks Kilo as OSI-approved OSS and gives it an MIT license label. The repository identifies the code as MIT licensed and invites contributions. The correct description is therefore OSI-approved open-source software, not fair-code, source-available, or open-core software. That distinction matters to teams that need to inspect, modify, and operate the agent without treating its source classification as a marketing shorthand.

The product thesis is clear from these first-party descriptions. Kilo wants to keep the agent, the session, the model selection, the tools, and the work context connected as a developer moves between surfaces. The release record shows that the hard part of that thesis is not only code generation. It is session management, repository state, permissions, review context, and recovery.

Recent releases point to an agent control plane

The v7.4.23 release, dated August 20 in the supplied context, is a useful snapshot of that direction. It reworked pull-request review comments in the Agent Manager panel. Resolved threads now collapse into a dedicated group, replies are visible, and review cards expose actions for sending feedback to the agent, resolving threads, copying content, opening a file, and opening the discussion on GitHub. A control can send all unresolved comments to the agent as structured review comments instead of pasted text.

That change shifts the agent from a private coding conversation toward a participant in a review loop. The difference is important. A chat panel can suggest a patch. A review workflow has to preserve thread state, distinguish resolved from unresolved feedback, connect comments to files, and give the developer a clear way to hand selected context back to the agent.

The same release added delegated subagent sessions to Agent Manager inspector tabs and included a long list of fixes for project loading, terminal context, session persistence, streaming, and large-session performance. Those items are less visible than a new model integration, but they address the friction that appears when several agents, worktrees, and terminals are active at once.

The v7.4.22 release, dated August 13, adds another layer. File references in agent responses can become clickable when they match real files in the workspace, and dead paths remain plain code with a file-not-found warning. The release also adds more pull-request comment actions, exposes the model’s default reasoning variant, improves cloud-provider credential handling, and fixes permission behavior for delegated subagents.

The v7.4.21 release, dated August 11, focuses heavily on Agent Manager interaction. It improves terminal focus and keyboard navigation, supports repository selection in multi-project worktree flows, reduces background Git polling across large worktree sets, and defers file indexing until search is used. It also adds model catalog browsing before a session starts and keeps model, agent, variant, and sandbox choices available in worktree prompts.

The JetBrains channel reinforces the same pattern. 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 inside the IDE. It displays worktree activity, change counts, ahead and behind status, and pull-request badges. It also supports opening worktrees in new windows and dedicated terminal tabs.

Earlier JetBrains releases show the supporting work required to make that experience usable. JetBrains 7.0.15 added active-file, visible-file, selected-text, and shell context to prompts, plus attachments that link back to source files and selections. JetBrains 7.0.13 improved session diffs, file drops, file watchers, local recall searches, invalid tool-argument messages, and SQLite lock handling.

Taken together, these releases describe a product moving toward coordinated agent work. The center of gravity is not one clever completion feature. It is the set of interfaces around an agent that has to operate on real repositories, preserve context, work in isolated trees, receive review feedback, and recover from interrupted sessions.

The metrics show intensity, not proof of product quality

ToolVitals reports the following measurements for Kilo Code:

  • Hot score: 226.5
  • Health score: 98
  • Shipping score: 99
  • ToolVitals score: 99
  • GitHub stars: 27,499
  • GitHub commits in 30 days: 1,858
  • GitHub releases in 90 days: 30
  • Active contributors: 26
  • Release events in 30 days: 0
  • Data confidence: 90

The strongest activity signal is the combination of 1,858 commits, 26 active contributors, and a 99 shipping score. That is a large amount of visible repository movement in the measured period. It supports the claim that Kilo is being actively developed. It does not prove that the changes are reliable, well tested, or useful to every team.

The 27,499 GitHub stars show substantial public interest in the repository. Stars are not active-user counts, retention figures, or evidence that the agent performs well on production code. They are a public repository signal, and they should be read alongside the contributor and release data rather than substituted for it.

The release numbers need more care. ToolVitals reports 30 GitHub releases in 90 days, while the current 30-day release-event count is zero. The supplied first-party release pages are dated between August 6 and August 20, while the local fact-check context was generated on October 7. The payload does not establish whether the gap reflects a release pause, a different channel, or a measurement boundary. It does establish that the current snapshot contains heavy commit activity without a corresponding release event in the latest 30-day window.

The separate Core and JetBrains release pages also make a single release number harder to interpret. A high count can represent work across several artifacts and channels. A quiet top-level release window can coexist with active development in branches, extensions, or candidate releases. The safe conclusion is that Kilo’s engineering activity is clear, while its current public release cadence is less legible.

ToolVitals assigns a data confidence score of 90. That supports confidence in the supplied measurement set, but it does not turn repository metrics into a product audit. The health, shipping, and ToolVitals scores remain ToolVitals signals. They should not be presented as measured code correctness or user satisfaction.

What a skeptical buyer still needs to test

An engineering lead should treat Kilo’s metrics as a reason to run a controlled evaluation, not as a substitute for one. The first test should cover the workflow Kilo is actually building: create a worktree-based task, move between planning and implementation, send review feedback back to the agent, inspect the resulting diff, and recover from an interrupted session.

Test the same repository through VS Code and JetBrains if both editors matter to the team. The supplied releases show that Kilo is working to provide comparable context, session handling, worktree visibility, and terminal behavior across those surfaces. That does not prove the experiences are equivalent in practice.

Test permissions and failure handling before allowing autonomous runs. The repository’s warning about --auto is direct. The mode can auto-approve permission prompts unless a rule denies an action, so it belongs in a trusted and isolated environment until the team’s policy model has been validated. The evaluation should include terminal commands, MCP tools, browser control, file edits, and a deliberate denied action.

Test the model and provider boundary as well. Kilo’s repository describes a large model catalog and mid-task switching, while the release notes mention reasoning variants, provider credentials, model discovery, and upstream runtime changes. A serious pilot should measure whether sessions preserve context when models change, whether failures explain themselves, and whether a developer can recover without losing the task state.

The buyer question is not whether Kilo has activity. It clearly does. The question is whether Agent Manager, worktrees, review comments, and cross-editor context reduce coordination cost for the team’s real repositories without creating new permission, state, or maintenance problems.

What ToolVitals cannot tell you

ToolVitals sees repository activity, contributors, releases, licenses, and public project evidence. It does not see code quality, user satisfaction, revenue, or whether the product actually works well in a team’s environment.

Commits can include refactoring, generated changes, dependency updates, fixes, or work that is not yet released. Stars can accumulate without continued use. Release events can reflect channel structure rather than a complete view of product progress. Contributors are not a direct measure of support quality or decision-making speed.

The local first-party excerpts show product positioning and release notes. They do not provide an independent security audit, a benchmark of generated patches, a measure of model latency, or evidence that every supported editor behaves consistently. They also do not establish how often an agent completes tasks without intervention.

That limitation changes the interpretation of the 99 scores. A high shipping score tells a team that Kilo is producing visible repository activity. It does not answer whether the agent writes safe migrations, preserves a codebase’s conventions, handles secrets correctly, or gives maintainers enough control over autonomous actions. Those questions require a real repository, a defined test set, and human review.

The comparison is about scale, not parity

The related_tools data places Kilo near several other active developer tools, but it does not establish direct feature parity. Kilo’s hot score is 226.5, compared with 231.8 for Hermes Agent and 224.3 for OpenClaw. All three have a ToolVitals shipping score of 99 in the supplied data.

The star counts show a different picture. Kilo has 27,499 GitHub stars, compared with 251,335 for Hermes Agent and 391,422 for OpenClaw. Those gaps should not be read as a ranking of coding-agent quality. The related list spans projects with different audiences, histories, and product scopes. The useful comparison is narrower: Kilo’s current hot score is competitive with these adjacent tools, but its public repository audience is much smaller by the supplied star measure.

That separation between activity score and repository scale is another reason to avoid a simple leaderboard reading. Kilo can be moving quickly without matching the installed base or recognition of a much larger project. The metrics support that specific claim and no more.

Recommendation for teams and maintainers

Teams should evaluate Kilo Code now if they work across VS Code or JetBrains and need agent sessions connected to worktrees, terminals, pull-request review, and multiple agent modes. Start with a bounded repository and a repeatable task set. Measure patch correctness, review turnaround, session recovery, permission behavior, and the amount of manual cleanup required. The evidence supports evaluating Kilo’s workflow coverage and engineering momentum. It does not justify assuming that the agent will produce correct changes without review.

Keep autonomous --auto runs isolated until the permission model has been tested. That recommendation comes directly from the repository’s own warning, not from the ToolVitals scores. Teams should also decide whether the CLI, IDE plugins, cloud surface, and review workflow are parts of one operating model for them or separate tools that need separate controls.

Maintainers have a different problem. The project is visibly active, but the current data leaves readers to reconcile 1,858 commits, 30 releases in 90 days, and zero release events in 30 days. Kilo would make its momentum easier to understand by publishing clear release accounting across Core, VS Code, CLI, JetBrains, and candidate channels. Each release should make it obvious which artifact changed, which work is available now, and which work remains experimental.

The maintainers should also connect activity to user-facing evidence. Release notes already show detailed fixes for worktree state, review comments, terminal focus, context capture, and session recovery. Adding reproducible examples, regression coverage, or task-level results would help readers judge whether that work improves the agent in practice. That would turn a strong activity signal into stronger evidence about product quality.

Kilo Code is a credible candidate for a controlled technical evaluation because its first-party material and ToolVitals measurements point in the same broad direction: active development around a multi-surface agent workflow. The caveat is equally clear. The project is easier to measure for engineering intensity than for real-world effectiveness, and the quiet 30-day release window means teams should verify the current artifact and workflow behavior before making a broader adoption decision.

Sources