Kilo Code’s most revealing metric is not its 27,175 GitHub stars. It is the combination of 1,913 GitHub commits in 30 days, 8 release events in 30 days, and 8 active contributors. ToolVitals records a 99 shipping score and a 97 health score beside that concentrated activity. The evidence points to a team pushing an agent beyond code generation, toward a shared control surface for worktrees, terminals, pull request review, and multiple IDEs. The question for users is not whether Kilo is active. It is whether this pace is producing a coherent workflow that survives real repository work.

The product is a cross-surface engineering system

The official Kilo site positions Kilo as an AI coding agent for VS Code, JetBrains, the CLI, and cloud. It says the product can work with more than 500 models, supports local models, and lets developers move between the places where they write and operate code. The site’s strongest product claim is not a single editor feature. It is that one agent can be controlled across IDEs, CLI, and cloud.

That framing describes a specific problem. AI coding work is split between prompts, editor context, shell commands, code review, and long-running tasks. Kilo’s answer is to keep those tasks inside one set of agent sessions rather than treating each surface as an isolated assistant. This is an interpretation of the positioning, not a measured result, but the recent release notes give it support.

The GitHub repository describes Kilo as an open-source coding agent for VS Code, JetBrains, and the CLI. It lists Code, Plan, Ask, Debug, and Review modes. Code edits files from natural language. Plan works out architecture before code is written. Ask answers questions without touching files. Debug traces issues. Review checks changes for areas such as performance, security, style, and test coverage. The repository also says developers can create custom agents.

The rest of the repository feature list fills in the operating model: multi-file code generation, inline ghost-text completion, self-checking, terminal and browser control, an MCP marketplace, and model switching during a task. The official site adds the cloud surface and presents local models as an option for keeping code private. That last point is a product statement from Kilo, not an independent security audit.

The repository makes two details clear for technical evaluators. First, it exposes an autonomous path through kilo run --auto, but warns that the flag disables permission prompts and allows the agent to execute any action without confirmation. The project says to use it only in trusted environments. Second, Kilo CLI is described as a fork of OpenCode enhanced for the Kilo platform. The project is therefore shipping both Kilo-specific product work and changes that arrive through an upstream relationship. Release v7.4.22 makes that split visible by listing upstream OpenCode changes alongside Kilo changes.

ToolVitals classifies Kilo Code as OSI-approved OSS and records an MIT license label. The repository’s license text says users can use, modify, and distribute the code, including commercially, while retaining attribution and license notices. That is a materially different statement from fair-code, source-available, or open-core language. For this tool, OSI-approved open-source is the accurate description.

The unusual signal is concentration, not raw popularity

ToolVitals gives Kilo a hot score of 274.3, a health score of 97, a shipping score of 99, and an overall ToolVitals score of 98. The payload assigns data confidence of 90. Those values describe ToolVitals’ assessment of public project evidence. They do not turn into a benchmark for agent accuracy or developer productivity.

The repository has 27,175 GitHub stars. That is a substantial public footprint, but stars are an accumulated attention signal. They do not tell us how many people run Kilo every week, how many teams use it in production, or how often a generated patch is accepted without rework.

The activity numbers are sharper. ToolVitals reports 1,913 GitHub commits in the last 30 days, 30 GitHub releases in the last 90 days, 8 release events in the last 30 days, and 8 active contributors. The two release counters cover different windows and should not be merged into one number. The distinction matters because a project can publish many version artifacts while having fewer release events in a shorter period.

Taken together, the numbers show public engineering activity at a pace that is large relative to the active contributor count. That is the story. Kilo is not merely popular and not merely releasing. It is changing quickly while ToolVitals sees a relatively small active cohort behind the visible work.

Concentration has two readings. A focused group can keep product decisions aligned and move from bug report to release quickly. The same pattern can make review load, institutional knowledge, and ownership more fragile if the project grows faster than its contributor base. ToolVitals cannot identify the cause of the ratio or tell us whether inactive contributors are occasional reviewers, former maintainers, or people outside the measured window. The safe claim is narrower: current public activity is concentrated according to the metric.

The 99 shipping score supports the first half of that reading. The 97 health score suggests that ToolVitals also sees favorable maintenance signals. Neither score proves that every release is safe or that the project has low operational risk. The release notes are needed to understand what the activity is buying users.

Release notes show Agent Manager becoming the center of gravity

The v7.4.21 release on August 11 is a workflow release more than a model announcement. Its changes improve Agent Manager terminal focus and keyboard navigation, let users select a repository when creating or importing a worktree in multi-project mode, add review modes through slash commands, and expose model catalogs before a session starts. It also reduces background Git polling, defers file watching and indexing until they are needed, and speeds worktree session setup. Read together, these changes target the cost of coordinating many active sessions. The full details are in the v7.4.21 release notes.

