Kilo Code: an open source coding agent for VS Code, JetBrains and the CLI

What Kilo Code is, and the problem it targets

Most coding agents force a choice early: a chat window in one editor, or a terminal tool that knows nothing about your editor session. Kilo Code's answer is to ship the same agent in three places. The README describes it as "the open source coding agent for building with AI in VS Code, JetBrains, or the CLI", and the repository layout backs that up with separate packages for the VS Code extension, the JetBrains plugin and the CLI.

The intended user is a working engineer who wants an agent inside the editor they already use, with the option to drop to a terminal when a task is better scripted. The project also targets teams that want automated review on pull requests and a cloud-hosted agent, both of which the README links to as hosted products rather than local installs.

One detail worth flagging because it shapes everything else: the README states plainly that the CLI is a fork of OpenCode, "enhanced to work within the Kilo agentic engineering platform". That is an honest disclosure, and it means anyone with prior OpenCode experience will recognise the shape of the tool.

Agents, model switching and the permission model

Kilo Code is organised around named agents rather than a single chat mode. The README lists five: Code for implementing and editing, Plan for architecture and implementation plans written before any code, Ask for questions about the codebase with no file writes, Debug for tracing issues, and Review for reading your changes across performance, security, style and test coverage. The separation matters more than it first appears. Ask and Plan are read-only in intent, so you can point them at a repository without expecting a diff.

On top of that sit the capabilities: multi-file code generation, inline autocomplete with ghost-text suggestions, a self-checking loop where the agent reviews and corrects its own work, terminal and browser control, and an MCP marketplace for wiring up external servers. Model selection is the other axis. The README claims 500+ models with switching mid-task, priced at the provider's rate with no markup, and says no API keys are required to start. That last phrase is the one to read carefully: no keys are required to start, which implies a hosted account path, while the model list itself is a bring-your-own-provider arrangement.

The permission model is where the design shows a deliberate trade-off. In normal interactive use the agent asks before acting. The autonomous mode described below removes that entirely.

Installing the Kilo Code CLI and running a first task

The CLI is published to npm as @kilocode/cli. The README gives several package managers; pick one. The npm route is the most portable:

npm install -g @kilocode/cli

Homebrew users on macOS or Linux can instead tap the project's own formula, and Arch users have an AUR package:

brew install Kilo-Org/tap/kilo

There is also a curl installer, `curl -fsSL https://kilo.ai/cli/install | bash`, plus pnpm and bun equivalents. If you would rather not use a package manager at all, the README points to the Releases page with per-platform binaries: `kilo-windows-x64.zip`, `kilo-darwin-arm64.zip`, `kilo-darwin-x64.zip`, `kilo-linux-x64.tar.gz` and `kilo-linux-arm64.tar.gz`. Two variants are called out in the README notes: an `x64-baseline` build for older CPUs without AVX, and a `musl` build for Alpine or minimal Docker images without glibc. The notes also warn that `kilo-vscode-*.vsix` is the extension package, not the CLI, which is an easy mistake to make when scanning a release page.

With the binary on your PATH, the README says to run `kilo` in any project directory to start. That opens the interactive agent. For a scripted, non-interactive run, the README documents `kilo run` with the `--auto` flag:

kilo run --auto "run tests and fix any failures"

According to the README, `--auto` disables all permission prompts and lets the agent execute any action without confirmation, and it should only be used in trusted environments. That is the whole tutorial: install, run `kilo` interactively, and reach for `kilo run --auto` only when you have decided the environment can absorb an unreviewed command.

VS Code users have a shorter path. The README says to install the Kilo Code extension directly from the VS Code Marketplace under the identifier kilocode.Kilo-Code, then create an account. JetBrains users install the Kilo Code plugin from the JetBrains Marketplace or search "Kilo Code" under Settings, then Plugins inside the IDE.

Where Kilo Code is the wrong tool

The autonomous mode is the clearest boundary. The README's own warning is that `--auto` disables all permission prompts and lets the agent execute any action without confirmation, and that it should only be used in trusted environments. If your CI runner holds deployment credentials, a package registry token or cloud keys, that sentence should stop you. The agent is documented as having terminal and browser control, so an unreviewed action is not limited to editing files.

There is a second, quieter limitation. The README lists terminal and browser control, a self-checking loop and MCP servers as features, but it does not document a rollback mechanism, a sandbox, or a per-command allowlist. The README does not document rollback. Anyone expecting the agent to be constrained by a policy file will not find that described on the front page; the README defers configuration to the docs site at kilo.ai/docs, which is outside what the repository front page states.

A third case: if you want a single agent bound tightly to one editor's own extension API, a cross-surface tool is more surface area than you need. Three install paths, three release streams and a hosted cloud product is more to track than a single-editor plugin.

Kilo Code compared with OpenCode and Cline

The most direct comparison is OpenCode, because the README says the Kilo CLI is a fork of it. The difference is packaging and platform, not the underlying interaction model. OpenCode is a terminal-first agent; Kilo Code takes that base and adds a VS Code extension, a JetBrains plugin, hosted code reviews and a cloud agent, all under one account. If you only ever work in a terminal, the fork's additions are mostly irrelevant to you, and you are carrying a larger project for no benefit.

Against Cline, the distinction is breadth of surface rather than model access. Cline is a VS Code extension, so its reach is one editor. Kilo Code's claim is the same agent in VS Code, JetBrains and the CLI, with agents you switch between by task type. If your team is split between IntelliJ and VS Code, that shared surface is the actual argument for Kilo Code. If everyone is already in VS Code, the argument weakens considerably and the choice comes down to which agent's behaviour you prefer in practice.

Neither comparison is settled by the README, which does not benchmark against either tool. Treat the fork disclosure as the reliable fact and the rest as positioning.

Licence, maintenance and upgrade cost

The repository is MIT licensed. The README states you are free to use, modify and distribute the code, including commercially, as long as you keep the attribution and license notices. For most teams that is the least restrictive outcome available, and it means forking is a real option if the project's direction stops suiting you. It also means the hosted products (cloud agent, code reviews, KiloClaw) are separate commercial services; the MIT grant covers the code in the repository, not those services. This is a description of the licence text, not legal advice.

On maintenance: the repository is not archived, and the last push was on 2026-08-28, with v7.5.6 released the same day and JetBrains 7.1.1 also dated 2026-08-28. Separate release streams for the main package and the JetBrains plugin mean two upgrade cadences to watch, and the presence of a release candidate (jetbrains/v7.1.1-rc.1) alongside the stable tag suggests the plugin ships on its own schedule.

Upgrade cost is dominated by the model list, not the code. Because the tool brokers access to many providers, a provider deprecating a model or changing its API affects your workflow even when Kilo Code itself has not changed. The repository uses bun as its package manager and turbo across a workspace of packages, so anyone building from source should expect a monorepo build rather than a single compile step. The root package.json even sets the test script to fail deliberately with the message "do not run tests from root", which tells you tests are meant to run per package.

Editorial conclusion

Adopt Kilo Code if you already work inside VS Code or a JetBrains IDE and want an agent that can also run headless in CI through kilo run --auto. Do not adopt it for unattended pipelines on machines that hold credentials you would not hand to a shell, because the README states that --auto disables all permission prompts. Before committing, verify three things: that your JetBrains IDE version is covered by the plugin listing, that the model you intend to use is reachable with your own provider account, and that your organisation accepts an agent holding terminal and browser control.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes