Most AI coding assistants ship with one model baked in, and everything — the prompts, the tool-calling format, the pricing — is built around that one choice. If you want to run something local, or swap providers, or use a model your company already pays for, you’re usually out of luck, or stuck with a bolt-on integration that clearly wasn’t the primary use case.
xpreiIDE starts from the opposite assumption: the model is yours to choose. Point it at a local Ollama daemon, or any OpenAI-compatible endpoint — OpenAI, OpenRouter, Together, vLLM, LM Studio, whatever you’ve already got running — and everything else works the same way. Chat, an agentic multi-file coder, codebase-aware context, inline edits. No vendor lock-in, no forced cloud round-trip for every keystroke.
Why this is harder than it sounds
The obvious approach to an AI coding agent — native function-calling — assumes the model supports it well. Most small, local, open-source models don’t, or do it unreliably. So xpreiIDE’s agent doesn’t use function-calling at all: it speaks one universal, prompt-based JSON tool protocol that works the same way whether you’re running a 7B model on a laptop GPU or a large hosted one. A weaker model will still reason less well than a stronger one — that part’s unavoidable — but it won’t fall over on the protocol itself, and when it does drift out of format, a built-in retry loop gives it another chance before giving up.
That same philosophy runs through the rest of the feature set:
- Agentic multi-file coding with approval gates, an end-of-run batch diff review (rejected edits never touch disk), one-click revert, and batched multi-edit — all working through that same universal tool protocol.
- Codebase-aware context via a dependency-free local index, plus a
wide set of
@-mentions (@file,@currentFile,@symbol,@diff,@terminal,@url,@search,@repomap,@commits,@os, and more) so you can pull in exactly the context a question needs. - MCP support, exposed through the same prompt-based protocol as every built-in tool — so MCP server tools work on a small local model too, not just on providers with native function-calling.
- Project rules and your own prompt files — a global rules file,
modular glob-scoped rule files, and
.xpreiIDE/prompts/*.mdfiles that become your own/slashcommands.
Everywhere you already work
xpreiIDE isn’t a VS Code-only extension. The engine is shared — one core package, reused across every host — so the same chat, the same agent loop, and the same bring-your-own-model philosophy show up in JetBrains IDEs, Eclipse, and a headless CLI for CI or no-editor workflows:
- VS Code — available today, the full feature set.
- JetBrains — verified in a real sandbox IDE: chat streamed a response from a local Ollama model, and an agent task ran end-to-end with an approval card and a real file edit.
- Eclipse — builds cleanly against a real toolchain, not yet run in a live Eclipse instance.
- CLI — available today, for CI and no-IDE workflows.
What’s next
This is day one. The roadmap keeps closing gaps IDE by IDE, and we’ll be writing about what we learn as we go — what works well on small local models, where the universal tool protocol shows its limits, and what we’re building next. If you want to follow along or contribute, the project is open source: github.com/Babbros-Product/xprei-ide.