GitHub Code Quality will move from public preview to a paid generally available product on July 20, 2026, turning a free code-health preview into a billing decision for organizations that have enabled it across repositories.
The change affects GitHub Team and GitHub Enterprise Cloud customers using Code Quality to find maintainability and reliability issues, enforce pull request gates, track code coverage, and route fixes through Copilot-powered workflows. GitHub said more than 10,000 enterprises used the public preview, which helps explain why the deadline matters: many organizations may already have the feature running in places where developers now treat it as part of the review process.
Starting July 20, the bill has three pieces. GitHub will charge $10 per active committer per month for repositories where Code Quality is enabled. AI-powered capabilities such as Copilot code review, AI-assisted detection, and Copilot Autofix will consume usage-based GitHub AI Credits. CodeQL-based deterministic analysis will continue to consume GitHub Actions minutes, or runner capacity for teams using self-hosted runners.
The cost is not just one line item
The easiest mistake is to treat Code Quality as a simple per-seat product. GitHub’s June 16 changelog describes a base subscription plus metered usage. The per-committer license covers access to findings, repository and organization quality scoring, rulesets integration, security and quality overview integration, organization-wide deployment, and quality gates that can block merges on maintainability, reliability, or coverage thresholds.
The variable costs sit elsewhere. GitHub’s billing documentation says AI features consume GitHub AI Credits based on token usage, with 1 AI credit equal to $0.01. It also notes that Code Quality uses a purpose-built mix of models and does not support model switching, which means teams cannot simply choose a cheaper model for the feature if consumption rises. Separately, CodeQL scans run as GitHub Actions workflows, so private-repository usage during preview has already been able to consume Actions minutes even before active-committer and AI-credit billing begins.
That combination matters for platform teams because the July 20 switch can turn one enabled repository into several different cost surfaces: the people who recently committed to it, the number and size of pull requests being analyzed, the use of AI review or Autofix, and the amount of deterministic analysis running through Actions.
Who counts as an active committer
The active-committer rule is especially important for organizations with many repositories, contractors, or occasional contributors. GitHub’s Code Quality billing page says a committer is active if one of their commits has been pushed to a repository with Code Quality enabled within the last 90 days, regardless of when the commit was originally authored. GitHub App bots are ignored, but members, enterprise-managed users, external collaborators, and pending invitees can count if they meet the contribution rule.
GitHub measures usage across the organization or enterprise so one user is not charged repeatedly for contributing to multiple enabled repositories. Even so, the selection of repositories matters. A broadly enabled monorepo, active internal platform repository, or shared SDK with many occasional contributors can pull more users into license usage than a team might expect from looking only at full-time engineers assigned to a project.
What Code Quality actually checks
Code Quality is not a single scanner. The rule-based side uses CodeQL to analyze C#, Go, Java, JavaScript, Python, Ruby, and TypeScript for maintainability and reliability findings. GitHub’s product documentation says AI-powered analysis appears separately in an “AI findings” dashboard and examines recently pushed files on the default branch, potentially including languages beyond the CodeQL list.
On pull requests, findings can appear as comments from the github-code-quality[bot]. Where possible, those comments can include Copilot Autofix suggestions. If coverage reporting is configured, the same bot can post a coverage summary comparing the pull request branch with the default branch. For default branches, standard CodeQL findings and AI findings are separated on repository code-quality pages.
This split gives engineering leaders a practical way to decide what they value. Some teams may want deterministic CodeQL maintainability checks and coverage gates but prefer to limit AI-powered review until they understand the credit impact. Others may decide that AI review and Autofix are precisely the reason to keep Code Quality enabled on high-churn repositories, while disabling it on low-value projects that do not need merge-blocking quality gates.
The audit to run before July 20
GitHub now lets organizations enable or disable Code Quality across all repositories from organization settings, according to the enablement guide. That organization-level toggle is useful, but it is blunt. Before using it, teams should map where Code Quality is already enabled, which repositories have enough activity to justify paid checks, and which repos were switched on mainly because the preview was free.
- Inventory enabled repositories. Separate production services, shared libraries, compliance-sensitive systems, and high-traffic monorepos from archived, experimental, or low-risk repositories.
- Estimate active committers. Look at the last 90 days of pushed commits for enabled repositories, including external collaborators and pending invitees that may count toward license usage.
- Review Actions consumption. During preview, detailed usage reports can show consumption by the dynamic CodeQL workflow used for Code Quality scans. That is the best early signal for deterministic-analysis cost.
- Watch AI-powered usage. Teams using Copilot code review, AI-assisted detection, or Autofix should decide where those features are worth variable AI-credit spend, especially on large pull requests or repositories with frequent generated-code changes.
- Check merge-blocking rules. Quality gates that block pull requests can be valuable, but they should be tuned before billing starts so teams are not paying for noisy enforcement that developers learn to bypass.
Organizations that do not want charges need to disable Code Quality before July 20. Teams that want to keep it should make the decision deliberately: enable it where reliability, coverage, and maintainability checks reduce real review burden, and turn it off where the signal is weak.
Why the timing matters
The Code Quality deadline arrives weeks after GitHub moved Copilot into usage-based billing. Together, the changes show how AI-assisted development tools are settling into the economics of enterprise software: code generation, code review, automated fixing, static analysis, and governance are becoming metered platform capabilities rather than flat add-ons hidden inside a developer subscription.
That is not automatically bad for engineering teams. A paid quality gate can be cheaper than letting defects, flaky tests, low coverage, or unreviewed AI-generated code accumulate across a large codebase. But the value depends on where the controls run and whether developers trust the findings. A scanner that blocks merges for the right issues can improve throughput. A scanner that comments too often, charges unpredictably, or runs on repositories nobody maintains becomes another operational tax.
The next three weeks are the useful window. By July 20, organizations should know which repositories need Code Quality, which teams own the budget, how AI-powered review will be governed, and what should happen when coverage or maintainability gates fail. The worst outcome is not paying for Code Quality. It is discovering after the deadline that a free preview quietly became an unplanned production dependency.
