Daniel Kim

Posted on Aug 15

Kilo Code's Reviewer Decides Between 0, 1, or 6 AI Agents Before It Reads Your Diff

#opensource #ai #codereview #vscode

Most "AI coding agent" posts on Product Hunt this year are the same pitch wearing a different logo: an editor sidebar, a system prompt, a monthly subscription with a usage cap you'll hit around the third week. Kilo Code has been posting #1 Product of the Day and #1 Product of the Week results with a pitch that sounds identical on the surface — open source coding agent, VS Code and JetBrains, now with an AI code reviewer. What the launch copy doesn't say is more interesting than what it does: Kilo isn't one codebase. It's two separate open-source coding agents, stitched together by a shared billing layer and, more recently, a review pipeline that decides its own headcount before it reads your diff.

I spent a few hours in the actual Kilo-Org/kilocode monorepo — not the marketing site, which is blocked from automated fetches, but the code, the changelog, and the docs source — to figure out what's real. Here's what I found.

What Kilo Code actually is

Kilo Code is an open-source AI coding agent that ships as a VS Code extension, a JetBrains plugin, a CLI/TUI, a cloud "Agent Manager" web surface, and (via a sub-product called KiloClaw) a chat-triggered agent you can reach from Telegram, Discord, or Slack. The repository currently sits at roughly 27,000 GitHub stars and 3,100 forks, and its own README calls it "the most popular open source coding agent" — a claim that's at least directionally supported by the star count relative to comparable open-source agents.

Inside the product there isn't one monolithic "AI assistant" persona. Kilo ships five named agents, each scoped to a task:

Code — the default implementation agent: writes, edits, and refactors across files
Plan — architecture and design before implementation starts
Ask — read-only codebase Q&A
Debug — diagnoses and fixes issues
Review — reads a diff and reports on it without touching code

You can also define custom modes (the screenshot above shows a "UX Designer" mode alongside the built-ins), and switch between more than 500 models mid-task — the docs list current options including GPT-5.5, Claude Opus 4.7, Claude Sonnet 4.6, and Gemini 3.1 Pro Preview, plus lower-cost and free options like MiniMax M2.1, which shows up as the active model in Kilo's own documentation screenshot of the Review mode.

Two smaller pieces round out the surface area. There's an MCP marketplace built into the extension for discovering and wiring up Model Context Protocol servers, so extending what the agent can reach (databases, ticket trackers, internal APIs) doesn't require hand-writing a config file from scratch. And inline autocomplete runs on a dedicated model — Mistral's Codestral 2508 — rather than routing ghost-text suggestions through whatever large model you've picked for chat, which keeps latency down and, notably, is free if you bring your own Codestral key, since Mistral offers a no-cost tier for it. The docs are unusually candid about this being a background process: Codestral requests fire whenever autocomplete is enabled, even if you haven't opened the chat panel, and there's an explicit settings toggle to kill it if you don't want the always-on behavior.

None of that is unusual for 2026. Model-agnostic, multi-mode coding agents are the default shape of this category now. What's underneath is where it stops being generic.

The part the launch page skips: this is two forks, not one product

Kilo Code's VS Code and JetBrains extensions are a fork of Roo Code, which is itself a fork of Cline. The repo's own README still greets Roo Code users directly — "Coming from Roo Code? Switch to Kilo and check out our migration guide" — and the changelog regularly logs entries like "Cherry-picked from upstream Roo-Code," pulling in specific pull requests from RooCodeInc/Roo-Code by number and author. Kilo isn't quietly derived from Roo Code; it's actively tracking it, pulling fixes across on an ongoing basis.

The CLI and TUI are a completely different lineage. Per the README, "Kilo CLI is a fork of OpenCode, enhanced to work within the Kilo agentic engineering platform." The changelog confirms this isn't a one-time fork either — entries like "Changes from opencode v1.17.13 to v1.18.0 upstream" appear repeatedly (I counted references to at least half a dozen separate upstream OpenCode version bumps in the visible changelog history), each one pulling in the corresponding upstream bugfixes and features from the @opencode-ai package family.

So the practical picture is: Kilo Code's editor extensions are Cline-via-Roo-Code with continuous upstream cherry-picks, and Kilo Code's CLI is OpenCode with continuous upstream merges. Two different codebases, two different upstream communities, two different release cadences that the Kilo team is manually reconciling — unified only by a shared account system, shared model billing, and a shared set of five agent definitions layered on top.