The v7.4.22 release on August 13 moves deeper into the connection between agent output and repository state. File references become clickable only after Kilo validates them against the workspace, with fallback search and a warning for dead links. Agent Manager gains pull request comment actions. The release also exposes a model’s default reasoning variant, adds structured AWS and Google Cloud credential support for Bedrock and Vertex AI in VS Code, and fixes permission behavior for delegated subagents. The release includes a large set of upstream OpenCode updates, including MCP code mode work and provider handling changes.

The v7.4.23 release on August 20 makes the Agent Manager review surface more explicit. Users can set the default open or collapsed state for MCP and generic tool blocks. Pull request review threads are reorganized into a Resolved group, replies are shown within each thread, and actions such as sending comments to the agent, resolving a thread, copying, opening the file, or opening GitHub are made prominent. Unresolved comments can be sent to the agent as structured review comments rather than pasted text. Delegated subagent sessions can open in Agent Manager inspector tabs beside terminals.

The same release contains less visible but important state work. Projects load their worktrees and sessions instead of waiting on a single spinner. Agent Manager captures the focused terminal, keeps terminals and nested sessions alive across configuration reloads, restores incremental assistant streaming, and reduces large-session rendering overhead. These changes are not flashy. They are aimed at the failure modes that appear after an agent becomes a persistent workspace rather than a one-shot prompt.

This sequence gives the editorial thesis its strongest support. Kilo’s recent direction is about the machinery around agent work: choosing a repository, creating a worktree, selecting a model, invoking a subagent, reading tool output, sending review feedback back to the agent, and keeping state intact while the interface changes. Agent Manager looks less like a dashboard attached to a coding assistant and more like the coordination layer for an agentic engineering workflow. That sentence is an interpretation. The release contents are the evidence.

JetBrains work turns portability into an engineering problem

Kilo’s JetBrains releases show that the cross-surface claim requires more than publishing another plugin. The JetBrains 7.0.13 release adds a visible Kilo Core version and tells users whether the plugin is using a downloaded or bundled CLI build. It also addresses checksum API rate limits, dropped-file references, eager file watchers, session diff rendering, local recall search, invalid tool arguments, and SQLite lock errors. The release pins the JetBrains CLI to Kilo CLI v7.4.20.

The JetBrains 7.0.15 release adds editor context to prompts, including the active file, visible files, selected text, and shell context when available. It shows selected text and attached files as prompt attachments with links back to source locations, and adds a setting to enable or disable automatic editor context. Those are context-boundary controls. They matter because an agent’s answer depends on what the IDE sends, not only on the model it calls.

JetBrains 7.0.16 updates the plugin’s CLI pin to Kilo Core 7.4.22 and refreshes provider, model variant, and session runtime support. The 7.1.0-rc.2 release then adds an Agent Manager beta for creating, opening, organizing, renaming, and deleting worktree-based tasks and sessions from the IDE. It also shows worktree activity, ahead and behind status, changes, and pull request badges, with options to open worktrees in new windows or dedicated terminal tabs.

The release notes also mention migration recovery, preserved pending session states, read-only Ask and Plan modes, and prompt-size reduction through lazy skill loading. These are signs of a product trying to preserve behavior across a shared core and different front ends. They are not proof that VS Code, JetBrains, CLI, and cloud have feature parity. They do show that Kilo is spending engineering effort on the hard parts of parity: context capture, binary distribution, session recovery, Git state, and permission boundaries.

For a technical buyer, this is more relevant than a long feature list. Cross-surface tools often fail at the seams. A session may lose its context, a plugin may pin an incompatible core, a worktree may display stale Git state, or a tool may behave differently after reconnecting. Kilo’s recent notes repeatedly address those seams. The notes do not provide failure rates, so the correct conclusion is that these problems are on the project’s active engineering agenda, not that they are solved in every environment.

What ToolVitals can measure, and what it cannot

ToolVitals can measure public project signals in the payload: repository stars, commits, releases, release events, active contributors, health, shipping, hotness, a combined score, openness classification, and confidence in its collected evidence. The first-party excerpts add stated product scope, installation paths, agent modes, license language, and release contents.

That evidence cannot establish code quality. A 1,913-commit month may contain valuable features, routine updates, generated changes, or fixes that users never encounter. The payload does not provide test coverage, defect rates, security audit results, model evaluation scores, task completion rates, latency, or crash statistics.

It cannot establish user satisfaction or business traction. GitHub stars do not equal active users. Release frequency does not equal retention. The 98 ToolVitals score does not measure revenue, support quality, procurement readiness, or whether a team can operate the tool under its own compliance rules.

