If you live in Neovim or Emacs, you probably don’t want to leave your editor to use an AI assistant. Both editors have mature plugin ecosystems with multiple Ollama-backed AI options — some simple chat interfaces, some more ambitious coding assistants with inline completion and code actions. This guide covers the best options for each editor, how to configure them with your local Ollama models, and what to expect from the experience.
Neovim + Ollama: Your Options
Several Neovim plugins connect to Ollama. The main ones worth knowing:
gen.nvim — the simplest option. A lightweight plugin that opens a floating window, lets you write prompts and get responses from any Ollama model. No autocomplete, no code actions — just a clean chat interface inside Neovim. Good for one-off questions and text generation without adding complexity to your config.
ollama.nvim — similar philosophy to gen.nvim but with more Ollama-specific features. Supports model switching, shows model status, and has better streaming output handling. The go-to for users who want a minimal Ollama integration without the overhead of a full AI coding assistant.
avante.nvim — the most ambitious option. Aims to replicate the Cursor AI experience inside Neovim: a sidebar chat panel, inline code editing with diffs, file context awareness, and the ability to apply suggested changes directly to your buffer. Supports Ollama as a backend. More configuration required but significantly more capable for actual coding assistance.
codecompanion.nvim — a well-maintained AI coding assistant with Ollama support. Supports chat, inline completion, code actions (explain, refactor, add tests), and slash commands. Has a growing community and active development. Good middle ground between gen.nvim’s simplicity and avante.nvim’s ambition.
Setting Up gen.nvim
gen.nvim is the fastest to get working. Install with your plugin manager:
-- lazy.nvim
{
"David-Kunz/gen.nvim",
opts = {
model = "llama3.2", -- your preferred Ollama model
host = "localhost",
port = "11434",
display_mode = "float", -- "float" or "split"
show_prompt = true,
show_model = true,
no_auto_close = false,
}
}With gen.nvim loaded, open it with :Gen. You’ll see a floating window with a prompt input. Type your question and hit Enter — the response streams in. Select text in a buffer first and run :Gen to automatically include the selection as context.
Built-in prompts: :Gen Ask, :Gen Change (rewrite selected text), :Gen Chat, :Gen Enhance_Code, :Gen Summarize. You can add custom prompts in your config to match your workflow.
Setting Up codecompanion.nvim
codecompanion.nvim is more powerful than gen.nvim and worth the extra configuration if you want a proper AI coding assistant:
-- lazy.nvim
{
"olimorris/codecompanion.nvim",
dependencies = {
"nvim-lua/plenary.nvim",
"nvim-treesitter/nvim-treesitter",
},
config = function()
require("codecompanion").setup({
adapters = {
ollama = function()
return require("codecompanion.adapters").extend("ollama", {
schema = {
model = {
default = "llama3.2",
},
num_ctx = {
default = 16384,
},
},
})
end,
},
strategies = {
chat = { adapter = "ollama" },
inline = { adapter = "ollama" },
agent = { adapter = "ollama" },
},
})
end,
}Key commands once configured:
" Open chat panel
:CodeCompanionChat
" Inline action on selected code
:CodeCompanionAction
" Quick inline prompt
:CodeCompanion [your prompt here]codecompanion’s inline action menu (triggered on visual selection) gives you options like Explain Code, Fix Code, Add Documentation, Write Tests — all executing against your local Ollama model. The chat panel maintains conversation history and can reference open buffers as context.
Setting Up avante.nvim
avante.nvim requires a few dependencies but delivers the most VS Code-like AI experience in Neovim:
-- lazy.nvim
{
"yetone/avante.nvim",
event = "VeryLazy",
build = "make",
dependencies = {
"nvim-treesitter/nvim-treesitter",
"stevearc/dressing.nvim",
"nvim-lua/plenary.nvim",
"MunifTanjim/nui.nvim",
},
opts = {
provider = "ollama",
ollama = {
model = "qwen2.5-coder:7b",
endpoint = "http://127.0.0.1:11434",
},
},
}Open the avante panel with <leader>aa by default. Select code and ask for changes — avante shows a diff of the suggested edits which you can accept or reject. It reads your entire current file as context, making it better for tasks that require understanding the surrounding code structure.
Figure 1 — Neovim Ollama Plugins: Feature Comparison
Emacs + Ollama: Your Options
Emacs has a rich set of Ollama integrations, benefiting from its long tradition of embedding external tools into the editor environment. The main options:
ellama — the most popular Emacs Ollama package. Provides chat, code completion, text transformation, translation, and custom prompt functions. Works with the built-in Emacs package manager and is straightforward to configure. The primary choice for most Emacs users.
gptel — a general-purpose LLM client for Emacs that supports Ollama alongside other backends (OpenAI, Anthropic, Gemini). If you want to switch between local and cloud models, gptel’s multi-backend support is valuable. Well-maintained and actively developed.
copilot.el + Ollama — uses Ollama as an alternative backend for Copilot-style inline completion. More experimental but interesting if you specifically want tab-completion style suggestions.
Setting Up ellama in Emacs
Install ellama via MELPA (add (require 'package) and MELPA to your init.el if not already configured):
;; With use-package
(use-package ellama
:init
(setopt ellama-language "English")
(require 'llm-ollama)
(setopt ellama-provider
(make-llm-ollama
:chat-model "llama3.2"
:embedding-model "nomic-embed-text"
:host "localhost"
:port 11434)))Key ellama commands once configured:
M-x ellama-chat ;; open a chat session
M-x ellama-ask-about ;; ask about selected region
M-x ellama-improve-code ;; improve selected code
M-x ellama-complete ;; complete selected text
M-x ellama-summarize ;; summarise selected text
M-x ellama-translate ;; translate selected textellama creates a dedicated buffer for each session and supports streaming output. The chat history is preserved in the buffer, making it easy to review previous exchanges. You can have multiple named sessions running simultaneously — useful when you’re working on multiple independent tasks.
Setting Up gptel in Emacs
gptel is a clean alternative, especially if you use multiple LLM backends:
(use-package gptel
:config
(gptel-make-ollama
"My Ollama"
:host "localhost:11434"
:stream t
:models '(llama3.2 qwen2.5-coder:7b phi4 mistral))
;; Set Ollama as the default backend
(setq gptel-backend
(gptel-make-ollama "My Ollama"
:host "localhost:11434"
:models '(llama3.2)))
(setq gptel-model 'llama3.2))gptel integrates with the buffer directly — you can use it in any buffer, including org-mode files. Send the current region, the whole buffer, or type prompts inline. The gptel-send command (bound to C-c RET by default) sends the selected text or current context to the model and inserts the response.
gptel’s org-mode integration is particularly good — it treats org-mode headings as conversation turns, letting you build readable conversation histories directly in org files. For Emacs users who live in org-mode, this is a compelling workflow.
Choosing the Right Model for Editor Integration
For all of these editor integrations, the model choice significantly affects the experience. A few guidelines specific to editor use:
For chat and Q&A (gen.nvim, ellama, gptel in chat mode): A general-purpose 7–8B model is excellent. Llama 3.2 3B is fast enough for quick questions. Llama 3.1 8B or Qwen 2.5 7B gives better responses for complex questions at acceptable speed.
For inline code assistance (codecompanion, avante, gptel inline): A coding-specific model noticeably improves output quality. Qwen 2.5 Coder 7B is the strong recommendation — it’s fast enough for the inline workflow and produces cleaner, more contextually appropriate code than a general model.
For code completion (autocomplete style): Use the smallest fast model you have — StarCoder2 3B or Phi-4-mini. Completion fires frequently and needs sub-second latency. A 7B model generates too slowly for comfortable tab-completion use on most hardware.
The split approach — a fast small model for completion, a larger capable model for chat — is worth setting up in your config if your plugin supports multiple model configurations.
Figure 2 — Terminal Editor AI Workflow: Neovim vs Emacs
Performance Tips for Editor Integrations
Terminal editor AI integrations are more sensitive to model latency than GUI editors because there’s no visual loading indicator — the editor just appears frozen while waiting for a response. A few practices minimise this. Use streaming output wherever your plugin supports it — gen.nvim, codecompanion, avante, ellama, and gptel all stream by default, so tokens appear as generated rather than the whole response arriving at once. Keep OLLAMA_KEEP_ALIVE set high during development sessions so your model stays loaded between queries. Use async completion so the editor remains responsive while waiting for the model — all the plugins above use async calls, but verify your configuration hasn’t accidentally made calls synchronous through a misconfiguration. For models that are too slow for your workflow, try a smaller or more aggressively quantized variant before abandoning the integration — a Q4_0 rather than Q4_K_M quantization sometimes gives 10–15% faster tokens per second with minimal quality difference, which can make the difference between a plugin that feels snappy and one that feels sluggish.
The Case for Terminal Editor AI
The argument for doing AI-assisted coding in Neovim or Emacs rather than switching to VS Code, Cursor, or Zed is straightforward if you’re already a terminal editor user: you get the AI capabilities you need without sacrificing the editor environment you’ve spent years configuring, the keybindings that are muscle memory, or the other plugins that make your workflow productive. The gap between what’s available in Neovim and Emacs versus what’s available in VS Code has narrowed significantly — codecompanion and avante are genuinely good coding assistants, and ellama and gptel are well-designed AI integrations that work naturally in the Emacs philosophy of everything-in-the-editor. They’re not as polished as Cursor or Zed’s built-in AI, but they’re good enough that staying in your preferred editor is the right choice for most users who are already committed to terminal-based development workflows.
Keeping Your Config Maintainable
AI plugins add to already-complex editor configurations. A few practices keep things manageable. Pin plugin versions in your plugin manager rather than always pulling latest — AI plugins update frequently and breaking changes happen. Keep your Ollama model selection in a single variable at the top of your AI config section so you can switch models by changing one line rather than hunting through multiple plugin configs. Use lazy loading aggressively for AI plugins — they don’t need to load on startup, only when you first use them, which keeps editor startup time fast. And document what each plugin does in comments in your config: the difference between gen.nvim and codecompanion isn’t obvious six months later without a note. A clean, well-commented AI section in your init.lua or init.el — with clear model defaults, lazy loading, and your custom keybindings — makes the whole setup easy to revisit, update, and share with other terminal editor users exploring local AI integration.