You can see the seam in the numbers: the VS Code extension's changelog alone has logged 397 distinct version entries by the time of writing, most of them shipping within a day or two of each other. That's the pace of a team maintaining a fork under continuous upstream pressure from two directions at once, not a team writing a coding agent from scratch. It's also, to be fair, a legitimate strategy — you inherit Cline/Roo Code's IDE integration maturity and OpenCode's terminal-native architecture instead of rebuilding either, and you can point to specific upstream commits to prove you're not silently drifting.

The tradeoff is real, though: a two-lineage fork means feature parity between the VS Code sidebar and the CLI isn't guaranteed by architecture, only by continued maintainer effort. The Agent Manager — Kilo's worktree-based multi-session orchestrator — is currently VS Code-only, built into the extension's embedded runtime specifically so it doesn't need a separate CLI install or CLI auth. If you live in the terminal, you don't get it yet.

The actual news: an AI reviewer that sizes its own team

The feature driving Kilo's most recent Product Hunt runs is Code Reviews — an AI agent that reviews pull and merge requests on GitHub or GitLab automatically, plus a /review slash command for reviewing changes locally before you ever open a PR.

The generic version of this pitch ("an AI reviews your PR") is not interesting; CodeRabbit and Greptile have been doing it as standalone products for a while, and every general-purpose coding agent can be prompted to review a diff. What's specific to Kilo's implementation is how it scales itself.

According to Kilo's own documentation, the Review agent estimates the size of a diff — changed file count and changed line count — and then picks a review strategy from three tiers:

Diff size	Behavior
Tiny (≤2 files, <100 changed lines)	0 sub-agents; the primary reviewer reads it directly
Small (3–5 files or 100–300 changed lines)	1 sub-agent, assigned to the single riskiest area
Medium and larger (6+ files or >300 changed lines)	Up to 6 sub-agents, sharded across independent areas

The sub-agents are read-only and can't post comments themselves — they return findings (path, line, severity, rationale) to a primary reviewer, which is responsible for deduplicating, verifying each finding actually lands on a valid diff line, and writing the final review. This matters more than it sounds: naive multi-agent review setups tend to produce redundant or contradictory comments when several agents look at overlapping code, and Kilo's docs are explicit that the primary reviewer owns final output for exactly that reason.

The genuinely uncommon part is that this policy is overridable per repository via a REVIEW.md file committed to the repo root — not a dashboard setting, a file that lives in version control next to the code it governs. Kilo reads REVIEW.md from the pull request's base branch, not the feature branch, specifically so a PR can't rewrite the rules used to judge itself. If the file is missing, disabled, unreadable, or over 10,000 characters (truncated, with a note in the review summary), Kilo falls back to its built-in tiering. Teams can use it to declare things like "0 sub-agents for docs-only or lockfile-only changes" or "3 sub-agents split across API, UI, and test coverage for changes that touch all three" — essentially writing a review runbook as code, checked into the same repo, reviewable in its own PRs.

Review behavior is also configurable along two other axes: style (Strict / Balanced / Lenient) and focus areas (security, performance, bug detection, style, test coverage, documentation), with a configurable time cap between 5 and 30 minutes per review. Reviews land as native GitHub/GitLab comments, "as if coming from a team reviewer," and bot-authored PRs — Dependabot, Renovate — are excluded by default so review credits and notification noise aren't spent on dependency bumps.

Agent Manager: the other half of the "how it works" story

The Review agent is the feature carrying the current Product Hunt momentum, but it isn't the only structurally interesting piece. Agent Manager — Kilo's answer to "what happens when you want more than one agent session running at once" — is a full-panel editor tab built directly into the VS Code extension's embedded runtime, which the docs specifically call out as needing no separate CLI install or CLI authentication.

Each session in Agent Manager runs in its own git worktree, checked out under .kilo/worktrees/ in your project, on its own branch, with a dedicated integrated terminal and a diff/review panel comparing against the parent branch. That worktree isolation is the actual mechanism that lets you run several agents on the same repository without them fighting over the same working directory — something that's a real, recurring problem for anyone who's tried to run two agent sessions against one checkout and watched them stomp each other's uncommitted edits. Sessions can also be imported from existing branches, external worktrees, or directly from a GitHub PR URL, and a sidebar session can be promoted into the Agent Manager mid-task via "Continue in Worktree" once it turns out to need more room.

