# CommitBrief FAQ > Common questions about installing, configuring, and running CommitBrief. 17 questions across 3 categories Canonical URL: https://commitbrief.com/faq/ --- ## Privacy ### Is my code sent to the LLM provider? What exactly leaves my machine? Only what the review needs: the diff text, plus your `COMMITBRIEF.md` and `OUTPUT.md` content (they become the system prompt) — sent directly over HTTPS to the provider **you** configured. There is no CommitBrief server in between. A [pre-send secret scanner](/docs/1.x/safety-and-cost#secret-scanner) blocks credential-shaped strings before that call goes out, and picking Ollama or a `-cli` provider (`claude-cli`, `gemini-cli`, `codex-cli`) keeps everything on your machine — zero third-party egress. Run `commitbrief --staged --show-prompt` to see the exact payload before anything is sent — no provider call, no cost. ### Can I run it fully offline? Yes — pick Ollama as the provider. The CLI then talks only to `http://localhost:11434` (or whatever you've configured); no API key is required and no diff leaves your machine. CommitBrief itself never makes outbound network calls beyond the provider you chose. There is no telemetry endpoint, no auto-update check, no analytics beacon. ### Does CommitBrief write to my repo or change my code? No — every review path is read-only: CommitBrief never edits a file and never stages a change on your behalf. The one exception is [`commitbrief commit`](/docs/1.x/commit), which runs a single `git commit` on what you already staged, and only after you confirm (or pass `--yes`). It never auto-stages and never touches file contents. ### Can I add my own secret patterns? Yes. The secret scanner ships eight built-in patterns for common token formats, and `guard.secret_patterns` lets you layer your own regexes on top — handy for internal or company-specific credentials: ```yaml guard: secret_patterns: - name: Acme Internal Token pattern: 'acme_[A-Za-z0-9]{32}' ``` Your patterns are additive: the built-ins always run and can't be disabled or shadowed (use `guard.secret_scan: false` to turn the scanner off entirely). An invalid regex aborts the review before any provider call, naming the offending entry, so a typo can't silently disable a check. Only the line number and pattern name are ever reported — never the matched text. This key is config-file only; hand-edit `config.yml` (or your `init`/`setup` output) rather than `commitbrief config set`. See [Safety and cost](/docs/1.x/safety-and-cost#adding-your-own-patterns-v170). ### Can a teammate hide a bug in the baseline? No. The baseline (`.commitbrief/baseline.json`) is **per-developer and gitignored** — `.commitbrief/` is auto-added to `.gitignore` on first write, so the file is never committed and never propagates. That means CI has no baseline file and reviews the full diff, and the next reviewer's checkout has no baseline (or their own) either. There's no shared baseline to bake a bug into, so a baseline can only quiet repeat noise *for you* — it can't lower the bar for anyone else. Inline `// commitbrief-ignore: reason` suppressions *do* live in the code, but they carry a mandatory reason that lands in the diff the reviewer reads, so they're never a silent override either. See [Signal control](/docs/1.x/signal-control). ## General ### What is CommitBrief? CommitBrief is a Go CLI that runs LLM-powered code reviews on git diffs — staged, unstaged, or any historic range `git diff` understands via the `commitbrief diff ` subcommand (single commit, branch vs target, PR-style three-dot range, etc.). It runs locally; the only network egress is to the provider you chose. It is **not** a SaaS, a dashboard, a GitHub App, or a bot. There is no account, no server-side state, and no telemetry. ### Do I need an API key? Only for six of the ten providers — Anthropic, OpenAI, Gemini, DeepSeek, Mistral, Cohere. `commitbrief setup` walks you through adding one. Ollama needs no key at all (it's your own local model), and the three CLI-tool-backed providers — `claude-cli`, `gemini-cli`, `codex-cli` — reuse the auth of a Claude Code, Gemini CLI, or Codex CLI subscription you're already logged into. See [Providers](/docs/1.x/providers). ### Which provider should I pick? Ten providers ship as of v1.4.0 — seven HTTPS API backends plus three subprocess wrappers around host CLI tools. Use whichever fits your billing and trust model. **API providers** (need an API key, billed per-token): - **Anthropic** (default): best output quality on code review tasks in our experience; ephemeral prompt caching makes repeat runs cheap. - **OpenAI**: comparable quality; automatic prompt caching at ≥1024-token prefixes. - **Gemini**: largest free-tier context windows (2 M with 2.5 Pro). Good when your `COMMITBRIEF.md` is unusually large. - **DeepSeek / Mistral / Cohere**: OpenAI-compatible endpoints driven through the same SDK — no extra dependency. Low-cost (DeepSeek), EU-hosted and code-tuned (Mistral `codestral`), or the Cohere `command` family. Structured output is prompt-driven with graceful degrade. - **Ollama**: zero cost, zero network egress, runs on your own GPU. Best for SOC2-restricted repos or air-gapped environments. **CLI-tool-backed providers** (no API key, reuse existing subscription): - **`claude-cli`**: drives your locally-installed Claude Code (`claude`) binary as a subprocess. Auth + billing handled by your Claude Code subscription. Output is pre-formatted plain text — no `--json` or `--fail-on` severity gating. - **`gemini-cli`**: same idea against Google's Gemini CLI (`gemini`). - **`codex-cli`**: same idea against OpenAI's Codex CLI (`codex`), run non-interactively under its read-only sandbox. Added in v1.3.0. Run `commitbrief setup` to configure any of the seven API providers interactively, or invoke a CLI-backed one directly with `commitbrief --cli claude` / `--cli gemini` / `--cli codex`. ### Does CommitBrief work with GitHub Actions or other CI? Yes. Run the binary directly in any runner that has `git` and your provider's API key — `commitbrief --staged --fail-on=critical` exits non-zero on a matching finding, so it works as a plain shell step in any CI system, GitHub or not (the docs include a GitLab CI recipe that saves the JSON report as an artifact). For GitHub specifically, the [official GitHub Action](/docs/1.x/severity#the-official-github-action) (`CommitBrief/commitbrief-action@v1`) wraps two modes: `comment` posts inline PR review comments and a verdict via `remote pr`, and `gate` fails the job on a severity threshold with no comments. ### Which languages or file types does it review? Any language a `git diff` can produce. CommitBrief has no per-language parser for the review itself — it hands your diff text to the LLM you configured, the same way a human reviewer reads a patch. The one Go-specific piece is the optional [flaky-test sandbox-rerun](/docs/1.x/flaky-tests): its test-name resolution parses Go's AST, so that one confirmation step is Go-only. The static flaky-pattern checks that run by default work on any language's test files. ### How do I silence flaky-test warnings? The flaky-test detector is a deterministic pre-pass that flags timing-dependent and unseeded-random anti-patterns in your changed test files. It's on by default for API providers. To turn it off: ```sh commitbrief --staged --no-flaky # per-run commitbrief config set review.flaky false # persistently ``` Disable it if a CI layer already handles flake detection, or if your test code legitimately uses these patterns. Note that flaky findings are first-class — they render alongside the model's findings and count toward `--fail-on`, so silencing them also drops them from CI gating. See [Flaky-test detector](/docs/1.x/flaky-tests). ### Does CommitBrief run on Windows? Yes. Pre-built Windows binaries (amd64/arm64) ship on every release — install via [Scoop](https://scoop.sh) (`scoop install commitbrief`) or as a raw archive from GitHub Releases. Path filters are normalized cross-platform, so a Windows-style `--dir app\Models\*` matches the same files a Unix glob would, and `commitbrief setup --alias` can install a shortcut into PowerShell or cmd.exe. See [Installation](/docs/1.x/installation). ### Can I narrow a review to specific files or directories? Yes. `--file`/`-f` and `--dir`/`-d` accept exact paths or gitignore-style globs (`--file '*.go'`, `--dir 'app/**'`), and `--exclude-file`/`--exclude-dir` remove matches from that set afterward — useful in a monorepo where you only want the touched package reviewed. Both stack with any scope (`--staged`, `--unstaged`, `diff `) and apply after the built-in and `.commitbriefignore` filters. See [Review scopes](/docs/1.x/review-scopes). ### How do I stop seeing findings I've already triaged? Two ways, both true removals (a dropped finding no longer counts toward `--fail-on` or appears in `--json`): - **Baseline** a whole repo's existing findings so only new ones surface from then on: ```sh commitbrief --update-baseline # record current findings ``` The baseline lives in a user-private, gitignored `.commitbrief/baseline.json`. Findings are fingerprinted by file + severity + title (not line), so they survive code drift. - **Suppress** one specific finding inline, with a reason the next reviewer can read: ```js const id = rows[0].id; // commitbrief-ignore: list is non-empty here ``` Use `commitbrief-ignore[high]: …` to scope the drop to one severity. This is stronger than `--min-severity`, which only hides findings from the view — they still count toward CI gating. See [Signal control](/docs/1.x/signal-control). ### How is this different from my editor's AI assistant? An editor assistant reviews what's near the cursor, inside one IDE, against whatever model that tool ships with. CommitBrief reviews the whole diff — staged changes, a commit range, or a PR — against rules you declare once in `COMMITBRIEF.md`, with a provider you pick per repo, so the same review runs identically from your terminal, a git hook, or CI. Neither replaces a human reviewer's intent-level judgment — "does this function solve the right problem" stays a person's call. CommitBrief is a pre-check before that person (or your future self) looks at the change. ## Cost ### Is CommitBrief free? What license does it use? Yes. The CLI is free and open source under [GPL-3.0-or-later](https://github.com/CommitBrief/commitbrief/blob/main/LICENSE), hosted at [github.com/CommitBrief/commitbrief](https://github.com/CommitBrief/commitbrief). There's no subscription, no seat license, and no paid tier. The only cost is whatever your chosen LLM provider charges per token — and that's $0 with Ollama (your own local model) or a CLI-tool-backed provider that reuses a subscription you already have. ### How much does a review cost? It depends on your provider's per-token pricing and the size of the diff plus your `COMMITBRIEF.md`. Run any command with `--verbose` to see the actual token counts and cost for that run. Two CommitBrief features keep cost low: 1. **Local response cache.** Re-running on an identical diff (same provider, model, language, schema) is a disk read — zero token spend. The verbose footer prints `Saved: $X` for cache hits. 2. **Provider prompt caching.** Anthropic, OpenAI, and Gemini all discount repeated input prefixes. CommitBrief structures the prompt to maximize cache hit rate; the verbose footer reports `provider cached: N` tokens. `commitbrief compress` can additionally shrink your `COMMITBRIEF.md` itself (see `--level light|balanced|aggressive`).