llm.nvim: a multi-provider LLM client that lives inside Neovim

The gap llm.nvim fills between editor and provider

Most LLM integrations for editors pick one vendor and one interaction model: a chat pane, or inline completion, or a command that rewrites the selection. llm.nvim instead treats the provider as a swappable detail and the task as the organising unit. The README lists GPT, GLM, Kimi, DeepSeek, Gemini, Qwen and local models such as ollama as supported backends, and states that you can use free models from Copilot, GitHub models, SiliconFlow, openrouter and Cloudflare. The audience is the Neovim user who already has keymaps for everything else and resents switching to a browser to ask a question about the buffer in front of them. That is a narrower audience than a general chat client, and the plugin does not pretend otherwise: it is Lua, it is configured in Lua, and it assumes you are comfortable with both.

Tools, handlers and where the model name actually lives

The architectural idea is the tool. The README states that you can define your own AI tools and that different tools can use different models. That single sentence explains most of the configuration surface. A tool is a named unit with a prompt, a model, and a handler that decides how the result reaches the buffer. The README names four handlers: disposable_ask_handler, attach_to_chat_handler, side_by_side_handler and action_handler. The disposable one is described as one-time with no history retained, which is the right shape for a translation or a docstring. Attach-to-chat appends the current context to an ongoing conversation. Side-by-side and action handlers are the ones used for code optimisation, and the examples show both a side-by-side display and a diff display for the same task. Because the model is a property of the tool rather than of the plugin, you can point a cheap local ollama model at commit messages and a stronger hosted model at code explanation in the same session. Nothing in the supplied material indicates a shared conversation store across tools, so treat each tool as its own context.

Chat UI, streaming and the shortcut help window

Chat is presented in two layouts, float and split, both shown as screenshots in the README rather than described in prose. The README notes that pressing ? displays a shortcut key help window, which is the only documented discovery mechanism for in-chat keybindings. Streaming output is not a global setting: the README links a deepseek example for streaming output and a Code-Explain example for non-streaming output, which implies the choice is made per tool configuration. That is consistent with the per-tool model design, and it also means you cannot assume a single switch turns streaming on everywhere. The Ask tool is explicitly documented as one-time with no history retained, and both Ask and Attach-To-Chat accept an inline_assistant option that controls whether diffs are displayed, with the default being to show them on pressing d. Those two defaults (no history, diff on demand) tell you the plugin expects you to review model output rather than accept it.

Getting it running: environment variable first, examples second

The README is blunt about the precondition: before using the plugin you should ensure that your LLM_KEY is valid and that the environment variable is in effect. That is the failure mode most first-time users will hit, because a key exported in a shell profile is not necessarily visible to a Neovim instance launched from a desktop launcher or a multiplexer with a stale environment. The README directs readers to the examples directory for configurations of different LLMs such as ollama and deepseek, for UI configuration, and for AI tools including code completion, and it says the examples contain most of the information you want to know. It also points to a wiki and a docs directory. The minimal installation example and the dependencies section exist in the README, but the supplied text does not include their contents, so the exact plugin-manager snippet and the dependency list cannot be reproduced here. What can be said is that the configuration keys visible in the material are diagnostic, lsp, inline_assistant and enable_cword_context, and the diagnostic key takes values from vim.diagnostic.severity, for example diagnostic = { min = vim.diagnostic.severity.HINT } or a list such as { vim.diagnostic.severity.WARN, vim.diagnostic.severity.ERROR }.

Diagnostics, LSP and web search as context sources

Three features push the plugin past a chat wrapper. Diagnostics can be attached to the disposable ask, attach-to-chat, side-by-side and action handlers by setting the diagnostic key, so a prompt can carry the current file's warnings and errors. LSP support is newer and the README labels it as still in continuous iteration, with the same three handlers (disposable ask, attach-to-chat, action) able to enable it; the configuration shape shown is a per-language table, for example lsp = { cpp = { methods = { "definition", ... } } }, though the supplied text truncates the method list. Web search is exposed through slash and at commands in chat: /buffer, /file and @web_search, documented in docs/functions. The combination is what makes the plugin worth the configuration: a prompt can be grounded in the buffer, the file, a web search or the language server's view of the code. Note the asymmetry, though. Diagnostics and LSP are opt-in per handler, and the LSP feature is explicitly described as iterating, so treat it as the least settled part of the surface.

Where llm.nvim is the wrong choice

The plugin has no homepage listed and no default configuration that works without a key. Its documentation strategy is to route you to examples, a wiki and a docs folder, which is fine for a tinkerer and poor for someone who wants a working chat pane in five minutes. If your only requirement is inline completion from a single provider, a narrower plugin will be easier to keep working, because llm.nvim makes you choose a provider, a model, a handler and a UI before you get output. There is also a licensing consideration: the project is GPL-3.0. If you copy configuration or code from the plugin into something you distribute, the GPL's terms apply to that distribution. This is not legal advice, and the boundary between configuration and code is exactly the kind of question to put to someone qualified if it matters to you. Finally, the README warns that free tiers from Copilot, GitHub models, SiliconFlow, openrouter and Cloudflare are usable, but free tiers change their terms and rate limits without asking plugin authors, so a working setup can stop working for reasons that have nothing to do with a plugin update.

Maintenance cost and the upgrade question

The release cadence visible in the material is three releases in roughly three months: v1.2.0 on 2026-03-07, v1.2.1 on 2026-03-11, v1.3.0 on 2026-04-19, with the last push to the default branch on 2026-06-20. That is a project under active change, which cuts both ways. You get fixes and new providers; you also get configuration drift. Because each tool is configured separately, an upgrade can require edits in several places rather than one, and the examples directory is the reference you will be diffing against. The practical mitigation is to keep your tool definitions in one file that you can compare against the upstream examples after each release, rather than scattering them across your init. If you are on a Neovim distribution that pins plugin versions, pin this one too and read the release notes before moving. Nothing in the supplied material describes a migration guide or a deprecation policy, so assume there is none and budget the comparison time.

How it compares with a single-provider editor plugin

The closest alternative in shape is a single-provider plugin such as one of the Copilot integrations: you authenticate once, you get completion and sometimes a chat command, and the provider decides what models you can reach. llm.nvim inverts that. You bring the key, you name the model, you write the prompt, and the plugin supplies the plumbing (handlers, UI, buffer and file context, diagnostics, LSP, web search). The difference shows up when you want two behaviours at once: a local model for a private buffer and a hosted model for a public one, or a fast model for commit messages and a slower one for explaining a function. A single-provider plugin cannot express that, and llm.nvim expresses it as two tool definitions. The cost of that expressiveness is that the plugin cannot tell you which model is good. It gives you a slot and expects you to fill it, which is why the examples directory carries so much of the documentation weight.

Editorial conclusion

Adopt llm.nvim if you already live in Neovim and want several providers and several task-specific prompts reachable from keymaps without leaving the editor. Do not adopt it if you want a single chat window with one model and no Lua configuration; the examples directory is the product, and reading it is the setup. Before committing, verify that your LLM_KEY environment variable is exported into the Neovim process, since the README states the key must be valid and in effect, and check the examples for your specific provider rather than assuming the defaults match it.

Official sources

1. Issues
2. Kurama622/llm.nvim on GitHub
3. License: GPL-3.0
4. README
5. Releases