Kilo Code is an open-source AI coding agent for VS Code, JetBrains IDEs and the command line. Its main appeal is freedom: developers can switch between hundreds of hosted models, bring their own provider keys, connect supported subscriptions or run models locally instead of committing to one AI vendor.

That flexibility is useful, but it also creates the main weakness covered in this Kilo Code review. Model choice, context indexing, agent permissions and usage-based billing all need active management. A cheap model that loops through the same failed edit can cost more than a stronger model that completes the task cleanly.

Our evaluation focuses on how Kilo’s current Plan, Code and Debug agents fit together, how repository context is assembled, what its permission controls can and cannot prevent, and how the real bill changes across lightweight and frontier models. We also compare Kilo Code with Roo Code, Cline, Cursor and Claude Code to show where the open-source approach earns its setup cost.

Kilo Code review summary

Area	Verdict
Best for	Experienced developers who want model freedom across VS Code, JetBrains and CLI workflows
Main strength	Open-source agent runtime with broad provider choice, granular permissions and usage visibility
Main weakness	More configuration and cost management than a fixed-subscription coding IDE
Pricing model	Free individual software, then free, local, BYOK or pay-as-you-go inference; optional Kilo Pass and paid team controls
Repository handling	Direct file tools plus optional semantic indexing, custom rules and ignore files
Safety	Good permission granularity, but dangerous commands remain possible when broad auto-approval is enabled
Overall verdict	Worth testing for developers who value control more than a zero-configuration experience

DIY AI verdict: Kilo Code is one of the more credible open-source alternatives to proprietary AI coding environments. It is especially attractive for JetBrains users, teams already paying several model providers and developers who want to assign different models to planning, implementation and debugging. It is less convincing to someone who wants a predictable monthly price and never wants to think about provider keys, token rates, or permission files.

---

---

What Kilo Code actually is in 2026

Kilo Code is the local coding-agent layer, not the underlying language model. The open-source software reads files, searches the repository, proposes edits, runs commands, and passes selected context to the configured model. Kilo Gateway is an optional hosted inference and billing layer that consolidates many providers under a single account.

This separation explains both the product’s value and its complexity. Two developers can install the same Kilo extension and get very different results because one uses a frontier model with semantic indexing and cautious permissions, while the other uses a free model with limited context and broad command approval.

Kilo currently spans three useful local surfaces:

• VS Code: the widest editor audience and the most visible interface for agents, diffs, model selection and permissions. The current extension is distributed through the Marketplace’s pre-release channel, although Kilo describes it as the recommended build.
• JetBrains: a native plugin for IntelliJ IDEA, WebStorm, PyCharm, PhpStorm, GoLand, Rider, CLion, RubyMine and DataGrip. It does not require Node.js and is a meaningful differentiator for teams comparing AI coding tools for JetBrains.
• CLI: the same core agent model in a keyboard-first interface, suitable for remote development, scripted tasks and developers who prefer terminal workflows.

Open source does not mean every model is open-weight or every request is free. Claude, GPT and Gemini models still incur their normal provider charges. The practical benefit is that Kilo does not force one provider, one IDE or one billing route.

The agent modes have changed, and older reviews are already misleading

Kilo’s terminology is moving from modes to agents. Current documentation describes four core agents: Code, Ask, Plan and Debug. Some package copy and older material still refer to Architect, Coder, and Orchestrator, which makes the workflow look more complicated than it is now.

Current agent	What it should do	Recommended use
Plan	Reads the project and writes planning material without broad implementation access	Architecture, scope, dependencies, migration sequencing and acceptance criteria
Code	Reads, edits and executes tools with the permissions you grant	Feature implementation, refactoring, tests and routine fixes
Debug	Uses full tools with a troubleshooting-oriented system prompt	Reproduction, log inspection, hypothesis testing and narrow repairs
Ask	Investigates with read-only tools	Code explanation, repository questions and low-risk discovery

The dedicated Orchestrator agent is being retired. Code, Plan and Debug can delegate isolated work to subagents, so users no longer need to switch into a separate orchestration mode before a complex task. This is a sensible simplification, but it changes how Kilo should be tested.

