Kilo Code’s strongest signal is not its 26,790 GitHub stars. It is the coordination visible in its release stream. ToolVitals reports 16 release events in 30 days and 30 GitHub releases in 90 days, while the supplied first-party notes show Kilo Core, the JetBrains plugin, Agent Manager, and model plumbing moving together. That pattern points to a platform being assembled across several surfaces, not a static IDE extension with a command-line wrapper.

The distinction matters for engineering teams evaluating AI coding agents. Kilo is shipping changes at the boundaries where agent systems usually become difficult to operate: permissions, long-running sessions, diff review, local state, model routing, and compatibility between an editor integration and its CLI runtime. The data supports a case for active development and broad product ambition. It does not prove that generated code is correct or that the system will fit every team.

Kilo’s product thesis is one agent across several workspaces

The official Kilo site positions the product as an open-source AI coding agent for VS Code, JetBrains, the CLI, and Cloud. The GitHub repository uses broader language, calling Kilo an all-in-one agentic engineering platform, then describes the same coding agent across VS Code, JetBrains, and the CLI.

The repository makes that positioning concrete. It provides installation paths for the VS Code extension, JetBrains plugin, CLI, and downloadable binaries. It also points to cloud execution, automated pull request code reviews, and an always-on agent. Kilo is therefore not presenting the CLI as a separate utility. The repository treats it as a shared runtime that connects multiple ways of working.

The feature set follows the same direction. The repository lists Code, Plan, Ask, Debug, and Review agents, along with support for custom agents. It describes multi-file code generation, inline autocomplete, self-checking, terminal and browser control, an MCP marketplace, and access to more than 500 models with mid-task model switching.

That collection creates a demanding product surface. A coding agent that only edits files in one editor has a narrower set of state and permission problems. Kilo has to keep sessions, worktrees, prompts, attachments, model choices, diffs, and approval flows coherent across the editor, CLI, and cloud interfaces.

The repository also states that Kilo CLI is a fork of OpenCode enhanced for the Kilo agentic engineering platform. That gives the project an explicit upstream relationship. It also means release compatibility is part of the engineering story. Kilo is not only adding its own features. It is incorporating upstream changes while maintaining its own integrations.

ToolVitals classifies Kilo as OSI-approved OSS and lists the license as MIT. That is the correct basis for calling Kilo open source here. The homepage also frames the product around inspectable prompts, context windows, and decisions in MIT-licensed source. Those statements describe the project’s transparency position. They are not an independent audit of every execution path.

The metrics show activity, but the release count needs interpretation

ToolVitals gives Kilo a health score of 98, a shipping score of 98, and a ToolVitals score of 99. Its hot score is 231.0. The snapshot reports 26,790 GitHub stars, 30 GitHub releases in the last 90 days, and 16 release events in the last 30 days. ToolVitals assigns the record a data confidence of 100.

Those numbers support a narrow conclusion. Kilo is an active project with a substantial public audience and a high measured level of shipping and repository health. The 16 release events are especially notable because the recent first-party material is not a stream of cosmetic version bumps. It includes changes to runtime behavior, editor integration, security controls, and agent workflows.

The count still needs care. A release event is not the same thing as a major feature, a unique production version, or a successful user outcome. The supplied events include release candidates as well as stable releases, and the repository serves several packages. Sixteen events therefore indicate publishing activity across the project, not sixteen independently validated improvements.

The 30-release figure over 90 days tells a similar story at a longer interval. It suggests that the recent cadence is not an isolated week, but ToolVitals does not expose the full release taxonomy or the scoring formula in the payload. Readers should treat the count as a useful activity signal, not a quality rating.

GitHub stars provide another useful but limited signal. They show attention and accumulated interest, not active installations, successful deployments, or recurring use. The project’s 26,790 stars cannot establish how many teams use Kilo in production.

Two other fields are null: github_commits_30d and github_contributors_active. Null is not zero. ToolVitals cannot use this snapshot to state how many commits landed in the last 30 days or how many contributors were active during that period. That missing context makes the release data more important, but it also limits any claim about the size or distribution of the engineering effort behind it.

Recent releases point to integration work, not just feature accumulation

The most revealing evidence comes from the relationship between Kilo’s core releases and its JetBrains releases. The JetBrains 7.0.13 notes say that the plugin shows its pinned Kilo Core version and whether it is using a downloaded or bundled CLI build. The same release pins the JetBrains CLI to Kilo CLI v7.4.20 and includes upstream OpenCode updates through v1.17.13.

That is packaging detail with product consequences. Users need to know which runtime an editor plugin is actually using. Maintainers need a controlled way to update that runtime. The release notes also address checksum API rate limits, dropped-file references, file watchers, local recall searches, session diff rendering, invalid tool arguments, and SQLite lock errors. These are failures at the boundary between an agent and the environment around it.

The JetBrains 7.0.14 release follows with two focused fixes. It improves slash command matching and avoids startup crashes when the Kilo CLI database is temporarily locked by another process. The sequence suggests that Kilo is responding to operational friction in the integration, not only adding visible user features.

The core v7.4.19 release shifts attention toward Agent Behaviour and Agent Manager. It adds configuration for a model and reasoning variant for each workflow, keeps mode and model selection synchronized in the New Worktree dialog, restores Agent Manager sections for multi-project use, and supports moving sessions between worktree sections.

Those changes point toward a more structured approach to agent work. A worktree is not merely a directory where the agent writes files. In Kilo’s recent releases, it becomes part of the session model, with its own placement, terminal context, prompt focus, and review state.

