DevoxxGenie IntelliJ Plugin: Local and Cloud LLMs Inside IDEA

What DevoxxGenie solves for IntelliJ IDEA users

The plugin targets a specific gap: an IntelliJ IDEA user who wants an LLM to read the code already open in the editor, without copying files into a browser tab or wiring up a separate chat client. The README describes it as a fully Java-based LLM Code Assistant plugin for IntelliJ IDEA, and the feature list is built around that premise. Review, test and explain are the three verbs in the repository description, and the plugin also adds inline code completion through Fill-in-the-Middle models served by Ollama or LM Studio.

The other half of the pitch is provider choice. The README lists local runtimes (Ollama, LMStudio, GPT4All, Llama.cpp, Nativ, Exo) alongside cloud APIs (OpenAI, Anthropic, Mistral, Groq, Gemini, DeepInfra, DeepSeek, Kimi, GLM, OpenRouter, Cloudflare AI Gateway, Azure OpenAI, Amazon Bedrock, NVIDIA). That breadth is the real differentiator: the plugin is the routing layer, and you decide where inference happens. Teams with a policy against sending source to a third party can point it at a local runtime; teams that want frontier models can add an API key instead. The README claims 114K+ active users, which is a distribution signal rather than a quality one.

The audience is narrower than the provider list suggests. This is for people who live in IntelliJ IDEA, not for people who want an LLM agent in a terminal or a CI pipeline. The repository description mentions CLI Runners and ACP Runners, but those are ways for the IDE plugin to call external agents, not a standalone agent distribution.

How the plugin routes prompts, context and agent tools

The architecture visible in the README is a chat surface plus a set of tools the model can call. Context comes from three sources: the files you attach, a RAG index built from your vectorized project files, and LLM-driven web search via Google Custom Search or Tavily. The README states the plugin supports RAG-based prompt context based on vectorized project files, which means you index the project once and the retriever selects chunks per prompt instead of pasting whole files.

Agent Mode is the layer above chat. The README describes it as autonomous code tools with parallel sub-agents, and it pairs with diff-based review of every file an agent run changes. That diff view is the safety mechanism: an agent that edits files is only useful if you can see what it touched before accepting it. MCP support is mentioned in the same paragraph, so external tool servers can be attached to the agent.

Two newer subsystems change the shape of the plugin. Spec Driven Development defines tasks in Backlog.md, browses them in a Spec Browser with Task List and Kanban Board views, and lets the agent implement them; the Agent Loop runs multiple tasks in a batch with dependency ordering and automatic advancement. Separately, Security Scanning exposes Gitleaks (secret detection), OpenGrep (SAST) and Trivy (dependency CVEs) as agent tools, and the README says findings are automatically created as prioritised tasks in the Spec Browser. That is a closed loop: scan, file a task, let the agent work the task.

The ACP and CLI runners are a different integration path. ACP Runners talk to external agents over the Agent Communication Protocol, described as JSON-RPC 2.0 over stdin/stdout with structured streaming, conversation history and capability negotiation. CLI Runners execute prompts and spec tasks through external CLI tools such as Claude Code, GitHub Copilot, Codex, Gemini CLI and Kimi. In other words, DevoxxGenie can act as the front end while another vendor's agent does the work, which is a pragmatic answer to the fact that the best coding agents are not all available as IntelliJ plugins.

Installing DevoxxGenie and running a first review

The README points to the JetBrains Marketplace listing for the plugin and to genie.devoxx.com for documentation. The installation category of the docs covers local and cloud LLM setup. The repository itself is a Gradle project, which matters only if you intend to build from source rather than install the published plugin. The repository layout includes gradlew alongside build.gradle.kts and settings.gradle.kts, and the README does not document a build command, so building from source means using the Gradle wrapper and the IntelliJ plugin tasks in the build script.

For normal use, install from the Marketplace entry linked in the README, then open the plugin settings and pick a provider. For a local Ollama setup, the plugin needs the Ollama endpoint; the README names Ollama as a supported local provider but does not print the default host and port, so take those from the Ollama documentation and enter them in the DevoxxGenie settings panel. For a cloud provider, the configuration docs cover API keys.

Once a provider is selected, the first useful action is a review of a file you already understand. Open the DevoxxGenie chat window, attach the file, and ask for a review. Because the plugin sends only what you attach (plus retrieved RAG context if you have indexed the project), starting with a single file keeps the first run cheap and makes it easy to judge whether the model is reading the code or guessing.

The inline completion feature is configured separately from chat, because it needs a Fill-in-the-Middle model. The README says FIM suggestions come via Ollama or LM Studio, so a provider that only serves chat completions will not drive inline completion. Set that up as a second step, after chat works.