Do not judge orchestration by asking one agent to “build the whole feature”. Give Plan a bounded design task, review its assumptions, then let Code implement one accepted slice. Use Debug only after you can state the failing behaviour and expected result. This reduces token waste and makes it easier to identify whether a failure came from the model, from missing context, or from an unsafe tool decision.

A practical Kilo Code workflow that controls cost and mistakes

The best Kilo workflow is a gated sequence rather than a single autonomous run:

1. Investigate with Ask. Identify entry points, dependencies, existing tests and files that must not change.
2. Design with Plan. Require a file-level implementation plan, risks, rollback route and test criteria.
3. Review the plan manually. Reject speculative rewrites, unrelated cleanup and dependency changes that are not required.
4. Implement with Code. Apply one coherent slice at a time, with command and edit permissions still set to Ask where risk is meaningful.
5. Validate with tests and static checks. Do not accept the agent’s own summary as evidence that the task works.
6. Use Debug on a reproducible failure. Supply the command, error output and expected behaviour rather than asking it to search indefinitely.
7. Review the complete diff. Look for configuration drift, weakened validation, removed error handling and generated comments that add no value.

This process sounds slower than granting full autonomy, but it usually lowers total time and spend. Long open-ended prompts encourage repeated repository scans, speculative edits and retries. The cheapest request is the one that does not need to be undone.

Model switching is useful only when it follows a routing policy

Kilo promotes access to more than 500 models. That is genuine breadth, but model count is a poor buying criterion. Most developers need three dependable routes, not hundreds of favourites:

• Low-cost route: repository exploration, summaries, test scaffolding, documentation and mechanical changes.
• General coding route: normal feature work, refactors and bug fixes where tool-use reliability matters.
• Escalation route: architecture, difficult debugging and high-risk migrations where a failed approach costs more than stronger inference.

A broad model catalogue becomes counterproductive when developers switch after every imperfect answer. Different models interpret repository rules, tool results and prior decisions differently. Mid-task switching can improve a stalled session, but it can also lead to duplicated exploration or to a new implementation strategy that conflicts with earlier edits.

Set a default model per agent and define an escalation rule. For example, use an economical model for Ask, a balanced coding model for Code and a frontier reasoning model only for Plan or difficult Debug sessions. DIY AI’s comparison of the best AI models for coding value provides a useful starting point, but the final choice should be checked against your language, repository size and tool-calling workload.

Kilo Code pricing: the software is free, the workflow is not

Individual use of Kilo Code is free and open source. Developers then choose how inference is paid for: free routed models, their own API keys, supported subscriptions, local models or Kilo Gateway credits. The current Kilo Code pricing lists Teams at $15 per user per month, while individual Gateway access has no monthly platform fee and charges model usage at provider rates.

Kilo Pass is optional. Its listed tiers are $19, $49, and $199 per month, with the payment converted into credits and bonus credits added under the current scheme. This can suit consistent users, but the bonus does not make an inefficient workflow cheap. Paid credits may roll differently from monthly bonus credits, and free bonus credits expire at the end of their cycle.

The table below illustrates the model costs for three hypothetical workloads, using rates displayed in Kilo’s model catalogue on 13 July 2026. These are not promises about how many tokens a task will consume. They exclude retries, embedding costs, background summarisation and any paid external tools.

Illustrative workload	Token volume	Qwen3.6 Plus $0.50 in / $3 out	Claude Sonnet 4.6 $3 in / $15 out	GPT-5.5 $5 in / $30 out
Targeted fix	120k input, 12k output	$0.10	$0.54	$0.96
Medium feature	600k input, 60k output	$0.48	$2.70	$4.80
Large refactor	2.5m input, 250k output	$2.00	$11.25	$20.00

The token price still does not reveal the cost per successful task. If a $0.48 model run misses the requirement, rewrites unrelated files and needs three retries, it can cost more than a $2.70 run that finishes correctly. Developer review time widens that gap further.

The hidden Kilo Code costs most pricing pages miss

Repeated context is often the highest cost

Agentic coding repeatedly sends instructions, file extracts, tool output and conversation history back to the model. A repository does not need to fit into one prompt for usage to grow quickly. Long sessions can reprocess the same context multiple times, although prompt caching may reduce the charge when supported by providers.

