Frequently Asked Questions

Is GitVelocity really free?

Yes. GitVelocity is completely free. You supply your own AI provider API key, which means the expensive part -- AI inference -- runs on your account, not ours. All we operate are lightweight servers to orchestrate the scoring pipeline, so our costs stay minimal. We're Headline, a data-driven venture capital firm with our own engineering team. We built GitVelocity for ourselves and our portfolio companies, loved it, and decided to share it with everyone.

Why do I need to bring my own API key?

GitVelocity uses your provider API key to analyze PR diffs. Anthropic models are the default (Claude Sonnet 5.5, with Opus 5.5, Opus 5, Opus 4.8, Opus 4.7, Opus 4.6, Sonnet 5 and Sonnet 4.6 as pinned options, and Haiku 5.5 as a low-cost option); other lower-cost alternatives are supported on your own OpenAI or OpenRouter key, and Claude Platform on AWS is supported if you would rather route Claude through your own AWS account. The AI model benchmark compares them all on accuracy, stability and cost. Your key is encrypted at rest and only decrypted at runtime when a score is being generated -- we never see it in the clear. Bring-your-own-key is also what keeps GitVelocity free: you cover the AI inference cost directly, so we do not need to charge for the product.

Do you store our source code?

No. We only read the diff of each merged pull request -- the same thing you would see in a PR review. We do not pull your full repository or model a graph of your code. The only things we store are the score, its dimensional breakdown, and a brief rationale. The diff is processed and immediately discarded.

Do you sell our data?

No. We're a regulated venture capital firm. We cannot and do not sell data or operate a side business. GitVelocity exists because our engineering team loves building it and sharing it with other engineering organizations.

Can engineers game the system?

GitVelocity is designed to be gaming-resistant. The AI reads actual code diffs and evaluates substance across six dimensions. It does not rely on superficial metrics like raw lines of code or commit counts. A few specifics on what stops the common tactics:

  • Effective lines, not raw lines. The line count that feeds the Effort Scale Factor excludes vendor code, lockfiles, images and binary assets, generated data files, snapshots, documentation and pure-text files (.md, .txt, .rst, .adoc), pure formatting changes, and whole-file deletions. A Prettier pass, a lockfile bump, or a docs-only edit does not move the needle.
  • Splitting PRs into smaller pieces reduces each individual score via the ESF. Total velocity stays roughly the same.
  • Adding meaningless code or duplicated boilerplate does not lift Base Score dimensions. The AI evaluates substance, not volume.
  • Combining unrelated changes into one PR does not reliably raise the Base Score either, because the AI assesses coherence and architectural impact, not surface-level scope.
  • Quality is capped at 15 points and measures craftsmanship, not test volume. 500 lines of trivial tests score the same as 50 well-targeted ones.
  • ESF is a multiplier, not an additive bonus. A low Base Score times a high ESF is still a low score.
  • 18 anchored reference examples calibrate the AI's interpretation of each dimension, so a large-but-shallow PR cannot drift into high Base Score territory.

The reliable path to higher scores is the same as ever: take on work that genuinely matters and ship it well.

How does test code affect my score?

Test code is handled differently at each stage of the scoring formula.

The base score is calculated from implementation code only. Test files and documentation files are excluded from the base score evaluation. The AI focuses on the engineering in what you built, not how much test code surrounds it.

The Quality dimension (capped at 15 out of 100 points) assesses test quality -- edge case coverage, test types, integration tests -- not test volume. Writing 500 lines of trivial tests scores the same as writing 50 well-targeted ones.

The Effort Scale Factor does include test files in its line count, because writing tests is real engineering effort. But the ESF is a multiplier on your base score, so inflating test volume without substantive implementation work produces marginal gains at best. A low base score multiplied by a higher ESF is still a low score.

Why did my small, complex change score lower than a larger refactor?

This one trips people up early. A tight 40-line bug fix with a clever algorithm lands at a 7, while a 600-line multi-file refactor lands at a 70. On the surface it looks backwards.

Here is what is going on. The final score is Base Score x Effort Scale Factor. The Base Score evaluates the substance of the change across six dimensions. The ESF is a multiplier tied to the scale of the change itself -- effective lines modified, with a file-count adjustment for cross-cutting work.

The 40-line fix may earn a strong Implementation score, but it sits in the Micro tier (11-50 lines, 0.25x). The 600-line refactor sits in the Large or XL tier (0.80x-1.00x), so even a modest Base Score gets multiplied into a much bigger final number. (Note: a pure documentation edit would collapse to the Nano tier, since .md and .txt files are excluded from the effective-lines count -- see below. A mixed refactor that touches real code plus docs is what clears the larger tiers.)

We anchor on effort, not just difficulty. How much engineering a change holds is not only a question of algorithmically hard or high-risk work. It is also about the time and effort the artifact itself represents. Strip AI out of the picture and picture a human producing that same 600-line change by hand -- reading the code, writing the comments, making the edits. That takes real hours, and GitVelocity scores it accordingly. AI compresses the machine time to produce the code, but the artifact and the effort it represents are unchanged.

So difficulty and scale both count, and both are legible in the final number.

How consistent are the scores?

