The Kilo Code plugin for JetBrains IDEs is native. Not a webview, not a VS Code extension in a JetBrains frame. It’s built on the IntelliJ platform, and specifically on JetBrains’ split mode API, which means it works properly when your IDE backend runs on a different machine than your UI.
That second part is the design decision worth explaining, because most AI coding tools in JetBrains handle it differently.
What split mode actually is
Split mode is JetBrains’ name for the architecture behind remote development. The IDE stops being one process and becomes two: a frontend that renders the UI on your laptop, and a backend that holds the project model, indexing, analysis, and execution. The backend can sit on a bigger machine, in a container, or in the cloud.
Developers use it for concrete reasons. More compute than a laptop has. A different OS than the one they run locally. Source code that stays on company servers while they work from anywhere. A thin client instead of a full local checkout.
For plugin authors, split mode changes where your code runs, and JetBrains is blunt about what happens if you ignore it. A plugin that only loads on the backend still technically works, but its UI gets rendered on the backend and shipped to the frontend as drawing commands. Every interaction pays a network round trip. JetBrains’ docs describe the result as UX “of insufficient quality.”
A split plugin avoids that by shipping three sets of modules: a frontend module for UI and anything latency-sensitive, a backend module for file system access, indexing, and project logic, and a shared module defining the RPC interfaces between them.
JetBrains only published guidance for this in spring 2026, and the modular plugin system is still marked experimental in the SDK docs. We build against it anyway, because the alternative is shipping a plugin that degrades the moment someone connects through Gateway.
Why we designed for it up front instead of retrofitting
Our old JetBrains plugin was a webview wrapper. It already had one opaque process boundary: the IDE couldn’t see inside the panel, and the panel couldn’t reach IDE internals except through what we bridged by hand. Adding remote development on top would have meant a second boundary layered on the first.
So when we rebuilt the plugin in Kotlin, we drew the frontend/backend line first and built features on top of it. Chat rendering, scrolling, and input live on the frontend. File indexing for @file mentions, terminal execution, and workspace access live on the backend. The split isn’t a migration we’re partway through. It’s the layout.
How other agents get into JetBrains
There are four routes into a JetBrains IDE right now, and they carry different tradeoffs.
Copilot has a real native plugin, built against the IntelliJ SDK, with its own chat tool window. Credit where it’s due. But remote development has been a long-running sore spot: GitHub’s issue tracker has reports of the frontend component calling backend-only IDE classes, which is exactly the failure mode JetBrains’ split-mode docs warn about, and an open issue from April 2026 describing agent tool calls running on the local client instead of the remote backend where the code lives. Retrofitting is hard even with Microsoft’s resources behind it.
Claude Code’s JetBrains plugin runs the CLI in the integrated terminal and connects over a local bridge, so your interface is the terminal and the IDE lights up around it with diffs and selection sharing. In remote development, Anthropic’s docs tell you to install the plugin on the remote host rather than the client. That’s the backend-only pattern.
Windsurf ships a second plugin just for remote development, installed on both host and client. Two artifacts to keep in sync is what retrofitting looks like when you don’t restructure the modules.
Why we skipped ACP
ACP, the Agent Client Protocol, is an open protocol co-developed by JetBrains and Zed. It standardizes how a coding agent talks to an editor, roughly the way LSP standardized language servers. Implement it once and your agent appears in JetBrains AI Chat, Zed, Neovim, and anything else that speaks it. JetBrains ships support in AI Assistant with a registry you can install agents from.
ACP agent renders inside the host IDE’s chat panel, and that panel has to work for every agent in the registry. It’s the common denominator by design.
That’s the tradeoff. Through ACP we couldn’t show your account balance and per-model pricing in the panel. We couldn’t build our own mode switching, our own approval controls for file edits and terminal commands, or our own MCP server management. We’d get a text chat box and whichever controls the protocol currently exposes. JetBrains has said as much: applying the standard means trading away tailor-made features, and they’re working to bring some of them back into the protocol.
Cursor took this route, which is why using Cursor in IntelliJ means using it inside JetBrains AI Chat rather than a Cursor-designed interface. Copilot took it too, then moved past it: Copilot was reachable through the ACP registry first, and in June 2026 GitHub and JetBrains replaced that with a purpose-built integration for a dedicated login flow and model picker. Even for the largest agent on the market, the generic path left something on the table.
Try it
Search “Kilo Code” in Settings → Plugins. It works in IntelliJ IDEA, WebStorm, PyCharm, GoLand, PhpStorm, Rider, CLion, and RubyMine, in Community and paid editions, locally or through remote development.
Setup instructions are in the JetBrains plugin docs. If you already use Kilo in VS Code or the CLI, your account and keys carry over.
It seems the JetBrains plugin version doesn't support autocomplete? At least, I couldn't find the corresponding option