gptcommit: An LLM Commit Message Hook That Costs N+2 Prompts Per Commit
A git prepare-commit-msg hook for authoring commit messages with LLMs.
At a glance
- What is it?
- gptcommit is a Rust git prepare-commit-msg hook that drafts commit messages through an OpenAI model. Its value depends on whether the per-commit prompt count fits your workflow and your budget.
- Who is it for?
- Adopt gptcommit if you already pay for OpenAI API access, commit frequently from a terminal, and want draft messages without leaving git. Skip it if you use commit templates, work in repos where diffs contain secrets, or need a provider other than OpenAI.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 149 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem gptcommit Targets: Commit Messages Nobody Wants to Write
Writing a commit message is a small task that happens dozens of times a week, and the README frames the tool's purpose directly: generate clear, comprehensive and descriptive commit messages so you can focus on writing code. The audience is developers who already use git from a terminal and already have an OpenAI API key. The tool does not try to be a standalone commit client. It installs itself as a prepare-commit-msg hook, which means the trigger is the ordinary git commit command you were going to run anyway. That placement is the whole design argument. A separate CLI that you invoke before committing adds a step; a hook adds none. The README's own blog post title, never write a commit message again with the help of gpt-3, sets the expectation the project is selling. Whether that expectation holds depends on the model's output quality and on how much of your diff you are willing to send to a third party, and the README does not address the second question at all.
How the Hook Fits Into Git's Commit Pipeline
Git calls prepare-commit-msg after it has assembled the default message but before the editor opens. gptcommit registers a subcommand for exactly that hook stage, listed in the CLI help as prepare-commit-msg with the description run on the prepare-commit-msg hook. The binary also exposes install and uninstall, which write and remove the hook file in the repository. The generation itself is not a single request. The FAQ states that gptcommit issues N+2 prompts, where N is the number of modified files with diffs under the max_token_limit, and the other two prompts produce the title and the summary. That is a per-file summarization pass followed by a synthesis pass, and it explains why the token cost scales with the size of the changeset rather than staying flat. The max_token_limit threshold matters here: files whose diffs exceed it are not summarized as separate prompts, so a commit touching one enormous generated file behaves differently from a commit touching twenty small source files. Configuration is layered. User settings come from $HOME/.config/gptcommit/config.toml, repository settings from $GIT_ROOT/.git/gptcommit.toml, and environment variables prefixed with GPTCOMMIT__ are applied on top, in that order. The README does not document whether the hook fails open (leaving the default message) or blocks the commit when the API call fails, and that is the first thing worth testing in a scratch repository.
Installing the Hook and Setting the Keys That Matter
The recommended path is cargo install --locked gptcommit, with a Homebrew formula at zurawiki/brews/gptcommit for macOS. Installation as a hook is a single command run inside the repository: gptcommit install, which the README says requires an OpenAI API key to complete. The API key can be persisted with gptcommit config set openai.api_key sk-..., or scoped to one clone with gptcommit config set --local openai.api_key sk-.... The environment variable GPTCOMMIT__OPENAI__API_KEY works too, and OPENAI_API_KEY is supported for compatibility with other OpenAI clients, taking the highest precedence. The same pattern applies to the endpoint: gptcommit config set openai.api_base https://... for a self-hosted or proxied gateway, with GPTCOMMIT__OPENAI__API_BASE and OPENAI_API_BASE as environment equivalents. Model selection is gptcommit config set openai.model your-model-name, and the README notes you can point it at a fine-tuned model. Output language defaults to English and accepts en, zh-cn, zh-tw, or ja via gptcommit config set output.lang zh-cn. Two smaller keys are worth knowing: allow-amend true lets the hook rewrite messages on amended commits, and openai.proxy takes an HTTP proxy string. The full list is available through gptcommit config keys, which is the command to run before assuming an option exists.
Why the Hook Silently Does Nothing on Some Commits
The most common failure report in the README is not an error at all. The hook simply does not run. By default it fires only for new commits. If a commit template is configured, or the commit is an amend, gptcommit skips, on the reasoning that the user has supplied their own message and the tool should not overwrite it. The diagnostic is git config --local commit.template, which should be blank if you want the hook active. Amends are re-enabled through gptcommit config set allow-amend true. This is a defensible default and a confusing one for a new user, because nothing in the commit output says the hook declined to run. The other structural limitation is provider lock-in. Despite the generic large-language-models topic on the repository, every configuration path in the README points at OpenAI: an OpenAI key, an OpenAI base URL, an OpenAI model name, OpenAI pricing. The api_base setting is the escape hatch for a compatible gateway, but there is no first-class support for other vendors. Finally, the cost model is user-visible by design. The README tells you to reduce your bill by switching models or shrinking the diff data sent. It does not offer a way to cap the number of per-file prompts, so a large commit is a large request.
gptcommit Versus Writing Your Own prepare-commit-msg Script
The alternative most teams actually weigh is a short shell script in .git/hooks/prepare-commit-msg that pipes git diff --cached into curl and writes the response into $1. That approach gives you total control over which files are included, how the diff is truncated, and which provider you call, and it costs nothing to maintain beyond your own debugging. What it does not give you is the layered configuration, the per-file summarization pass, the language table, or the install and uninstall subcommands. The trade is roughly this: gptcommit is a maintained binary with a defined config surface, and a hand-rolled script is a file you own. If your requirement is a non-OpenAI provider, the script wins immediately, because gptcommit's provider support is expressed through an OpenAI-compatible base URL rather than a provider abstraction. If your requirement is consistent behaviour across a team, the config file at $GIT_ROOT/.git/gptcommit.toml is per-clone and not committed, so neither option gives you a shared, version-controlled policy without extra work.
Maintenance, Licensing, and What the Release Cadence Suggests
gptcommit is MIT licensed, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are retained. That is the standard permissive position; if you vendor or repackage it, keep the LICENSE file intact. The release history shows v0.5.17 in October 2024, v0.5.16 in January 2024, and v0.5.14 in October 2023, with repository activity recorded as recently as April 2026. The gap between the last tagged release and the last push means the install path through cargo install --locked gptcommit will resolve to a published version, not to whatever is on main. If you need a fix that landed after v0.5.17, you are building from source. The other maintenance cost is external and unavoidable: the tool's behaviour is tied to OpenAI's model lineup and pricing. The README's default is described only as the fastest and most cost-effective model available, without naming it, so the actual cost per commit is something you have to measure against your own diffs and your own account. Nothing in the repository can insulate you from a model retirement or a price change.
Who Should Install It, and What to Check First
The fit is narrow and clear. You commit from a terminal, you already hold an OpenAI API key, your repository has no commit template configured, and you are comfortable sending cached diffs to a third-party API. Under those conditions the hook is close to invisible, which is the point. The misfit is equally clear. Repositories containing credentials, customer data, or licensed third-party code in their diffs should not enable this without a deliberate decision about what leaves the machine, and the README offers no redaction or path-exclusion setting. Teams standardized on a non-OpenAI provider should not adopt it unless their gateway speaks the OpenAI API. Anyone who relies on commit templates will find the hook inert until they clear git config --local commit.template. Before rolling it out beyond a test clone, verify three things: whether a failed API call leaves the default message in place or aborts the commit, how many prompts a typical commit in your repository produces given the max_token_limit behaviour, and whether OPENAI_API_KEY is already exported in your shell, since it overrides gptcommit config set without warning.
Editorial conclusion
Adopt gptcommit if you already pay for OpenAI API access, commit frequently from a terminal, and want draft messages without leaving git. Skip it if you use commit templates, work in repos where diffs contain secrets, or need a provider other than OpenAI. Before installing, run gptcommit config keys to see the full option set, and decide whether the default model or a cheaper one fits your usage. Also confirm what your shell exports, because OPENAI_API_KEY takes the highest precedence and will silently override anything set with gptcommit config set.
Community notes