Model or dataset
devoxx/DevoxxGenieIDEAPlugin avatar
devoxx/DevoxxGenieIDEAPlugin

DevoxxGenie: An IntelliJ Agent That Switches Between Local and Cloud LLMs

DevoxxGenie is an agentic plugin for IntelliJ IDEA that uses local LLM's (Ollama, LMStudio, GPT4All, Jan and Llama.cpp) and Cloud based LLMs to help review, test, explain your project code. Latest version now also supports Spec Driven Development with CLI Runners.

681 stars99 forksJavaMIT

At a glance

What is it?
DevoxxGenie is an MIT-licensed IntelliJ IDEA plugin that routes code review, explanation and spec-driven task execution through either a local runtime such as Ollama or a cloud provider such as Anthropic. The interesting part is the runner abstraction; the part to check before adopting is how much of your code leaves the machine.
Who is it for?
Adopt DevoxxGenie if your team already lives in IntelliJ IDEA and wants one chat surface that can point at Ollama on a laptop or at Anthropic in CI, with Backlog.md as the task record. Do not adopt it if you need a headless agent that runs outside the IDE, or if you cannot accept Gitleaks, OpenGrep and Trivy being invoked by an LLM agent against your working tree.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 2 days ago.
What is it written in?
Mainly Java, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

What DevoxxGenie Is Trying to Replace

The problem it addresses is provider sprawl inside a single IDE session. A Java developer who wants to explain a class with a local model, review a diff with a frontier model, and run a security scan has, without a plugin, three separate tools and three separate context windows. DevoxxGenie puts those behind one chat panel in IntelliJ IDEA. The README lists local runtimes (Ollama, LMStudio, GPT4All, Llama.cpp, Nativ, Exo) and cloud providers (OpenAI, Anthropic, Mistral, Groq, Gemini, DeepInfra, DeepSeek, Kimi, GLM, OpenRouter, Cloudflare AI Gateway, Azure OpenAI, Amazon Bedrock, NVIDIA) as first-class options. The audience is narrow on purpose: IntelliJ IDEA users writing Java, who care about which model sees their source. The plugin is written in Java, which matters if you intend to read the source rather than treat it as a binary. It is MIT licensed, so the code can be forked and modified, though the README does not describe a contribution or release process beyond the version tags.

Agent Mode, MCP and the Runner Layer

The architecture visible in the README is a chat surface plus a set of execution backends. Agent Mode gives the model code tools, and the README mentions parallel sub-agents. Beyond that, there are two runner families. ACP Runners speak the Agent Communication Protocol, described as JSON-RPC 2.0 over stdin/stdout, with structured streaming, conversation history and capability negotiation, and the listed peers are Kimi, Gemini CLI, Kilocode, Claude Code and Copilot. CLI Runners execute prompts and spec tasks through external command line tools such as Claude Code, GitHub Copilot, Codex, Gemini CLI and Kimi. The distinction is worth holding onto: ACP is a protocol with negotiated capabilities, while CLI Runners shell out to a tool and read what comes back. Context comes from RAG over vectorized project files, and the README states that agent runs produce a diff-based review of every changed file. That diff review is the most useful safety property claimed here, because it is the point where a human can see what the agent touched before accepting it.

Spec Driven Development and the Backlog.md File

The SDD workflow is the most opinionated part of the plugin. Tasks are defined in a file called Backlog.md, browsed in a Spec Browser with Task List and Kanban Board views, and then implemented by the agent. The Agent Loop runs multiple tasks in a single batch with dependency ordering and automatic advancement. This is a real design choice with a real cost. Your task state lives in a markdown file in the repository, which means it is diffable and reviewable in a pull request, and it also means merge conflicts on Backlog.md are now a normal part of your workflow. Dependency ordering inside the loop is only as good as the ordering you wrote into the file; the README does not describe a scheduler that resolves cycles or reorders tasks on its own. If you want the agent to run unattended across a batch, you are trusting the file.

Security Scanning Wired Into the Agent