The v7.4.20 release adds speech-to-text model discovery through the Kilo Gateway while retaining offline fallback and organization model restrictions. It also makes the first Agent Manager terminal prompt appear sooner by deferring optional enhancements and keeps the final file visible when expanding multi-file patch results.

The JetBrains 7.0.12 release shows the same priorities from another angle. It supports queued prompts while a session is running, gives users more explicit information in skill permission prompts, improves session changes and full-context diff review, and supports batch approval for commands from skill context. It also prevents agent loops from freezing when a provider stalls after response headers, enforces permissions for shell commands the parser cannot scan, keeps session reverts atomic, and defers CLI module loading and telemetry work to reduce startup time.

The release candidate JetBrains 7.0.13-rc.1 makes the integration direction even clearer. It adds tooling for pinning, unpinning, and updating the bundled Kilo Core CLI, supports resuming Claude and Codex sessions through the bundled runtime, and adds remote CLI file delivery for attachment flows.

Taken together, the releases describe a platform that is trying to make agent sessions portable and controllable. Agent Manager, worktrees, queued prompts, shared diffs, bundled runtimes, and model metadata are connected pieces. The evidence does not establish that the overall experience is mature, but it does show where the project is spending engineering effort.

What ToolVitals can and cannot tell you

ToolVitals can measure repository stars, release activity, health and shipping scores, and the resulting ToolVitals score. It can also preserve first-party release evidence. It cannot measure code quality, user satisfaction, revenue, support quality, task completion rates, or whether Kilo actually works well on a particular codebase.

The payload includes no SSL or uptime measurements. Their absence is not a pass or fail, and this post does not infer either. The official site’s claims about local models and code privacy are relevant to Kilo’s stated product direction, but the supplied excerpts do not provide an independent assessment of data handling across every IDE, CLI, and cloud mode.

The same caution applies to model breadth. The site and repository say Kilo supports more than 500 models and allows switching between them during a task. That establishes a product capability claim. It does not establish equal support quality, identical tool behavior, or consistent performance across those models.

A skeptical engineering lead should evaluate the workflows that the release notes identify as risky. Use a non-production repository and run the same tasks through VS Code, JetBrains, and the CLI. Test long sessions, queued prompts, large branch diffs, attachments, worktree changes, provider stalls, and recovery from local database locks.

Test permission behavior separately. The repository documents an --auto mode for fully autonomous runs and warns that it disables permission prompts, allowing the agent to execute actions without confirmation. Keep that mode restricted to trusted environments during evaluation, and verify that ordinary approval flows fail closed when commands cannot be parsed or when skill content is malformed.

The homepage points readers toward a data export guide, but the supplied excerpt includes only its title. Do not infer retention, deletion, or governance behavior from that title. Ask for the relevant documentation and test the controls that matter to your organization.

Relative position in the ToolVitals comparison set

The related_tools list is not a strict feature comparison. It includes frameworks and developer tools that do not solve the same problem as Kilo. The numbers still provide useful context for interpreting Kilo’s score.

LangChain has a hot score of 240.0, 143,809 GitHub stars, a shipping score of 100, and 12 release events in 30 days. Kilo’s hot score is 231.0, its star count is 26,790, its shipping score is 98, and its release event count is 16. LangChain’s much larger star base reflects a different type of project and should not be read as a direct adoption ranking against an IDE-centered coding agent.

Gemini CLI has 106,428 stars, a hot score of 224.2, a shipping score of 100, and 24 release events in 30 days. Kilo has fewer stars and fewer recent release events than Gemini CLI, but a higher hot score in this snapshot. ToolVitals does not expose enough of the formula to explain that difference, so the safe conclusion is only that Kilo’s current measured activity and attention are strong relative to these entries.

The comparison also reinforces the central point. Kilo does not lead every metric. Its shipping score is below the 100 recorded for LangChain and Gemini CLI. Its case rests on the combination of a 98 shipping score, a 98 health score, a 99 overall score, and release notes that connect several product surfaces.

What maintainers should take from the signal

For maintainers, the 16 release events are evidence of demand for coordination as much as evidence of velocity. The project is managing a core CLI, multiple editor integrations, Agent Manager workflows, model metadata, permissions, and upstream OpenCode changes. Each added surface increases the number of version and state combinations that users can encounter.

The recent notes identify a practical maintenance agenda. Keep runtime provenance visible in every integration. Publish a compatibility matrix for bundled and downloaded CLI builds. Treat database locks, provider stalls, parser failures, and large diff rendering as first-class test cases rather than edge reports.

The permission changes deserve equal attention. Showing verbatim skill commands, failing closed for unscannable shell commands, and making queued approval states deterministic all improve the auditability of agent actions. Those controls should remain consistent across VS Code, JetBrains, the CLI, and any cloud execution path.

Maintainers should also separate stable release communication from release-candidate experimentation. The recent sequence contains both, and readers need to know which behavior is ready for general use. ToolVitals can count the events, but clear compatibility and stability signals have to come from the project itself.

Recommendation

If your team wants one open-source coding agent that spans VS Code, JetBrains, the CLI, and cloud workflows, evaluate Kilo Code in a controlled pilot. The evidence supports choosing it for broad surface coverage, active release coordination, model flexibility, and serious work on permissions, sessions, diffs, and worktrees.

Do not choose it solely because ToolVitals reports a 99 score or because the repository has 26,790 stars. Pin the versions you test, define rollback steps, verify permission behavior, and measure task success on your own repositories. Kilo’s current signal is strong activity around a multi-surface platform. Your evaluation must determine whether that platform is reliable enough for your engineering process.

Sources