There's a genuinely well-thought-out detail in how it surfaces PR status: each worktree gets a color-coded badge showing its associated PR number, and Kilo tries three separate strategies in order to find that PR via the gh CLI — first the branch's tracking ref (which works even for fork PRs checked out with gh pr checkout), then a same-repo branch-name match, then, as a last resort, a search by HEAD commit SHA. That's the kind of fallback chain you write after discovering the naive approach breaks on real-world branch-naming conventions, not something you'd design speculatively on day one.

What changed versus what came before

Set next to the review-bot category (CodeRabbit, Greptile, and similar standalone tools), Kilo's move is architectural: instead of a separate subscription living outside your coding agent, the reviewer is the same product, the same account, the same credit pool, and — per the sub-agent tiering — the same underlying agent runtime doing the reviewing that does the coding. You don't buy a second tool to close the loop on the first one.

Set next to closed-source IDE agents like Cursor, Windsurf, and GitHub Copilot, the difference is licensing and pricing structure rather than raw capability. Kilo ships under the MIT license (with a note in LICENSE crediting OpenCode's 2025 copyright, consistent with the fork lineage above), and its documentation states the billing model plainly: "Our pricing matches the model provider's API rates exactly. We don't take any commission or markup. $1 you give us becomes $1 of Kilo credits." That's a genuinely different economic model from a flat monthly subscription — you're charged what Anthropic, OpenAI, or Google actually bill for the tokens, not a bundled rate that has to average out across light and heavy users. Kilo also sells a prepaid "Kilo Pass" as a discounted way to load credits, and supports bringing your own provider API key (BYOK) to skip Kilo credits entirely for models it doesn't mark up anyway.

Set next to its own ancestors, Roo Code and Cline, the honest framing is that Kilo isn't a reimagining so much as a commercial layer and a second, independently-maintained surface (the OpenCode-derived CLI) added on top, plus the Review agent and Agent Manager as genuinely new functionality that doesn't exist upstream.

Why this should matter to you specifically

Cost exposure is direct, not abstracted. With per-provider pass-through pricing, a price change from Anthropic or OpenAI shows up in your Kilo bill exactly as it would if you called the API yourself — no markup buffer, but also no markup buffer to protect you from a provider price increase mid-month. If you're used to a flat-rate IDE subscription, this is a mental model shift: you're now managing token spend the way you would with a raw API key, just inside an IDE.

Lock-in risk is lower than usual, in a specific, checkable way. MIT license plus an active upstream relationship with two other open-source projects means that if Kilo the company disappeared tomorrow, the VS Code extension's lineage (Roo Code, Cline) and the CLI's lineage (OpenCode) both continue to exist and ship independently. That's a stronger guarantee than "it's open source" usually implies, because you can point to the specific upstream repos that would keep moving.

Review policy as code is a real security/maintainability win, not just a nice-to-have. Storing review strictness, focus areas, and sub-agent delegation rules in a REVIEW.md that's read from the base branch — and can't be altered by the PR it's reviewing — is the kind of detail that suggests the team building this has actually thought about the adversarial case (a contributor trying to weaken review scrutiny in the same PR that needs weaker scrutiny). It's a small design choice, but it's the one that separates "review bot as toy" from "review bot you'd trust to gate a merge."

The multi-surface story has a real gap. Agent Manager's worktree orchestration — parallel isolated sessions, each on its own branch, with PR status badges pulled via the gh CLI — is VS Code-only today. If your team standardizes on the CLI or JetBrains, you don't get it, and there's no committed timeline in the docs for closing that gap given the two-codebase structure described above.

The independent read

Two things nag at me after going through the actual code and docs instead of the pitch.

First: "zero markup" pricing is a real and verifiable claim, but it's not the same thing as "cheap." Pass-through pricing means Kilo has no incentive structure to push you toward a more efficient model or a smaller diff — the meter runs exactly as fast as the frontier model you chose runs, and a team that lets Review agents fire on every push with Strict style and a 30-minute cap on a busy monorepo can rack up real spend with nobody deliberately overspending on any single decision. The "no markup" framing is honest, but it shifts the entire burden of cost discipline onto the user, the same way a raw cloud API bill does. That's a fair trade for a lot of teams, but it's not the free lunch a Product Hunt tagline implies.

Second: the two-lineage fork structure is simultaneously Kilo's best argument and its biggest open question. Inheriting Roo Code/Cline's IDE maturity and OpenCode's terminal architecture instead of building either from zero is a legitimately smart way to reach "works well in VS Code and works well in the terminal" faster than almost anyone building from scratch could. But it also means Kilo's roadmap is partly hostage to two upstream projects it doesn't control, and the fact that Agent Manager — arguably the most differentiated recent feature — is VS Code-only isn't really a product decision, it's a consequence of that split: the VS Code extension has its own embedded runtime to build against, and the CLI would need its own separate implementation of the same worktree-orchestration logic. Nothing in the public docs commits to closing that gap on any timeline. If you're evaluating this for a CLI-first or JetBrains-first team, that's the detail to press on before adopting, not the credit-pricing pitch.

Practical use cases

Gating PRs without hiring a second reviewer. The Balanced style plus a 15–20 minute cap is a reasonable default for teams that want a consistent first pass on every PR before a human looks at it, especially for teams too small to have a dedicated reviewer on every change.
Pre-push local review. /review uncommitted or /review branch catches issues before a PR exists at all, which matters for teams that want review feedback to shape the diff, not just gate it after the fact.
Running several agent sessions in parallel on unrelated tasks. Agent Manager's worktree isolation (stored under .kilo/worktrees/) lets you have Kilo working on three different tickets simultaneously in the same repo without one session's uncommitted changes colliding with another's — genuinely useful for anyone who has ever lost work to two agents editing the same file at once.
CI-gated autonomous runs. kilo run --auto disables interactive prompts entirely, explicitly built for CI/CD pipelines — useful for scripted maintenance tasks (dependency bumps, codemods) that shouldn't need a human approving every tool call.
Reaching an agent from outside the IDE. KiloClaw's chat-platform integration (Telegram, Discord, Slack, plus a first-party "Kilo Chat" that needs no token setup) is aimed at triggering agent work from wherever your team already talks, not just from an editor window.

Limitations the launch page won't tell you

"Free" review is a beta condition, not the pricing model. Kilo's docs say compute and review time are free "during limited beta" — Kilo Code credits are still consumed for the model reasoning the reviewer does. Expect that to change once the beta label comes off.
Reviews only see the diff, not the repo. The Review agent explicitly reviews changed files, not the whole codebase — it won't catch a regression in a file the PR didn't touch, even if the PR's logic depends on it.
Worktrees multiply disk usage. Kilo's own docs warn that node_modules, build output, and local databases get duplicated per parallel worktree, and closing a worktree removes its checkout but not external caches, containers, or databases your scripts created outside it — a detail that matters the first time you run five parallel sessions on a monorepo with a heavy install step.
PR badges need a working gh CLI. Agent Manager's PR status detection depends on the GitHub CLI being installed and authenticated locally; without it, badges silently don't appear rather than erroring loudly.
Bot PRs are silently skipped. Dependabot and Renovate PRs don't get reviewed by default. That's a reasonable default for noise reduction, but it also means a dependency bump that introduces a real breaking change gets zero AI review coverage unless you change the setting.
Two upstream codebases means two sets of bugs to inherit. Tracking both Roo Code/Cline and OpenCode upstream means Kilo absorbs upstream regressions from either lineage on top of its own — the tradeoff of not reimplementing either from scratch.

Who should actually try this

Try it now if you're a small team without a dedicated code reviewer and want a first-pass gate on every PR, or if you're already comfortable managing raw API spend and want that model applied to a coding agent instead of a flat subscription. The REVIEW.md mechanism alone is worth evaluating if you've been burned by review bots that can't be told "skip lockfile-only changes."

Wait if you need Agent Manager's parallel-worktree workflow specifically but your team lives in JetBrains or the terminal — that feature isn't there yet, and there's no public timeline for it given the split codebase.

Skip it if your organization has hard constraints around vendor-hosted credit systems and BYOK doesn't fully route around them, or if you specifically want a single, from-scratch codebase rather than a maintained fork of two separate upstream projects — that's a legitimate preference, and Kilo isn't that.

Sources

What's your actual experience with review policy that lives in the repo (REVIEW.md-style) versus review policy locked in a vendor dashboard — has putting it in version control changed how your team argues about review strictness, or just moved the argument into PR comments on the policy file itself?

DEV Community