aicommit2: a reactive CLI that writes commit messages for Git, YADM and Jujutsu

The problem aicommit2 solves, and the people it is aimed at

Most commit messages are written in the last ten seconds before a push, by someone who has already forgotten why the change exists. aicommit2 attacks that specific moment. You stage your changes, run one command, and the tool reads the staged diff, sends it to an AI provider, and returns a message you can accept or edit. The README frames the project as a reactive CLI for Git, YADM and Jujutsu, with automatic detection of which repository type you are in, so the same command works whether you are committing dotfiles through yadm or working in a jj repository.

The target user is a developer who lives in a terminal. If your workflow is a GUI client with a commit box, this tool adds a step rather than removing one. It is also not aimed at teams that want a fixed commit convention enforced mechanically. aicommit2 writes prose; it does not validate that the prose matches a specification. The README credits AICommits as the inspiration for the core functionality and architecture, which is worth knowing because it means the design lineage is a single-purpose commit-message generator, not a general AI coding assistant.

How the reactive mode and the provider matrix actually fit together

The mechanism described in the README is straightforward: aicommit2 collects the staged diff, optionally compresses it, builds a prompt from a system template, and sends it to one or more configured providers. The reactive part is that it can issue simultaneous requests to multiple AIs and then let you select among the returned messages. That is a different trade-off from picking one model. You pay for several API calls per commit and you read several drafts, but you get a comparison that is hard to do by hand.

The provider list is the widest part of the project. The README documents OpenAI, Anthropic, Google Gemini, Mistral, Codestral, Cohere, Groq, Perplexity, DeepSeek, OpenRouter, GitHub Models, Bedrock and Ollama, plus any service that implements the OpenAI API specification. There are also preview providers that reuse a locally installed CLI instead of an API key: Copilot SDK, Claude Code and Gemini CLI. The Claude Code note in the README is explicit that it runs your local Claude Code CLI with a Pro or Max subscription and no API key, and that it is meant for terminal use of aicommit2 rather than being called from inside a Claude Code agent session. If you are on Homebrew, note the warning that the Homebrew package does not include Copilot SDK support because of a proprietary dependency, so npm is the route for that provider.

Diff compression is the other mechanism worth understanding. The README claims it reduces token usage by 30 to 60 percent with smart diff compression. That claim is the project's own; there is no published methodology behind it, so treat it as a design goal rather than a measured guarantee. The practical consequence is that large diffs are more likely to fit inside a model's context window, which matters most for local models with small windows.

Installing aicommit2 and generating your first message

There are two installation routes in the README: Homebrew for macOS and Linux, and npm everywhere else. The npm route requires Node.js v18 or later, and the README tells you to check with node --version. Pick one:

brew install aicommit2

npm install -g aicommit2

Installing the npm package puts two binaries on your path, aicommit2 and aic2, both pointing at dist/cli.mjs according to package.json. Nothing works until at least one provider is configured. The interactive wizard is the documented default:

aicommit2 setup

The README states the wizard walks through provider selection, API key entry and model configuration in one step. If you prefer to do it by hand, the config command takes dotted keys:

aicommit2 config set OPENAI.key=<your key>
aicommit2 config set ANTHROPIC.key=<your key>

Once a provider is set, stage something and run the tool inside the repository:

git add .
aicommit2

The README notes the same command works in YADM and Jujutsu repositories because the repository type is auto-detected. You should see one or more candidate commit messages and a prompt to accept, edit or discard. For a local model, the Ollama provider is listed with a user-configured model, meaning the README does not pin a default: you supply the model name yourself.

Where aicommit2 stops being the right tool

The clearest limitation is that aicommit2 is a convenience layer, not a policy engine. It generates a message from a diff; it has no documented mechanism for enforcing a commit convention across a team, and no documented verification step that the generated message matches your project's rules. If your release process parses commit messages to compute versions, an AI-written subject line is a new source of variance in that pipeline. You would be relying on the model to follow whatever convention you describe in the prompt template, which is a soft constraint, not a check.

Two more boundaries are visible. First, the npm installation requires Node.js v18 or newer, so a locked-down build image or an older runtime rules out the npm route; Homebrew is the alternative but it drops Copilot SDK support. Second, the preview providers that reuse a local CLI carry their own constraints. The README says the Claude Code provider is not intended to be called from inside a Claude Code agent session, and the Gemini CLI provider similarly depends on your local Gemini login. Those are environment assumptions, and they will bite in a container or a CI runner where no such CLI is authenticated.

Finally, cost and privacy are decisions you make, not defaults the tool makes for you. Reactive mode multiplies requests. A cloud provider sees your diff, which for a private repository or a dotfiles repo managed with yadm is a real consideration. The README's answer to that is Ollama, but the README does not document a default model for it, so you are on your own for choosing one that handles diffs well.

How aicommit2 differs from aicommits and from plain git hooks

The README states that AICommits inspired the core functionality and architecture of aicommit2. That makes AICommits the natural comparison point, and the difference is scope rather than philosophy. Both generate a commit message from a staged diff. aicommit2 adds version control systems beyond Git, specifically YADM and Jujutsu, a wider provider list including local Ollama models and OpenAI-compatible endpoints, and the reactive mode that queries several providers at once. If you only use Git and only want one provider, the extra surface area buys you little.

The second alternative is not another CLI at all: it is a prepare-commit-msg hook wired to a script you maintain. The README lists git hook integration as a feature and the repository ships a .pre-commit-config.yaml, so aicommit2 can occupy that slot. The difference in approach is that a hand-written hook is deterministic and testable, while aicommit2 delegates the text to a model. A hook that appends a ticket number from the branch name will never surprise you. aicommit2 will occasionally produce a message you would not have written, which is either the point or the problem depending on what your history is used for.

Maintenance, release cadence and what the MIT licence means here

The repository is not archived, and the last push was on 2026-09-14, the same day as the v2.12.0 release. The two releases before it, v2.11.1 and v2.11.0, landed on 2026-08-15 and 2026-08-10. That is a compressed release cadence, and package.json shows the version field set to 0.0.0-semantic-release, which indicates releases are cut automatically by semantic-release rather than bumped by hand. Practically, that means version numbers track commit conventions in the project's own history, and a steady stream of patch releases is expected rather than a sign of instability.

Upgrade cost is low by construction. The package is installed globally through npm or Homebrew, so upgrading is a package manager operation rather than a migration. The README has an Upgrading section, though its contents are not shown in the repository's main documentation file. The one upgrade consideration the README does surface is the Homebrew versus npm split: if you later need Copilot SDK support, you have to move from the Homebrew package to npm.

The licence is MIT, which is permissive and imposes no source-disclosure obligation on your own code. The caveat is not legal but practical: the tool sends repository diffs to third-party APIs, so the licence of aicommit2 tells you nothing about the terms of the providers you configure. That is a question for your own review of each provider's data handling, and the README does not answer it.

Editorial conclusion

Adopt aicommit2 if you already commit from a terminal and want the message written by a provider you control, especially if you use Jujutsu or keep a local Ollama model for private diffs. Skip it if you need deterministic, policy-checked messages in CI, or if you cannot install Node.js 18 for the npm route. Before configuring anything, run aicommit2 setup and confirm which provider it selected, because a wrong provider or model is the most likely source of disappointing output.

Frequently asked questions

Official sources

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