GitHub Code Quality is billing now. Decide which repositories justify all three meters.

GitHub Code Quality became generally available on July 20, 2026, for GitHub Team and GitHub Enterprise Cloud. It is a standalone paid product, separate from GitHub Advanced Security, and organizations that enabled it during the public preview began billing automatically at general availability. Their existing scans continue without a migration or reconfiguration, so the immediate task is to review where the product is enabled and disable it at the repository or organization level if future scans and charges are not justified.

That review needs more than the advertised $10 base price. This article explains what Code Quality evaluates, what its active-committer license, AI credits, and scan compute each count, what GitHub's preview and internal-use figures establish, and how to decide whether to keep, narrow, or disable paid enablement without assuming a return that the published evidence does not show.

July 20 turned preview enablement into paid repository scope

According to GitHub's general-availability announcement, accessed July 20, 2026, Code Quality is available on GitHub Team and GitHub Enterprise Cloud and is not available on GitHub Enterprise Server at launch. It complements GitHub Advanced Security but has its own license and usage charges. A GitHub maintainer says in the launch discussion that public repositories incur no active-committer license fee, although AI credits and Actions minutes still apply; the published material does not establish availability on GitHub Free.

Preview repositories keep running as part of the paid product. GitHub says disabling Code Quality for a repository or organization stops future scans and charges, which makes inherited organization-wide enablement a repository-scope decision now. GA also adds organization dashboards and APIs for managing enablement and fetching findings.

Code Quality combines rule-based analysis, AI findings, coverage display, and merge controls

GitHub's Code Quality documentation describes two places where results appear. Pull-request analysis can post findings inline before merge, while default-branch analysis can surface an existing backlog. AI-powered analysis also covers recently changed code.

The product combines two detection paths. Deterministic CodeQL analysis means CodeQL applies defined, repeatable rules for known code patterns and anti-patterns. GitHub currently lists rule-based support for C#, Go, Java, JavaScript, Python, Ruby, and TypeScript. AI-assisted detection means GitHub invokes AI models to look for maintainability and reliability issues outside those fixed rule sets, including in recently changed code written in additional languages; GitHub does not publish evidence here that coverage or accuracy is equivalent across languages.

Copilot Autofix can suggest a change for review before merge. Assigning remediation to the separate Copilot cloud agent requires a Copilot license, although Code Quality's AI-assisted detections and autofixes do not. Automated findings still leave the merge decision with the team, a boundary covered in our article on AI code review bots and human merge ownership.

Code Quality can render coverage metrics on pull requests from customer-supplied Cobertura XML reports. It does not create tests or establish their quality. Rulesets can block pull requests that fail configured quality or coverage thresholds, but the gates only enforce the chosen criteria and supplied evidence.

GitHub includes evaluate mode, which reports how a proposed ruleset gate would behave without blocking merges. Teams can test a threshold against normal repository activity before enforcing it.

Every enabled repository can touch three separate cost meters

GitHub's billing documentation, accessed July 20, 2026, identifies three units. Finance, platform, and engineering teams should keep them separate because each responds to a different usage pattern.

Scroll sideways to see all 3 columns.

Cost surface	What GitHub counts	What to establish before keeping enablement
Active-committer license	$10 USD per unique active committer per month; a GitHub maintainer says public repositories incur no license fee	Which Team or Enterprise license holders enter the 90-day window through repositories that incur the license fee
AI credits	Token-priced model interactions for AI-assisted detection and Copilot Autofix; GitHub currently defines one AI credit as $0.01 USD	Actual shared-pool consumption, since GitHub publishes no universal credit amount per finding, scan, or fix
Scan compute	GitHub Actions minutes used for deterministic CodeQL scans, unless the organization uses self-hosted runners	Hosted-runner minutes or the infrastructure and operating cost of self-hosted execution

An active committer is a person with a GitHub Team or GitHub Enterprise license in the organization or enterprise whose commit was pushed to at least one enabled repository within the previous 90 days. The push date controls the test regardless of when the commit was authored. GitHub counts a person once across the organization or enterprise, and GitHub App bots are ignored.

