# OpenCommit: a git commit message generator that runs on OpenAI, Claude, Gemini or a local Ollama model

> OpenCommit wraps your staged diff and asks an LLM for a Conventional Commit message, with a global config file, per-repo overrides and an Ollama path for local models. The npm package is the real product; the GitHub Action releases are from 2023.

**di-sukharev/opencommit** — top #1 and most feature rich GPT wrapper for git — generate commit messages with an LLM in 1 sec — works with Claude, GPT and every other provider, supports local Ollama models too

- Repository: https://github.com/di-sukharev/opencommit
- Website: https://www.npmjs.com/package/opencommit
- Stars: 7,544 · Forks: 444
- Language: JavaScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/di-sukharev-opencommit

## The problem OpenCommit solves, and the developers it is aimed at

Writing a commit message is a small task that gets skipped under deadline pressure, and the result is a history full of "fix", "wip" and "update stuff". OpenCommit takes the staged diff, sends it to a language model, and returns a formatted commit message. The README frames the goal bluntly: "Killing lame commits with AI".

The target user is a developer who already works in a terminal, already has an API key for a hosted model or a local Ollama install, and wants the message written without switching to a browser tab. The project ships a single command, oco, installed globally through npm. It is not a Git GUI, not a pre-commit hook framework, and not a replacement for review. It sits between git add and git commit.

Because the message is generated from the diff, the quality of the output depends on how much context the diff carries. A one-line change to a config value gives the model very little to work with. A multi-file refactor gives it plenty. That relationship is inherent to the approach, and the README does not claim otherwise.

## How oco turns a staged diff into a commit message

The mechanism is a wrapper around git plus an HTTP call. The package exposes two binaries, opencommit and oco, both pointing at out/cli.cjs. When you run oco, the CLI collects the staged changes, which is why the README notes that running git add is optional and that oco will stage files for you. The diff is assembled into a prompt, tokenised, and sent to the configured provider. The response is parsed and printed as a commit message for confirmation.

Provider selection is a config value, not a separate binary. OCO_AI_PROVIDER accepts openai (the default), anthropic, azure, ollama, llamacpp, gemini, flowise, deepseek, aimlapi, openrouter or orcarouter. The model is OCO_MODEL, defaulting to gpt-4o-mini. Token budgets are explicit: OCO_TOKENS_MAX_INPUT defaults to 4096 and OCO_TOKENS_MAX_OUTPUT to 500. There is also OCO_REASONING, which overrides reasoning-model auto-detection with true or false and is omitted by default, plus OCO_REASONING_MAX_TOKENS defaulting to 1000 for the completion budget including hidden reasoning tokens.

The output shape is controlled by OCO_PROMPT_MODULE, which takes either conventional-commit or @commitlint. Emoji support is a boolean, OCO_EMOJI, and by default it uses a short set of ten emojis rather than the full GitMoji specification. The README explains the reason: limiting the number of tokens sent in each request. The --fgm flag switches to the full specification.

Two details matter for anyone integrating this. The config file lives at ~/.opencommit, and a local .env in the repository takes priority over the global file. The README suggests setting OCO_MODEL and OCO_LOCALE globally while keeping OCO_EMOJI and OCO_DESCRIPTION per repo. The .opencommitignore file at the repository root is the mechanism for excluding paths from what gets sent.

## Installing OpenCommit and generating your first commit

Installation is a global npm install. The README gives this as the first step, and it requires Node and npm on the machine.

```bash
npm install -g opencommit
```

After installation you have both opencommit and oco available on your PATH. The next step is an API key. The README points at the OpenAI platform for the key and notes that payment details must be added to the account for the API to work. The key goes into the OpenCommit config, which is stored locally in ~/.opencommit.

```bash
oco config set OCO_API_KEY=<your_api_key>
```

Now stage something and run the command. The README shows git add followed by oco, and notes that the git add step is optional because oco stages files itself.