Where DevoxxGenie is the wrong tool

The clearest limitation is the deployment shape. This is an IntelliJ IDEA plugin. There is no documented headless mode, no server binary and no CI integration in the README. If your goal is to run an agent over a repository on every pull request, DevoxxGenie is the wrong layer; the ACP and CLI runners let the IDE plugin delegate to an external CLI agent, but the orchestration still starts from the IDE.

The second limitation is provider configuration surface. Supporting fifteen-plus cloud providers and six local runtimes means a lot of settings, and the README does not document defaults for any of them. Nothing in the README states what happens when a provider endpoint is unreachable, whether requests time out, or how failures surface in the chat window. The README is silent on rollback for agent edits beyond the diff-based review, so treat that diff view as the only documented checkpoint before changes land in your working tree.

The security scanning feature deserves a specific caution. Gitleaks, OpenGrep and Trivy are external tools, and the README describes them as running from the LLM agent. That implies the plugin invokes them locally, which means their binaries and their own configuration requirements are now part of your setup. The README does not document how those binaries are installed or versioned. If you cannot install and update them yourself, the scanning feature is not usable as described.

Finally, the plugin is Java-based and distributed through JetBrains Marketplace, so it only serves JetBrains IDEs. VS Code users are out of scope entirely, and the README makes no claim otherwise.

DevoxxGenie compared with Continue for IntelliJ

Continue is the obvious comparison, and the related searches show people type both names together. The difference is where each puts its weight. Continue is built around a configuration file that declares models, context providers and custom blocks, and it ships across multiple editors. DevoxxGenie is IntelliJ-only and puts its weight on agentic workflows inside that one IDE: Spec Driven Development with Backlog.md and a Kanban board, an Agent Loop that batches tasks with dependency ordering, security scanning that files findings as backlog tasks, and runners that delegate to external CLI agents over ACP.

That means the choice is not about model support, since both reach local and cloud providers. It is about whether you want a portable assistant configuration or an IDE-native agent with a task backlog. If your team already tracks work in Backlog.md-style markdown and wants the agent to pick tasks up from it, DevoxxGenie's Spec Browser is the feature with no direct equivalent in the comparison. If you need the same assistant behaviour in IntelliJ and another editor, a cross-editor tool is the better fit, because nothing in the DevoxxGenie README suggests it runs outside JetBrains IDEs.

A second axis is extensibility. DevoxxGenie exposes a reflection-based ExternalPromptService so other IntelliJ plugins can send prompts to it at runtime with no compile-time dependency; the README cites a SonarLint fork and a SpotBugs fork that push code-quality findings into DevoxxGenie. That is a plugin-to-plugin integration story, which a standalone assistant does not attempt.

Maintenance cadence, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-10. Releases v1.14.0, v1.14.1 and v1.14.2 landed between 2026-08-24 and 2026-08-26, so the project is shipping at a steady pace and the changelog file at the repository root is the place to read what changed between them.

The licence is MIT. That is permissive: you can use, modify and redistribute the plugin, including in commercial settings, provided the copyright notice and permission notice are preserved. This is a statement about the licence text, not legal advice; if you fork and redistribute, read the LICENSE file in the repository and get your own counsel on notice requirements.

Upgrade cost is the part teams underestimate. The plugin's surface area has grown well past chat: provider integrations, RAG indexing, MCP, agent mode, spec driven development, external CLI and ACP runners, and three external security tools. Each release in the 1.14 line is a minor version bump, and the changelog is where breaking changes to settings or the Backlog.md format would appear. Because agent runs modify files, pinning a version and reviewing the changelog before upgrading is cheaper than discovering a behaviour change mid-task. The README does not document a rollback path for agent edits, so keep agent work on a branch.

Editorial conclusion

Adopt DevoxxGenie if you already work inside IntelliJ IDEA and want one plugin that can point at Ollama, LM Studio or a cloud provider without leaving the editor, and if you are willing to configure API keys and provider endpoints yourself. Skip it if you need a headless CI agent or a Git-hosting bot; this is an IDE plugin and the README documents no server mode. Before committing a team to it, verify that the providers you intend to use are in the supported list, that the Spec Driven Development workflow matches how your team writes Backlog.md, and that you are comfortable with the plugin shelling out to Gitleaks, OpenGrep and Trivy on your machine.

Frequently asked questions

Official sources

1. devoxx/DevoxxGenieIDEAPlugin on GitHub
2. License: MIT
3. Project website
4. README
5. Releases