The official site says Kilo can keep code private with local models and lets developers inspect prompts, context windows, and decisions in MIT-licensed source. Those are useful design claims. The supplied evidence does not include a threat model, data-retention policy, independent audit, or a test of local-model behavior. An engineering lead should validate those items separately inside the intended deployment boundary.

The data also cannot tell us whether Kilo works well for a particular repository. Language mix, build system, monorepo size, Git topology, provider access, MCP servers, and internal policy can change the result. A high public score is a reason to run a serious evaluation. It is not a substitute for one.

The related_tools data puts Kilo near several active projects, but the comparison needs context. Unsloth is also categorized as a developer tool. It has a hot score of 268.4, 75,541 GitHub stars, a shipping score of 99, and 7 release events in 30 days. Kilo’s hot score is higher and its recent release-event count is one higher, while Unsloth has a much larger star count. Both projects have a 99 shipping score, yet their public footprints differ.

Orca provides a second contrast. ToolVitals lists 60,712 stars, a hot score of 256.3, a shipping score of 99, and 28 release events in 30 days. Orca has more stars and far more release events than Kilo in that window, but a lower hot score. The comparison does not establish that one tool is better. It shows that popularity, recent release activity, and the hot score capture different properties.

Hermes Agent, another related developer-tools entry, has 240,335 stars, a 100 shipping score, a hot score of 257.4, and 5 release events in 30 days. That is a larger repository audience with fewer recent release events in the payload. These reference points make Kilo’s profile clearer: its notable signal is not the largest star base or the highest shipping score. It is the combination of high hotness, near-top shipping and health scores, and concentrated recent activity.

What a skeptical buyer should test

A skeptical engineering lead should treat Kilo as a workflow system to test, not as a score to accept. Build a fixed evaluation set from the team’s own work. Include a multi-file feature, a bug trace, a test repair, a pull request review, a task that needs a worktree, and a session that must be resumed after an interruption. Run the same tasks through the surfaces the team would actually use, such as VS Code, JetBrains, and the CLI.

Record whether the agent understands the repository, produces changes that pass existing tests, preserves local conventions, and keeps review context attached to the right files. Test Agent Manager’s worktree state, terminal focus, session recovery, delegated subagent views, MCP output handling, and file references. Measure human correction time and the number of permission decisions. Those measurements belong to the buyer because the supplied ToolVitals data does not contain them.

Inspect the permission model before enabling automation. The repository’s --auto mode disables all permission prompts and permits any action without confirmation. Kilo explicitly limits that mode to trusted environments. A team should start with approvals enabled, isolate credentials, and decide which repositories and MCP servers can be exposed to an agent. The MIT license makes source inspection possible, but license access does not remove the need for operational controls.

The evaluation should end with a use-case decision. If the team needs a single coding agent across IDEs and CLI, model selection during work, worktree-based sessions, and pull request feedback that can return to the agent, Kilo has a concrete reason to be on the shortlist. If the team only wants a narrow autocomplete feature, the Agent Manager investment may not matter. Choose based on the workflow that must improve.

What maintainers should take from the data

For maintainers, the message is not to ship faster. The shipping score is already 99, and ToolVitals records 1,913 commits in 30 days plus 30 GitHub releases in 90 days. The more actionable signal is the 8 active contributors behind that pace. Kilo should make ownership and contribution paths easy to understand before the public surface grows further.

The release notes already provide useful detail. They name user-visible behavior, explain fixes around Git state and session lifecycle, and identify upstream OpenCode changes. Maintain that separation. A compatibility table for Kilo Core, VS Code, JetBrains, CLI, and upstream baselines would make the cross-surface contract easier to review. Release notes should keep calling out permission changes, data-context changes, and state-recovery changes because those affect trust more than visual polish.

The maintainers also have a chance to turn activity into stronger evidence. Public release volume shows motion, but it does not show stability. A small set of reproducible workflow tests covering worktrees, pull request review comments, MCP tools, provider switching, reconnects, and JetBrains context would let users judge progress against behavior rather than commit count. That would answer the questions ToolVitals cannot answer.

Recommendation

Evaluate Kilo Code if your team wants an MIT-licensed, OSI-approved open-source agent that spans VS Code, JetBrains, and the CLI, and if worktree coordination and pull request review are central to the way you ship. The recommendation rests on the product evidence and the release pattern, not on a claim that Kilo is already the best coding agent.

Start with a controlled pilot on representative repositories. Keep permission prompts active. Compare completed work, review quality, session recovery, and context accuracy against the tool your team uses now. Kilo’s 98 ToolVitals score and 99 shipping score justify that pilot. The 8 active contributors and the absence of product-quality benchmarks are reasons to verify the result yourself, not reasons to dismiss the project.

This is a project moving toward an agent manager, not just an agent. The pace is real. The concentration is real. The practical question is whether that direction matches your team’s repository workflow.

Sources