GitHub Code Quality GA: What $10/Committer Blocks

GitHub announced on June 16 that Code Quality becomes generally available on July 20, 2026. It stops being free. The base price is $10 per active committer per month on any repository where Code Quality is enabled, plus usage-based charges for AI features and Actions minutes for CodeQL scans.

More than 10,000 enterprises used the public preview. Many of them now face a purchase decision before July 20, or they need to disable it to avoid charges. This article breaks down what Code Quality actually gates, what it doesn't review, and why the distinction matters for teams evaluating the spend.

What you're paying for

The billing has three components, and they stack.

$10 per active committer per month is the base license. An "active committer" is anyone who pushed a commit to an enabled repository in the last 90 days, regardless of when the commit was authored. This covers access to findings, scoring, rulesets integration, quality gates that block PRs, organization-wide deployment, and the quality dashboards.

AI-powered features are billed on consumption via GitHub AI Credits (1 credit = $0.01 USD). This applies to Copilot code review on PRs, AI-assisted detection, and Copilot Autofix generation. You don't need a separate Copilot license to use these features within Code Quality, but every AI interaction costs tokens.

GitHub Actions minutes power the deterministic CodeQL scans. These are the rule-based maintainability and reliability checks that run on every PR and on the default branch. If you're on self-hosted runners, you absorb the compute cost instead of paying GitHub's per-minute rate.

For a 50-person team where every developer commits, the base license alone is $500/month before AI usage or Actions compute. That's real money, and it raises a fair question: what exactly does this quality gate enforce?

What the quality gate blocks

Code Quality's enforcement mechanism works through GitHub's rulesets. You set thresholds on three dimensions, and PRs that violate them can't merge:

• Maintainability — CodeQL flags code smells like complex methods, long parameter lists, duplicated logic, and naming issues. These are structural indicators.
• Reliability — Detects patterns likely to cause bugs: null dereferences, resource leaks, unreachable code. Pattern-matched, not verified at runtime.
• Code coverage — Upload coverage reports, set a threshold, and block PRs that drop below it. The bot posts a summary comparing the PR branch to the default branch.

On top of the deterministic CodeQL rules, Code Quality also runs AI-powered analysis on files pushed to the default branch, covering languages beyond the seven CodeQL supports (C#, Go, Java, JavaScript, Python, Ruby, TypeScript). Findings from that AI layer appear on a separate dashboard tab.

The new GA release also adds organization-level quality dashboards and org-wide deployment, so engineering leaders can track maintainability and reliability scores across all repositories from one view. That's genuinely useful for visibility.

None of this is new technology. SonarQube, Codacy, and CodeClimate have offered maintainability scoring and quality gates for years. GitHub's advantage is integration: the gate lives inside the same platform where PRs already merge, and rulesets enforce it without external webhook plumbing.

What it doesn't catch

Here's the gap. Code Quality's gate evaluates structural signals. It doesn't read the diff and reason about what the code change actually does.

A PR can pass every Code Quality threshold and still contain:

• Logic errors that don't trigger any CodeQL pattern. An off-by-one in a pagination boundary, a misapplied business rule, or a condition that silently drops records. Perfectly maintainable code can be wrong.
• Concurrency bugs like race conditions, deadlocks, or unsafe shared state access. These require understanding execution flow, not just structure.
• Dependency risks that aren't in the advisory database yet. A new dependency introduced in a PR might have no known CVEs but could ship with overly broad permissions, telemetry, or a license incompatibility.
• Architectural regressions where a change bypasses the intended abstraction layer, leaks internals across module boundaries, or introduces a coupling that will compound over time. The maintainability score might stay green.

Coverage thresholds make this even trickier. A PR can maintain 80% coverage while the new code itself has no meaningful assertions. The threshold checks quantity of lines exercised, not quality of test logic.

The availability gap: GHES teams are left out

There's a hard constraint in the announcement that's easy to miss. GitHub Code Quality is only available on GitHub Enterprise Cloud and GitHub Team plans. It's not available on GitHub Enterprise Server.

That's a significant gap. Enterprises running GHES (often for compliance, data residency, or air-gapped environments) have no path to these quality gates. They can run CodeQL on their own, but without the integrated scoring, rulesets enforcement, or dashboards that Code Quality bundles.

For GHES teams evaluating how to enforce code quality at the PR level, the tooling decision has to come from outside GitHub's product surface.

Where semantic review fits in

The quality gate and the code review are different jobs. Code Quality answers: does this code meet structural standards? A reviewer (human or automated) answers: is this change correct, safe, and well-designed?

GitHub's own Copilot code review layer (which is part of Code Quality's AI usage) does attempt semantic analysis. But its scope is limited: it runs on PR diffs, comments inline, and suggests fixes. It doesn't operate as a standalone gating mechanism. And its accuracy on real-world bugs still varies, with GitHub noting that model switching isn't supported because it "is likely to compromise the reliability and accuracy of analysis results."

This is where a dedicated code review tool adds value alongside Code Quality rather than instead of it. Tenki's Code Reviewer reviews the actual diff at the CI boundary, analyzing what the code change does rather than measuring its structural profile. In benchmarks against 122 known bugs, Tenki caught 68.9% of them (84/122), compared to 24.6% for Copilot (30/122). The review runs as a GitHub Action, so it works on any Actions-compatible setup, including GHES instances where Code Quality isn't available.

The pricing model is also different. Tenki charges $1.00 per review, not per committer per month. For teams that merge fewer PRs than they have committers (which is most teams), that's a lower total cost.

The decision before July 20

If your org used Code Quality during the preview, you'll start getting billed on July 20 unless you disable it first. GitHub's docs are clear on this: go to your organization settings and turn it off on each repository, or disable it org-wide.

But whether you keep it or not, it's worth understanding what the $10/committer buys and what it leaves uncovered. The quality gate is a structural filter. It catches code smells and enforces coverage floors. Those are worth having. They're just not the same thing as knowing whether the code is correct.

The question isn't whether to use Code Quality. It's whether to treat it as your only gate.