The lazy.nvim snippet installs parrot.nvim without calling setup

The lazy.nvim recipe installs without ever calling setup

Three install recipes are given and they are not equivalent. The lazy.nvim one is the shortest:

{
  "frankroeder/parrot.nvim",
  dependencies = { "ibhagwan/fzf-lua", "nvim-lua/plenary.nvim" },
  opts = {}
}

There is no `config` function and no call to `require("parrot").setup()`, and the page states that providers must be explicitly set up to become available. So a user who copies this block gets the plugin loaded with no providers at all and an empty option table doing nothing. The Packer recipe on the page does include a config function that calls `require("parrot").setup()`, which is why the omission reads as an oversight rather than a choice. Both recipes carry the comment about optionally adding a notification plugin for better messages, which is the only configuration difference between them.

The dependency list names one fzf plugin and the recipes install another

The dependencies section lists Neovim 0.10 or newer as the hard requirement and `plenary` as the one established plugin that is not optional. Three more are marked optional: ripgrep, fzf described as optional but requiring ripgrep, and telescope. Every install recipe, however, depends on `ibhagwan/fzf-lua` and `nvim-lua/plenary.nvim`. Those are two different things from the dependency list, since the list names the standalone `junegunn/fzf` binary while the recipes pull a Lua wrapper around fuzzy finding. So a reader who installs only what the dependency list says ends up without the plugin the recipes expect, and the optional markers do not explain when the fuzzy finder is needed.

The native package path fetches nothing but the plugin

The third recipe drops the plugin manager entirely and clones straight into Neovim's package directory:

git clone --depth=1 https://github.com/frankroeder/parrot.nvim.git \
  "${XDG_DATA_HOME:-$HOME/.local/share}"/nvim/site/pack/parrot/start/parrot.nvim

The shallow clone is the right call for a plugin of this size, and the destination is the conventional start directory so Neovim will load it without configuration. What the command does not do is fetch dependencies. Plenary and the fuzzy finder are absent, so the same setup that works under a plugin manager does not work here until you install both by hand, and the page gives no second command for that. Of the three recipes, this is the one most likely to end in a plugin that loads and then errors on its first missing require.

Two named providers are not OpenAI-compatible APIs

The provider section is headed by a claim of unified support for any OpenAI-compatible API, and the list underneath it includes the Anthropic API and the Google Gemini API alongside OpenAI, xAI and a local ollama endpoint. Those two do not speak that wire format, so the heading describes the mechanism and the list describes intentions. The configuration example makes the assumed shape concrete: a provider named openai with an api_key taken from the environment and an endpoint spelled out in full as the chat completions path, plus a params block that separates chat settings from command settings, with a temperature of 1.1 and a top_p of 1 for chat. Whether each listed vendor needs a translation layer or its own endpoint is not something the page settles.

The demo section is a list of bare asset URLs

Seven demos are presented and none of them is embedded. Each is a line containing a user attachments asset address placed inside a paragraph element as plain text, so the demo section renders as a column of URLs rather than as playable clips. The first three are visible on the page and cover switching providers and models, triggering completions from comments, and letting the plugin fix bugs. The remaining four are collapsed inside disclosure elements, which describe rewriting a visual selection, appending code with that selection as context, adding comments to a function, and retrying the last operation. Each of those captions names the command it demonstrates, so the section works as a command reference even though the videos do not play.

The whole buffer is the context unless you hide comments

A chat is a markdown buffer, not a separate UI. A new buffer is opened with `:PrtChatNew` and the previous one toggled with `:PrtChatToggle`, you write your instruction after a user prefix marker in the buffer, and the reply streams into the buffer at your cursor. Generation is triggered by a keymap, `<C-g><C-g>` in insert mode by default, or by `:PrtChatRespond`, and stopped with `<C-g>s`. The context rule is the part worth internalising: the entire buffer content is sent as context unless you use hidden comments, so what leaves your machine is decided by how you annotate the file rather than by an explicit selection. System prompts can be set per chat or globally, and chats are saved as markdown files in Neovim's standard path or somewhere you choose.

Credentials can be produced by a command at request time

Keys do not have to sit in your config. Three sources are named: environment variables, bash commands, and password manager command line tools, with the last two evaluated lazily. Lazy evaluation is the point, since a password manager query runs when a request needs it rather than at startup, so the key is never written into a Lua table. Repository-specific instructions come from a `.parrot.md` file picked up with the `PrtContext` command. Two boundaries are stated as design commitments rather than features still to come: there is no autocompletion, and there are no hidden background requests that analyse your files. The plugin also explicitly excludes agents of the kind provided by coding agents and command line tools.

The test target repeats the path its own variable already holds

The build file is three targets long. Tests run headless Neovim with a plenary directory runner, set to sequential, against `tests/`. Linting runs `luacheck` over the `lua/` directory, and formatting runs stylua with the repository's `.stylua.toml` over every Lua file found beneath the current working directory, which is a wider sweep than the lint step and will touch test fixtures as well as the plugin. A variable for the test init file is defined at the top and then not used, because the test recipe spells the same path out inline twice. The history of the project is a changelog file at the root, releases run from v2.5.0 in October 2025 to v2.6.0 in July 2026, and the last commit on the default branch is dated 2026-08-24.

Editorial conclusion

The plugin does one thing and says so plainly, which is worth something: text goes to an endpoint you configure, nothing is sent in the background, and conversations are files you own. If you want that, read the provider configuration examples rather than the feature list, because the provider list overstates what is OpenAI-compatible. Two things to check before it becomes part of your editing loop. The lazy.nvim recipe as written leaves setup uncalled, so no provider exists until you add it yourself, and the context model sends the entire buffer unless you use hidden comments, which means the size of what you send is something you control by how you write comments rather than by a setting. On licensing, the root has a licence file and the recorded field is empty, so read the file before you redistribute anything derived from it.

Frequently asked questions

Official sources

1. frankroeder/parrot.nvim on GitHub
2. Issues
3. README
4. Releases