```bash
git add <files...>
oco
```

The CLI prints a generated message and waits for confirmation before committing. If you want it to commit without asking, the README documents the --yes flag.

```bash
oco --yes
```

To run against a local model instead of a hosted API, install and start Ollama, pull a model once, then point OpenCommit at it. The README uses mistral as the default and shows llama3:8b as an alternative.

```bash
ollama run mistral
oco config set OCO_AI_PROVIDER='ollama' OCO_MODEL='llama3:8b'
```

If Ollama runs on another machine with GPUs, OCO_API_URL points at it. The README gives this example with 192.168.1.10 standing in for the real address.

```bash
oco config set OCO_API_URL='http://192.168.1.10:11434/api/chat'
```

A documented failure mode appears right after this section: a connection refused error on ::1:11434 means Ollama is not listening on IPv6. The README's fix is to export OLLAMA_HOST=0.0.0.0 before starting Ollama, and to add that line to .bashrc or .zshrc to make it persist.

## The Ollama IPv6 error and other places the setup breaks

The IPv6 connection refusal is the most concrete failure the README documents, and it is worth understanding why it happens. Node resolves localhost to ::1 first on many systems, while Ollama binds IPv4 only by default. Setting OLLAMA_HOST=0.0.0.0 makes Ollama listen on all interfaces, which resolves it. The same variable is the one you would set if you wanted Ollama reachable from another machine, so the fix and the exposure are the same setting. Exposing Ollama on all interfaces without a firewall is a decision the README does not discuss.

The llama.cpp path has a similar shape but a different URL convention. The README shows starting the server with a GGUF model on port 8080 and then setting the provider and URL.

```bash
./llama-server -m model.gguf --port 8080
oco config set OCO_AI_PROVIDER='llamacpp' OCO_API_URL='http://localhost:8080'
```

Note that the Ollama example includes /api/chat in the URL while the llama.cpp example does not. Copying one form into the other provider will not work, and the README does not spell out the difference.

Token limits are the other quiet failure. OCO_TOKENS_MAX_INPUT defaults to 4096. A large diff will exceed that, and the README does not describe what happens when it does. There is no documented truncation strategy, no warning behaviour, and no guidance on splitting a commit. If you routinely stage hundreds of lines, this is the constraint to test before you trust the tool.

## OpenCommit against Aicommits and commitlint

The related searches around this project include Aicommits, Aicommit2 and Commitlint, and the differences are real rather than cosmetic.

Aicommits is the closest comparison: another CLI that generates a commit message from the staged diff. The distinction OpenCommit draws is provider breadth. Its config lists openai, anthropic, azure, ollama, llamacpp, gemini, flowise, deepseek, aimlapi, openrouter and orcarouter as first-class values of OCO_AI_PROVIDER, and the README states it supports local Ollama and llama.cpp servers, including ones on another machine via OCO_API_URL. If you need the same command to work against a hosted model in CI and a local model on a laptop, that config surface is the reason to pick this one. If you only ever use one provider, the extra configuration is overhead you will not use.

Commitlint is a different category of tool. It validates a message after it exists; it does not write one. OpenCommit's OCO_PROMPT_MODULE accepts @commitlint as a value, which means the prompt is shaped to produce output that commitlint will accept. Running both is coherent: OpenCommit writes the message, commitlint enforces the rule. Running commitlint alone gives you a failing hook and a human who still has to rewrite the message.

A third option is doing nothing and writing the message yourself. That is not a joke answer. For a one-line change, reading the diff and typing a message takes less time than the round trip to a model, and no diff leaves your machine.

## Maintenance status, licence and what an upgrade costs

The repository is not archived, and the last push was on 2026-09-09. The npm package version in package.json is 3.3.10. Those two facts sit alongside a third: the most recent GitHub releases listed are github-action-v1.0.2, github-action-v1.0.1 and github-action-v1, all dated 2023-05-21. The CLI is being pushed to; the GitHub Action side has not had a release in roughly three years. If you came for the Action, that is the number to weigh.