Enabling another repository may add no base licenses if its recent committers are already counted elsewhere. It may instead add members, enterprise-managed users, external collaborators, or people with pending invitations when the other conditions apply. Visible team size alone does not determine the repository's base exposure.

An AI credit is GitHub's usage unit for AI-model interactions. Code Quality draws from a shared pool, prices interactions by tokens, and currently values one credit at $0.01. GitHub publishes no universal credit amount per detection, scan, finding, or autofix, and Code Quality does not support model switching.

Deterministic CodeQL scans use GitHub Actions. GitHub-hosted runs consume Actions minutes; self-hosted runners avoid that GitHub charge but leave the organization paying for infrastructure and operations.

A Copilot subscription is not required for AI-assisted detection or Copilot Autofix. AI credits still remain separate from any applicable $10 active-committer license, as does scan compute.

GitHub's adoption and resolution figures establish use, not ROI

GitHub reports that more than 10,000 enterprises used Code Quality during the public preview. In the GitHub Community launch post, a maintainer gives a separate denominator: more than 200,000 repositories ran it. These vendor-reported figures show preview reach, not paid conversion, post-GA retention, cost, or outcomes.

GitHub also says its own engineering teams resolve 67.3% of Code Quality findings before merging pull requests. Its announcement provides no sample size, period, repository or finding mix, baseline, comparison group, or definition of “resolved.” The figure shows action on a share of findings; it does not establish accuracy, fewer defects or incidents, productivity, time saved, or return on spend. Our discussion of GitHub Copilot cohorts and AI adoption measurement explains the same boundary between tool activity and business outcomes.

Scores and finding counts only become useful in repository context

GitHub's guidance on interpreting Code Quality results says scores need repository context. A small repository, or one with little code in CodeQL-supported languages, may show few findings and a good score because little code was analyzed.

Generated code can create many maintainability findings even when the authored source is manageable. Large repositories can accumulate many findings while most code meets the team's standards. Comparisons across unlike repositories need codebase size, supported-language coverage, and generated-file treatment.

A Cobertura percentage can show whether the supplied report met a threshold, but not whether important behavior was tested. Before blocking merges, confirm that the report includes the intended code and the threshold fits the repository's testing strategy.

Decide paid enablement from one bounded cycle of repository evidence

Inventory every enabled repository, including archived, low-change, experimental, and mirrored projects. Record the owner, lifecycle state, primary languages, generated-code footprint, scan activity, and whether it supplies Cobertura XML.

Estimate active-committer exposure with the 90-day push rule and unique people across the organization or enterprise. Keep that base estimate separate from observed AI-credit use and Actions minutes. For self-hosted scans, record internal compute and operations instead of labeling them free.

Inspect whether teams review, resolve, dismiss, or ignore the findings; whether AI-credit use and scan frequency fit repository activity; whether CodeQL supports the main languages; and whether generated code distorts the backlog. Verify the source and scope of the Cobertura report instead of treating its percentage as a test-quality score.

Put candidate quality and coverage thresholds into evaluate mode. Observe which pull requests would be blocked, which findings developers consider relevant, and where coverage inputs mislead. Enforce a gate only when the repository owner can explain its threshold and exceptions.

At that point, make one of three ordinary scope decisions:

1. Keep enablement where the repository produces useful findings or coverage signals, the team understands the active-committer exposure, and the three measured costs are acceptable for the evidence used.
2. Narrow enablement to repository groups where the signals inform review, while removing repositories that add contributors, scans, or noisy results without supporting a current decision.
3. Disable enablement where no owner uses the output, the analyzed code is a poor fit, or the organization cannot yet justify the license, AI-credit, and compute exposure. For preview users, GitHub says disabling at the repository or organization level stops future scans and charges.

After one complete billing cycle, compare estimates with actual unique active committers, AI-credit consumption, scan compute, findings acted on, and evaluate-mode results. The record will not prove defect reduction or ROI, but it gives engineering and finance evidence for the next scope decision.

Sources

• GitHub: GitHub Code Quality is now generally available
• GitHub Docs: About GitHub Code Quality
• GitHub Docs: GitHub Code Quality billing
• GitHub Docs: Interpreting Code Quality results
• GitHub Community: GitHub Code Quality is now generally available