The aicommit2 Homebrew build silently drops the Copilot SDK provider

Sixteen providers, and three of them need no API key

The provider table is the centre of this project, and it is unusual in how many rows it has.

Most are ordinary API keys with a default model chosen for you: a small OpenAI model, a dated Claude model identifier, a preview Gemini model, Mistral's small model, Codestral, a dated Cohere command model, a Groq-hosted open model, Perplexity's search model, a DeepSeek model, GitHub Models serving the same small OpenAI model, and a Bedrock model whose identifier is the long cross-provider form.

Three rows are different in kind, and all three are marked as preview.

One runs the Copilot command line tooling with your existing Copilot authentication, which needs a specific permission on your account rather than a key you paste. One runs your locally installed Claude Code command line program against your Claude subscription, explicitly with no API key, and the documentation adds a warning that it is meant for use from a terminal and is not intended to be called from inside an agent session. One runs your installed Gemini command line program with your Gemini login, on either the free tier or a subscription, also with no key.

Those last two warnings matter. A tool that writes commit messages is exactly the kind of program a coding agent reaches for, and one of its providers is documented as not for that use.

There is also an escape hatch: any service implementing the OpenAI request and response specification is supported through its own guide, which is how self-hosted gateways get added without a new row in the table.

The package manager build and the Homebrew build are different products

The installation section recommends Homebrew for macOS and Linux, and then tells you that the Homebrew build is not the whole thing.

brew install aicommit2

The npm route is one command as well, installing the package globally.

The reason is a dependency that cannot be redistributed through that channel. One provider relies on a proprietary dependency, so the Homebrew formula excludes that provider's support entirely, and the instruction is to use the npm installation if you need it.

That is a real difference in what you get, and it is stated in the same place as the install command rather than in a footnote. A user who installs with the recommended path and then configures the excluded provider gets a configuration that cannot work.

The npm route carries its own floor: a minimum Node version of eighteen, with a command to check it. The Homebrew route has no such requirement stated, which is the usual trade for a formula that ships a prebuilt binary.

The third route is a Nix flake, with a command to run it temporarily in the current shell and another to install it into the profile permanently. The short alias has its own repository: the long name and the short name are two different addresses, both pointing at the same program.

So there are three install routes, two repositories for the same command, and one provider that only exists on one of the routes.

The repository type decides whether you stage files first

Three version control systems are supported and the repository is detected rather than configured.

With Git you stage what you want committed and then run the tool, which reads the staged diff. With a dotfiles manager, the same two steps apply with that tool's add command. With Jujutsu the documentation says no staging is needed, because that system records changes as you make them, so the tool runs directly against the working state.

That last point is the substantive difference between the supported systems rather than a cosmetic one. A commit message tool that only reads staged changes has nothing to say in a system with no staging area, and one that reads working changes would produce a different message in Git unless it is careful about which state it reads.

The reactive part of the interface sits on top of this: the documentation describes issuing simultaneous requests to several configured providers and selecting the best message among the results. That is the feature the name refers to, and it is the reason sixteen provider rows exist rather than one with a fallback.

The naming is worth noting for anyone typing it often. Both the long command and a four letter alias point at the same file, and the alias exists because the documentation says the long name is too long to type.

Configuration happens either through an interactive wizard that walks provider selection, key entry and model choice in one step, or through explicit configuration commands that set a provider's key one at a time. At least one provider has to be configured before the tool will do anything.

Diff compression is the only quantified claim in the feature list

The feature list has eight entries and only one of them carries a number.

Diff compression is claimed to reduce token usage by between thirty and sixty percent, with smart compression of the diff before it is sent. That is the claim worth interrogating, because it is the one you would notice on a bill and the one you cannot verify from the documentation. What the compression does to the model's understanding of the change is not described anywhere in the visible sections.

The other entries describe capability rather than magnitude. Multi-provider support is listed as a feature in its own right. The reactive interface that fires several requests at once and lets you pick is listed separately. Structured code review with severity levels happens before you commit rather than after, which is the more interesting placement: the tool can stop you rather than merely describe what you did.

Rewriting the message of an existing commit is available as a separate subcommand, so you can amend without leaving the tool. It can be wired in as a prepare-commit-message hook, which is the integration point that matters for teams, since it means the message is generated before the editor opens rather than after you have already typed something.

There are also integrations for a terminal git client, a watch mode that commits repeatedly, logging settings, and user-defined system prompt templates with example files for both the commit template and the code review template shipped at the repository root.

The manifest version is a placeholder and two lockfiles are committed

The package manifest declares its version as a placeholder string ending in a semantic release marker, which is the convention for a project whose published version is written by release automation at publish time rather than by hand.

That has one visible consequence: the version in the repository is not the version you installed, so anyone comparing them has to look at the release list instead.

The lockfile situation is less tidy. The repository root contains both an npm lockfile and a pnpm one, while the scripts invoke the pnpm package manager throughout, including a prepack step that builds and then cleans the published manifest. Committing two lockfiles in a project that uses one of them is the kind of thing that happens when a contributor arrives with the other one installed, and it never gets cleaned up because neither is wrong enough to break a build.

The build itself bundles and minifies into a single distribution directory, and the published files list contains only that directory, so the templates, tests and documentation stay in the repository.

The release history is a monthly cadence with the last three versions about a month apart, and the branch was last pushed about a week after the newest of them.

The test script runs a directory, and there is a golden corpus harness

The scripts section has two entries that explain how the project is checked.

The test script does not name a test file. It invokes a TypeScript runner with the tests directory as its argument, which means the runner is pointed at a folder and works out what to execute. That works with a runner that accepts a directory and fails quietly in a way you notice later if a file is misplaced, which is a trade this project has evidently made in exchange for not maintaining a file list.

The second entry is more interesting: two scripts for an evaluation harness against a golden corpus, one of which extracts the corpus and the other which runs against it. A golden corpus is the way you check that a change to the prompt template or the diff compression did not make the output worse, and having two scripts rather than one suggests the extraction step is separate because the corpus is checked in and regenerated deliberately.

The linting path is a pre-commit hook wired through a simple git hooks package, running a staged pipeline that formats changed TypeScript files and then lints them. Two configuration styles are present for the linter, which is the same drift pattern as the two lockfiles.

There is also a type check as a separate script rather than part of the build, so a type error does not block a bundle and a bundle does not imply type safety.

Editorial conclusion

This is worth using if you want commit messages from a local model or a subscription you already pay for, because three of its providers need no API key at all and the Jujutsu support means you are not forced through a staging step the other tools cannot do. Two things to check first. Install with npm if you want the Copilot SDK provider, since the package manager build excludes it. And if you intend to drive it from an agent session rather than a terminal, read the warning on the subscription-backed provider, because the project explicitly does not intend that usage.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. tak-bro/aicommit2 on GitHub