The same PR scored multiple times lands within a 2-4 point range. That consistency comes from three things:

  • 18 anchored reference examples that the AI uses as calibration points across the scoring spectrum
  • Structured rubric evaluation across six defined dimensions with specific scoring criteria
  • Deterministic prompt design that minimizes variance between scoring runs

Tight enough variance to trust the scores for trend analysis and cross-team comparisons.

Do I have to rescore my old PRs when GitVelocity switches to a new AI model?

No. Unless someone in your organization picks a specific model in Settings → AI Scoring, your PRs are scored by GitVelocity's default model, and we move that default to a newer AI model from time to time. When we do, scores already recorded keep the model that produced them, and only new PRs are scored by the new model. The two models are not on one scale, though: when the default moved from Sonnet 4.6 to Sonnet 5.5 on October 2, 2026, the same PRs scored about 12–19% lower on Sonnet 5.5 (see What changes for you). A trend line that crosses the switch date mixes the two.

If you want one scale, there are two ways to get it:

  • Pin the previous model. In Settings → AI Scoring, pick Anthropic - Sonnet 4.6 in the Model Selection card. New PRs are scored by Sonnet 4.6 again, and later changes to the default no longer move you. This costs nothing beyond normal scoring. PRs already scored by Sonnet 5.5 stay that way until you rescore them: run a backfill with Force rescore over the days since the switch, which costs one scoring call per PR in that range.
  • Rescore your history on the new model. In Settings → Historical Backfill, start a backfill over your full history with Force rescore turned on. Every PR in the date range is scored again and its stored score replaced. The cost is one scoring call per PR on the API key your organization scores with, so it grows with the number of PRs: for a history of a few thousand PRs on Sonnet 5.5, expect a few hundred dollars. A history of several thousand PRs can take around an hour, because each PR's diff is fetched from your Git provider again.

Either way, comments GitVelocity has already posted on your pull requests keep the score they were posted with.

What about chained or stacked PRs?

GitVelocity only scores PRs that merge to your default branch (typically main). This has specific implications for stacked or chained PR workflows.

How it works: If you have a chain of PRs where PR A merges into PR B, PR B merges into PR C, and PR C finally merges into main, only that final merge to main gets scored. The intermediate merges (PR A into B, PR B into C) are not scored because they do not target the default branch.

Does that mean the intermediate PRs are lost? Yes, in terms of individual scoring. Only the merge to main is evaluated. The combined score of one large merge will not equal what the individual PRs would have scored if each had merged directly to main separately.

Is that unfair? In practice, it does not meaningfully affect anyone's performance picture when you look at trends over time. Consider the math:

  • Hitting 100 on a single PR is extremely rare. The highest score we have seen internally on a 1--2 week project was 81.
  • Touching many components in a single PR does not automatically push the score toward 100. The AI evaluates coherence and depth, not breadth alone.
  • An engineer who splits work into smaller PRs and merges each one directly to main will tend to accumulate more total points than someone who stacks the same work. Some might call this unfair, but the difference washes out over time.
  • Month-over-month trends naturally smooth out these variations. Top performers and those needing support stand out regardless of which PR strategy they use.

Our recommendation: Run a historical backfill so you have enough data for trends to emerge. Day-to-day scores can be noisy -- a stacked PR workflow might undercount one week, while a burst of small merges might overcount another. Trends over weeks and months tell an accurate story regardless of how engineers structure their PRs.

Does GitVelocity only count shipped code?

Yes. Only merged pull requests are scored. Draft PRs, open PRs, and PRs closed without merging are not included. GitVelocity measures what actually ships to production, not what was attempted.

How does AI-generated code affect scores?

GitVelocity treats AI-generated code identically to human-written code, and that is intentional.

Code is code regardless of who or what wrote it. Engineering today increasingly means how well you can shepherd AI-generated code to production: reviewing it, integrating it, catching the places where it is wrong, and shipping it with confidence. An engineer who uses AI to ship harder work faster is shipping more engineering, and their scores reflect that.

We also do not try to detect whether a human or AI wrote a given line. Some tools do. We think it is the wrong thing to measure. What matters is the artifact that shipped to customers.

What languages does GitVelocity support?

GitVelocity is language-agnostic. The AI reads code structure and architectural patterns regardless of the language. Whether your team writes TypeScript, Python, Go, Rust, Java, or something else, PRs are scored against the same rubric.

Can I use GitVelocity with private repositories?

Yes. GitVelocity works with both public and private repositories on GitHub, Bitbucket, and GitLab. The integration requires read access to pull requests so we can analyze diffs when they merge. Code is analyzed in real time and is not stored after scoring completes.

Can I measure my own work without my company?

Yes. A personal workspace scores your open source contributions, side projects and other work outside your company's repos, with your own API key. Only you can see it, and it is never counted in benchmarks. If you already use GitVelocity at work, choose Create personal workspace from the workspace menu; otherwise choose Just my own work when you sign up.

What are your security standards?

We operate in both the US and Europe and hold ourselves to European regulatory standards -- the higher bar. All data is encrypted at rest and in transit. We follow CIS benchmarks, run regular penetration tests, and are compliant with GDPR and the EU Digital Operational Resilience Act (DORA). For full details, see our Security documentation and Privacy Policy.