DevoxxGenie exposes Gitleaks for secret detection, OpenGrep for SAST and Trivy for dependency CVEs as tools the LLM agent can invoke. Findings are turned into prioritised tasks in the Spec Browser. The README also points at two proof-of-concept forks, of SonarLint and SpotBugs, that send findings to DevoxxGenie either with one click or as deferred Backlog tasks, using a reflection-based ExternalPromptService that requires no compile-time dependency. The reflection approach is a deliberate trade: other plugins can integrate without a build-time link, and in exchange the integration is resolved at runtime, so a renamed method breaks it silently until someone tests it. Note that Gitleaks, OpenGrep and Trivy are separate tools with their own licences and their own installation requirements; the README does not state that they are bundled.

Getting It Installed and Pointed at a Model

The primary install path is the JetBrains Marketplace listing for plugin 24169-devoxxgenie, which the README links. Configuration is documented on genie.devoxx.com under Installation and Configuration, covering API keys and settings; the README does not reproduce the exact settings keys, so treat the site as the source of truth for provider fields. Two file conventions are stated explicitly. Skills are portable SKILL.md files that you place in ~/.devoxxgenie/skills/, <project>/.devoxxgenie/skills/, .claude/skills/ or .agents/skills/, and the LLM activates them mid-conversation when relevant. The README notes the same files work in Claude Code, Codex and Gemini, and that what used to be called Custom Prompts are now Commands. Inline completion uses Fill-in-the-Middle models served through Ollama or LM Studio, so the model you pick for chat is not automatically the model doing completion. If you are on a team, the project-level .devoxxgenie/skills/ directory is the one to commit, because it travels with the repository.

Where the Plugin Stops Being the Right Tool

The hard boundary is the host application. This is an IntelliJ IDEA plugin, so a headless CI job, a Neovim user or a VS Code team cannot use it as-is, even though CLI Runners let it drive external command line agents. You would be installing an IDE plugin to reach a CLI. The second limitation is provider configuration surface. Fourteen cloud providers and six local runtimes is a long list, and each one needs its own credentials, endpoint and model name; the README does not describe a shared configuration profile, so a team standardising on one setup has to document it themselves. The third is that the README leans on the documentation site for nearly every operational detail, including the SDD task format and the ACP handshake. If genie.devoxx.com does not answer a question about a specific provider, the README will not either. Finally, the README's own framing describes the plugin as a glimpse into a paradigm shift; that is marketing, and it tells you nothing about whether the agent loop will behave on your codebase.

How It Differs From a General Coding Assistant

Compare it with GitHub Copilot, which the README lists as an ACP and CLI Runner peer. Copilot's model is a hosted assistant bound to a subscription and a vendor's model catalogue, with completion as the centre of gravity and the IDE as the delivery surface. DevoxxGenie inverts the provider relationship: the plugin is the client, and you supply the endpoint, whether that is a local Ollama instance or an Anthropic key. The practical difference shows up in two places. First, offline or air-gapped work is possible if a local runtime is configured, which a hosted-only assistant cannot offer. Second, the SDD layer has no equivalent in Copilot's default workflow: Backlog.md as a committed task file and an Agent Loop that advances through it is a different unit of work than a chat turn. The cost of that inversion is configuration and maintenance, which the hosted assistant absorbs for you.

Licence, Upgrade Cost and What to Verify First

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That covers the plugin code. It does not automatically cover the external tools the agent can call: Gitleaks, OpenGrep and Trivy ship under their own licences, and the CLI Runners invoke third-party agents such as Claude Code, Codex and Gemini CLI, each governed by its own terms. Confirm those separately before wiring them into a corporate build. On upgrade cost, the release cadence visible in the material is tight: v1.14.0, v1.14.1 and v1.14.2 landed within three days of each other in August 2026, and the last push to master is dated 2026-09-10. A plugin that moves this fast will occasionally change configuration or file conventions, as it already did when Custom Prompts became Commands. Pin a known-good version for a team rollout and read the release notes before jumping. The README claims 114K+ active users; that figure is the project's own and should not be read as a quality signal either way.

Editorial conclusion

Adopt DevoxxGenie if your team already lives in IntelliJ IDEA and wants one chat surface that can point at Ollama on a laptop or at Anthropic in CI, with Backlog.md as the task record. Do not adopt it if you need a headless agent that runs outside the IDE, or if you cannot accept Gitleaks, OpenGrep and Trivy being invoked by an LLM agent against your working tree. Verify first: which provider you will actually configure, whether your FIM model supports inline completion through Ollama or LM Studio, and whether the SKILL.md files you drop into ~/.devoxxgenie/skills/ are permitted to be read by the model you selected.

Official sources

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

Community notes