{"slug": "kilo-codes-jetbrains-plugin-was-built-for-split-mode-from-day-one", "title": "Kilo Code’s JetBrains plugin was built for split mode from day one", "summary": "Kilo Code has released a native Kotlin plugin for JetBrains IDEs built on JetBrains' split mode API, with frontend and backend modules separated so the UI stays local while indexing and execution run on the remote backend. The plugin, which replaces a previous webview wrapper, is designed for remote development from day one, avoiding the performance issues that affect other AI coding tools like GitHub Copilot, which has faced problems with remote development in JetBrains IDEs.", "body_md": "# Kilo Code’s JetBrains plugin was built for split mode from day one\n\n### A native Kotlin plugin split across frontend and backend modules, so the UI stays local while indexing and execution run wherever your code lives.\n\nThe 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.\n\nThat second part is the design decision worth explaining, because most AI coding tools in JetBrains handle it differently.\n\n**What split mode actually is**\n\n[Split mode](https://plugins.jetbrains.com/docs/intellij/split-mode-and-remote-development.html) is JetBrains’ name for the architecture behind [remote development](https://www.jetbrains.com/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.\n\nDevelopers 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.\n\nFor 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.”\n\nA split plugin avoids that by shipping three sets of [modules](https://plugins.jetbrains.com/docs/intellij/modular-plugins.html): 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.\n\nJetBrains only [published guidance for this](https://blog.jetbrains.com/platform/2026/05/make-your-plugin-remote-development-ready/) 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.\n\n**Why we designed for it up front instead of retrofitting**\n\nOur 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.\n\nSo when we [rebuilt the plugin in Kotlin](https://blog.kilo.ai/p/kilo-code-goes-native-on-jetbrains), 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.\n\n**How other agents get into JetBrains**\n\nThere are four routes into a JetBrains IDE right now, and they carry different tradeoffs.\n\n**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](https://github.com/microsoft/copilot-intellij-feedback/issues/588), which is exactly the failure mode JetBrains’ split-mode docs warn about, and an [open issue from April 2026](https://github.com/microsoft/copilot-intellij-feedback/issues/1643) 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.\n\n**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](https://code.claude.com/docs/en/jetbrains) tell you to install the plugin on the remote host rather than the client. That’s the backend-only pattern.\n\n**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.\n\n**Why we skipped ACP**\n\n[ACP](https://www.jetbrains.com/acp/), the Agent Client Protocol, is an open protocol [co-developed by JetBrains and Zed](https://blog.jetbrains.com/ai/2025/10/jetbrains-zed-open-interoperability-for-ai-coding-agents-in-your-ide/). 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](https://www.jetbrains.com/help/ai-assistant/acp.html) with a registry you can install agents from.\n\nACP 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.\n\nThat’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.\n\nCursor 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](https://blog.jetbrains.com/ai/2026/06/github-copilot-now-an-integrated-agent/) for a dedicated login flow and model picker. Even for the largest agent on the market, the generic path left something on the table.\n\n**Try it**\n\nSearch “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.\n\nSetup instructions are in the [JetBrains plugin docs](https://kilo.ai/docs/code-with-ai/platforms/jetbrains). If you already use Kilo in VS Code or the CLI, your account and keys carry over.", "url": "https://wpnews.pro/news/kilo-codes-jetbrains-plugin-was-built-for-split-mode-from-day-one", "canonical_source": "https://blog.kilo.ai/p/kilo-codes-jetbrains-plugin-was-built", "published_at": "2026-08-04 15:55:27+00:00", "updated_at": "2026-08-04 16:37:01.356618+00:00", "lang": "en", "topics": ["developer-tools", "ai-tools", "artificial-intelligence"], "entities": ["Kilo Code", "JetBrains", "GitHub Copilot", "IntelliJ Platform"], "alternates": {"html": "https://wpnews.pro/news/kilo-codes-jetbrains-plugin-was-built-for-split-mode-from-day-one", "markdown": "https://wpnews.pro/news/kilo-codes-jetbrains-plugin-was-built-for-split-mode-from-day-one.md", "text": "https://wpnews.pro/news/kilo-codes-jetbrains-plugin-was-built-for-split-mode-from-day-one.txt", "jsonld": "https://wpnews.pro/news/kilo-codes-jetbrains-plugin-was-built-for-split-mode-from-day-one.jsonld"}}