Indexing has setup and embedding overhead

Kilo’s semantic codebase indexing is opt-in. It parses code into blocks, creates embeddings and stores vectors in LanceDB or Qdrant. A local Ollama and LanceDB setup can avoid hosted embedding charges, but it adds local compute and configuration. Larger teams may prefer Qdrant, which introduces another service to secure, monitor and back up.

Free models can create expensive review work

Free routing is useful for experimentation and low-risk tasks. It is a weak default for confidential repositories or important migrations because the underlying provider can change and some free endpoints may log prompts for service improvement. A zero-token bill is not a saving if the output needs extensive repair.

Configuration has an ownership cost

Someone must maintain model defaults, provider keys, project rules, ignore patterns, permissions and spending controls. For one developer this is manageable. Across a team, unmanaged personal configurations make results hard to reproduce and security decisions hard to audit.

Repository indexing improves discovery, not correctness

Semantic indexing can help Kilo find authentication logic, database access or similar implementations without knowing exact filenames. It does not prove that the retrieved files are the right source of truth. Generated files, duplicate legacy modules, and stale migrations can all be semantically relevant yet still be wrong for the current task.

A reliable repository setup needs three layers:

• Exclusions: use .kilocodeignore and existing ignore rules to keep dependencies, generated assets, secrets and irrelevant archives out of discovery.
• Project rules: record architecture constraints, test commands, coding standards and files that must not be edited.
• Verification commands: give the agent exact lint, type-check, unit-test and integration-test commands rather than asking it to decide what “working” means.

Index status also needs to be checked after branch changes, dependency updates, or large refactors. Good semantic retrieval reduces search friction. It does not replace current documentation, tests or developer judgement.

Kilo Code permissions are granular, but unsafe approval is still unsafe

Kilo uses Allow, Ask, and Deny rules for tools such as reading, editing, shell commands, file search, and external directory access. Rules can be global or narrowed to command and path patterns. This is better than one blanket “autonomous mode” switch because a team can allow harmless reads while requiring approval for edits and commands.

The dangerous shortcut is setting every tool to Allow. An agent with unrestricted shell and file access can remove files, alter configuration, expose environment values or run destructive package scripts. Kilo’s own warning is blunt because the risk is real.

A safer starting policy is:

• Allow reads, filename searches and content searches inside the project.
• Ask before edits, package installation, database commands, Git writes and network calls.
• Deny destructive shell patterns and access outside the repository unless a task specifically requires them.
• Keep API keys in environment variables rather than committed configuration files.
• Use a disposable branch, worktree or container for broad refactors and unfamiliar repositories.

Kilo also offers sandbox controls on macOS and Linux, but the sandbox is disabled by default, and Windows does not currently receive the same sandbox settings. Permission prompts therefore remain the primary protection for many users.

Kilo Code versus Roo Code, Cline, Cursor and Claude Code

Tool	Where it wins	Where it loses	Best fit
Kilo Code	Model breadth, VS Code plus JetBrains plus CLI, open-source runtime, granular routing and permissions	Configuration overhead, variable spend and a fast-moving interface	Developers who want control across several IDEs and providers
Roo Code	Highly configurable VS Code workflows, modes and provider choice	More VS Code-centred and can consume substantial context in long agent runs	Power users who enjoy tuning agent behaviour
Cline	Clear approval-led workflow, open-source software and a mature agent pattern	Usage costs can rise quickly and model freedom still requires active provider management	Developers who value explicit review of each action
Cursor	Polished integrated IDE, quick onboarding and predictable starting subscription	Proprietary environment with less control over the complete routing and product layer	Developers who prioritise convenience and daily editing flow
Claude Code	Strong long-horizon reasoning and a focused terminal-native experience	Claude-centred model choice and potentially high subscription or API spend	Complex repository work where model consistency matters more than provider choice

A recurring real-world pattern is that developers rarely settle on a tool because it lists the most models. They stay with the product that gives them dependable context selection, visible diffs, understandable costs and enough control to stop a bad run. Kilo competes well in terms of control, but its fast-moving v7 interface has also frustrated users who preferred the visibility and review flow of earlier builds.

