CodeCompanion.nvim

You will keep this one. The conversation happens in an ordinary buffer, so your own motions, folds and search work on it, and that is the deciding daily trait: nothing about the interface asks you to learn a second editor. Refactors happen in place, a prompt library saves the things you type twice, and the provider list is long enough that whatever you already pay for is on it.

Pick it if you want one plugin to cover most of what you do. Pick avante.nvim if what you actually want is fast suggestion and one-key application.

Count the products. Conversations, in-place transformations, a prompt library, multi-step workflows, a review interaction and a bridge to half a dozen external agent binaries all live in one plugin maintained by one person. Each of those is a reasonable project on its own, and together they are more integration points than any single maintainer can regression-test, so breakage arrives in the corner you happen to use.

What it does right: the review interaction requires you to approve or reject each change, so the most dangerous feature is the one guarded most explicitly.

1. Context gathering is explicit: the chat buffer holds the references the user added, so the model's inputs are visible text rather than a retrieval decision made elsewhere, and the token cost of a turn can be read off the screen. 2. Edit application rewrites the buffer directly, keeping the editor's own undo as the rollback mechanism, which is a better safety net than most bespoke diff appliers.

No benchmark is claimed, and the documentation site is the only source for any of this. The observation: designs that reuse the editor's primitives tend to survive model changes, because they never depended on the model.

This is the strongest single-maintainer asset in the editor category, and that description contains the risk. Nearly seven thousand stars is real distribution, and there is no entity to receive value from it, which means maintenance depends on one person's continuing interest rather than anybody's payroll. Projects in this shape either recruit co-maintainers or slow down, and the transition is rarely announced.

Likely path: the maintainer is hired by a company that wants the audience, and the plugin becomes a hobby again. Position: adopt freely, and watch the commit cadence rather than the star count.

One sentence on the demo: the reviewer step is the part I liked. Commercially this is the cheapest row on the board, because the plugin costs nothing and the inference can run through a subscription we already hold rather than a new provider agreement, which removes an entire procurement cycle. Against that, there is no console, no policy surface and no identity integration, and nothing here runs unattended in our pipelines.

Onboarding is an hour for engineers already in this editor and irrelevant to everyone else. Approved with conditions: personal tooling, existing subscription only.

This is the one I would run air-gapped without complaining. My local server is a supported adapter rather than a workaround, and writing a custom adapter for anything else is a small Lua table, so no provider is privileged and no key leaves my machine unless I send it. The tool-protocol client means the servers I already maintain attach without a shim.

The whole configuration is a table in my dotfiles, so it travels with me and diffs like code. Permissive licence, readable source, no telemetry to hunt for. That is ownership, and it is rare enough to say plainly.