Licence is MIT, stated in package.json and present as a LICENSE file at the repository root. MIT permits commercial use and modification with the copyright notice retained. That is a description of the licence text, not legal advice; if your organisation has a policy on model-generated content in source history, that policy is the thing to check, not the licence.

Upgrade cost is low by design. The published package contains only out/cli.cjs and out/tiktoken_bg.wasm, so a global npm install replaces a single bundled file. The build is esbuild-based (esbuild.config.js) and the release script publishes to the latest tag. Config compatibility is where an upgrade can bite: the README documents OCO_REASONING and OCO_REASONING_MAX_TOKENS as newer additions, and a config file that predates them will simply fall back to defaults. Nothing in the README describes a migration step or a config version, so the safe assumption is that your ~/.opencommit file is read as-is.

## What OpenCommit cannot do for you

The tool generates a message from a diff. It does not know why you made the change. If the reason lives in a ticket, a Slack thread or your head, the model will describe the mechanics of the diff and nothing more. For a bug fix that looks like a one-character change, the generated subject line will be technically accurate and practically useless. That is the case where a human message wins, and no amount of prompt configuration fixes it.

There is also the question of what leaves your machine. With a hosted provider, the staged diff is sent to that provider's API. The .opencommitignore file exists precisely because that is a concern, and it is the only mechanism the README documents for keeping paths out of the request. There is no documented redaction of secrets, no documented local pre-scan, and no documented dry-run mode. If your repository contains credentials in tracked files, that is a problem to solve before you run oco, not after.

The confirmation prompt is the last line of defence. Running oco --yes removes it. That flag is documented as a convenience, and it is also the flag that turns a generated message into a committed one without a human reading it. Teams that want the speed should still consider whether the diff review happens before or after the commit lands.

## Conclusion

Adopt OpenCommit if you already pay for an LLM API or have Ollama running locally and you want commit messages generated from the staged diff without leaving the terminal. Skip it if your team enforces a commit template that the model cannot see, or if committing unreviewed AI text into a regulated history is not acceptable. Before rolling it out, run oco config descri to see the accepted values for OCO_PROMPT_MODULE and OCO_LANGUAGE, and confirm that your provider's model name is one the config actually accepts.

## FAQ

### What does git commit do, and how does OpenCommit relate to it?

OpenCommit does not replace git commit. It generates the message for a staged change using a language model, prints it for confirmation, and then commits; the README notes that running git add is optional because oco stages files itself.

### What does "initial commit" mean in git, and does OpenCommit handle it?

The README does not discuss the first commit in a repository or how OpenCommit behaves when there is no prior history to draw on. It documents the tool only in terms of staged changes and a generated message.

### What does commit() do?

The README does not document a commit() function or any programmatic API. The supported entry points are the opencommit and oco binaries, both pointing at out/cli.cjs, configured through oco config set or a .env file.

### What does "code commit" mean, and is OpenCommit the same thing?

OpenCommit is a commit message generator, not a code hosting or code review service. It takes the staged diff, sends it to the configured provider, and returns a message shaped by OCO_PROMPT_MODULE, which accepts conventional-commit or @commitlint.

### Is there a vscode open commit extension?

The README describes OpenCommit as a CLI tool installed with npm install -g opencommit and run as oco. It does not mention a Visual Studio Code extension or any editor integration.

## Sources

- [di-sukharev/opencommit on GitHub](https://github.com/di-sukharev/opencommit)
- [License: MIT](https://github.com/di-sukharev/opencommit/blob/master/LICENSE)
- [Project website](https://www.npmjs.com/package/opencommit)
- [README](https://github.com/di-sukharev/opencommit/blob/master/README.md)
- [Releases](https://github.com/di-sukharev/opencommit/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/di-sukharev-opencommit