Kilo is the strongest choice in this group when JetBrains support and provider freedom are both requirements. Cursor remains easier for a developer who wants a polished default. Claude Code is harder to beat for teams already committed to Claude and willing to pay for consistent deep-agent work. Roo Code and Cline remain credible alternatives for VS Code users who already understand usage-based agent economics.

Common Kilo Code mistakes

• Choosing the cheapest model for every agent. Planning and difficult debugging often need stronger reasoning than repository search or documentation.
• Switching models during every failure. First check context, permissions, tests and task scope. The model may not be the cause.
• Enabling all auto-approvals. Speed is not worth removing the control boundary around shell commands and edits.
• Indexing everything. Generated code, old copies and dependencies can pollute retrieval and waste embedding work.
• Using one long session for unrelated tasks. Old context increases cost and can steer the agent towards stale assumptions.
• Comparing subscription prices without inference. Kilo Teams is not an all-inclusive model plan. Cursor and Claude subscriptions have their own usage policies and limits.
• Accepting a successful command as a successful feature. A passing unit test can still miss broken permissions, migrations, UI states or production configuration.

Who should use Kilo Code?

Kilo Code is a good fit for experienced developers who already know how to review diffs, restrict commands and diagnose a bad agent run. It is also compelling for JetBrains teams that want access to a model-agnostic coding agent without moving into a separate AI-native IDE.

It makes particular sense when a developer already has provider credits or subscriptions, wants to use local models for sensitive work, or needs different models for planning and execution. Shared team modes, billing and controls become more valuable once several developers need consistent configurations.

Who should avoid Kilo Code?

Choose a simpler product if you want one installer, one model policy and one predictable bill. Kilo can be configured to feel straightforward, but its advantage lies in its options. Ignoring those options leaves you with extra product complexity and little benefit.

It is also a poor choice for users who cannot confidently review code changes or command prompts. The agent can produce useful work, but permissions do not validate architecture, security or business logic. Less experienced developers may be safer with a narrower, approval-heavy workflow and small tasks until they can recognise a plausible but incorrect change.

Kilo Code verdict: excellent control, but only with a disciplined setup

Kilo Code earns attention because its open-source runtime, multi-platform support and provider freedom solve real constraints. It lets a developer keep VS Code or JetBrains, use the CLI when appropriate and route different jobs to different models without adopting a proprietary editor.

The trade-off is operational responsibility. Model choice needs a policy. Indexing needs exclusions. Permissions need least-privilege defaults. Costs need to be measured per completed task rather than per million tokens. Teams that implement those controls get a flexible agent platform. Teams that do not may simply create a more configurable way to waste tokens and approve risky changes.

Start with Ask and Plan, choose one economical model and one escalation model, leave edits and shell commands on Ask, and test Kilo on a bounded repository task with clear acceptance criteria. That trial will reveal more than any model-count claim.

Kilo Code FAQ

Is Kilo Code free?

The individual Kilo Code software is free and open source. AI inference may still cost money unless you use free routed models, a supported subscription or a local model. Teams adds a per-user platform charge for shared administration and controls.

Does Kilo Code work with JetBrains IDEs?

Yes. Kilo provides a native JetBrains plugin that supports major IDEs, including IntelliJ IDEA, WebStorm, PyCharm, PhpStorm, GoLand, Rider, CLion, RubyMine, and DataGrip.

Is Kilo Code better than Cursor?

Kilo offers more provider and platform control, while Cursor offers a more integrated, easier-to-use default experience. Kilo is better for developers who want BYOK, local models or JetBrains support. Cursor is usually easier for someone who wants an AI-native IDE with less configuration.

What happened to Kilo Code Orchestrator mode?

The dedicated Orchestrator mode is deprecated. Current full-access agents, such as Code, Plan, and Debug, can delegate work directly to subagents, reducing the need for a separate orchestration step.

Can Kilo Code run local models?

Yes. Kilo supports local and OpenAI-compatible endpoints, including setups based on Ollama or LM Studio. Local inference removes hosted token charges, but shifts costs to hardware, setup, speed, and model capability.