GitHub Code Quality GA: Setup, Pricing and Rollout

GitHub Code Quality is a standalone paid product, not a GitHub Advanced Security bundle or a feature that requires a GitHub Copilot subscription. It was not available on GitHub Enterprise Server at launch. This guide turns the GA announcement into an implementation plan: establish cost boundaries, enable a pilot, upload coverage, observe rulesets in evaluate mode, measure noise, and keep a tested rollback.

The research cutoff is July 22, 2026. Product facts come from GitHub's announcement and live documentation. No licensed Code Quality organization or metered scan was available for hands-on testing, so the workflow and API examples below were reviewed against official documentation rather than executed.

What GitHub shipped at general availability

The GA release joins four jobs that teams often operate separately: finding quality problems on a pull request, suggesting a repair, measuring test coverage, and deciding whether a pull request meets the merge policy.

GitHub reports that more than 10,000 enterprises used the public preview and that its own engineering teams resolved 67.3% of findings before merging. Both numbers are vendor-reported. GitHub has not supplied an independent reproduction or enough detail to treat either figure as a performance guarantee for another organization.

How CodeQL and AI-assisted detection fit together

Code Quality is not one opaque model call. Its documented analysis path has distinct layers:

1. CodeQL performs deterministic analysis. GitHub maintains queries for known reliability and maintainability anti-patterns. On pull requests, the CodeQL - Code Quality check reports rule-based findings and their severity.
2. AI-assisted analysis broadens detection. GitHub's separate AI scan analyzes recently pushed files on the default branch and may identify issues in languages beyond CodeQL's supported quality-query set. It is not an AI ruleset signal on pull requests.
3. Copilot Autofix proposes a patch. A developer reviews the suggestion in context, applies or edits it, and relies on ordinary tests and review before merge.

That separation matters for governance. A CodeQL rule has a named rule, severity, location, and repeatable detection path. An AI-assisted finding can be useful where no rule exists, but it requires closer review for relevance. GitHub's current threshold documentation says AI detections cannot be used as the Require code quality results ruleset threshold. Deterministic findings and uploaded coverage remain the enforceable signals.

Do not conflate three products that can appear in the same interface:

The responsible workflow is still familiar: inspect the finding, understand the proposed change, run the relevant tests, and require the usual reviewer approval. Autofix shortens repair work; it does not prove that a change is correct.

Pricing: model the three cost lines

As of July 22, 2026, GitHub's Code Quality billing documentation defines three cost parts.

GitHub defines an active committer precisely: a person is active when one of their commits has been pushed to at least one Code Quality-enabled repository in the last 90 days, regardless of when the commit was authored. The person must have a Team or Enterprise license relationship with the organization or enterprise; the definition includes members, enterprise-managed users, external collaborators, and people with a pending invitation. Each person consumes one Code Quality license across the relevant billing organization or enterprise even if they contribute to several enabled repositories. GitHub App bot accounts are ignored.

Illustrative monthly cost model

Suppose a pilot covers 120 active committers. The predictable base is:

120 active committers × $10 = $1,200 per month

illustrative total = $1,200
                   + metered Code Quality AI usage
                   + billed GitHub-hosted Actions compute

This is an illustration, not a quote. The sources do not provide a universal AI charge or scan duration, so inserting invented averages would make the estimate look more precise than it is. Export the billing usage report for repository-level allocation, group the AI usage view by product, and record hosted-runner minutes during the pilot. Self-hosted scans still incur infrastructure and operational costs.

GitHub says there is no pre-enable estimate for the complete spend because it depends on committers, scan frequency, and findings. Billing began automatically at GA on July 20, 2026 for repositories that remained enabled from public preview.

Enable a repository or organization pilot

Before enabling anything, confirm the account is on GitHub Team or GitHub Enterprise Cloud. For an enterprise, an enterprise owner must first allow Code Quality. GitHub Actions must also be enabled because deterministic CodeQL analysis runs as Actions workflows. GitHub documents these prerequisites and the controls below in its enablement guide.

For one repository:

1. Open Repository → Settings → Security → Code quality.
2. Select Enable code quality.
3. Choose the languages for deterministic CodeQL analysis.
4. Choose the standard runner or a labeled runner and supply its label.
5. Review the billing impact, save, and confirm that CodeQL - Code Quality completes on a pull request.

For an organization:

1. Open Organization → Settings → Security → Code quality.
2. Set Repository access to Selected repositories for a fixed pilot or Matching a filter for a pilot driven by visibility, fork status, or a custom property.
3. Leave Enforce access off while teams calibrate, unless central policy must prevent repository administrators from opting out.
4. Review the dialog showing repositories that will be enabled and disabled plus the billing effect, then confirm.

The repository-access setting is bidirectional. Moving to a filter enables matching repositories and disables nonmatching repositories. A review dialog exists because one organization change can alter both groups. For a pilot, a custom property such as code-quality-enabled: true creates a visible expansion mechanism without maintaining a long list by hand.

Expected evidence after setup is a successful Code Quality Actions run, pull-request annotations when a test change triggers a known rule, and repository or organization dashboard data after analysis completes. Do not add a merge gate until that check reports consistently.

Add Cobertura coverage to pull requests

Coverage is opt-in per repository; enabling Code Quality does not create or upload a report. GitHub's coverage setup guide accepts Cobertura XML from any language or framework that can generate it. The official upload action needs code-quality: write permission.

This workflow is adapted from GitHub's setup documentation. Replace the test command, branch, language, and file path for the repository. It has not been executed for this article.

name: Code Coverage

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

permissions:
  contents: read
  code-quality: write

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          ref: ${{ github.event.pull_request.head.sha || github.sha }}

      - uses: actions/setup-python@v5
        with:
          python-version: "3.x"

      - run: |
          python -m pip install -r requirements.txt
          python -m pip install pytest pytest-cov
          pytest --cov=. --cov-report=xml

      - name: Upload coverage report
        if: github.event_name != 'pull_request' || github.event.pull_request.head.repo.full_name == github.repository
        uses: actions/upload-code-coverage@v1
        with:
          file: coverage.xml
          language: Python
          label: code-coverage/pytest

Two details prevent misleading deltas. First, push to the default branch establishes the baseline and pull-request runs establish the comparison. Second, checking out the pull-request head commit keeps coverage line numbers aligned with the diff instead of the synthetic merge commit. The fork condition also avoids attempting a privileged upload from an untrusted fork context.

GitHub stores the latest upload for each branch. It reports covered lines divided by total lines and shows the pull-request branch against the default branch, including per-file changes. A move from 44% to 65% is a gain of 21 percentage points, not a 21% relative increase.

Configure quality and coverage rulesets safely

GitHub documents separate branch rules for quality severity thresholds and coverage thresholds:

Before adding Require code quality results, open a recent pull request and verify the CodeQL - Code Quality check completes successfully. GitHub warns that a ruleset can block every pull request if the required analysis is not reporting.

Create the branch ruleset at repository level for a special case or organization level for a shared standard. Target the default branch, enable the relevant rule, and start with the weakest threshold that protects the pilot's current bar. AI detections cannot be selected as the quality threshold.

Set the ruleset to Evaluate first. Evaluate mode records which pull requests would have been blocked without preventing merges. GitHub's rollout guide suggests collecting roughly one or two weeks of activity, inspecting ruleset insights, and adjusting the severity or coverage thresholds before switching to Active.

Triage findings without training teams to ignore them

Every finding should end in one of three states: fixed, dismissed with a reason, or escalated to the rule or product owner. “Ignore the bot” is not a sustainable fourth state.

GitHub's pull-request findings guide supports applying a suggestion or dismissing an irrelevant finding. A review policy should make that choice auditable:

1. Read the rule, severity, affected location, and explanation before opening the suggested patch.
2. Decide whether the issue is present in changed code and whether the proposed repair preserves behavior.
3. Apply or edit Autofix only after checking the complete diff; run focused tests plus the repository's required suite.
4. If the finding is irrelevant or unactionable, use Dismiss finding for the Code Quality bot comment. GitHub also documents Resolve for a Copilot review comment.
5. Record a reason such as false positive, accepted legacy exception, or non-actionable generated code. Repeated dismissals for one rule should trigger a rule-policy review rather than repeated local work.

A practical pilot sample separates deterministic and AI-assisted findings and records these fields:

Repository scores need context. GitHub's default-branch scores are based on the most severe deterministic finding: no findings is Excellent, at least one note is Good, at least one warning is Fair, and at least one error is Poor. Generated code, repository size, and supported-language coverage can distort comparisons. Use the scores to locate work inside a repository, not to rank teams without normalization.

Use the findings and setup APIs

GitHub's Code Quality REST reference has four documented operations:

Use the findings endpoint to build a pilot report without scraping the dashboard:

gh api \
  -H "Accept: application/vnd.github+json" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "/repos/OWNER/REPO/code-quality/findings?state=open&per_page=100"

The setup endpoint supports configured and not-configured states plus language and runner settings. A controlled enablement request can look like this:

gh api --method PATCH \
  -H "Accept: application/vnd.github+json" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "/repos/OWNER/REPO/code-quality/setup" \
  -f state=configured \
  -f runner_type=standard \
  -f 'languages[]=javascript-typescript' \
  -f 'languages[]=python'

GitHub may return 202 Accepted with a run_url; poll that run instead of assuming the configuration has completed. A 409 means another setup update is in progress. Use the minimum token scope, inventory current configuration before patching, log every change, and keep the UI pilot as the policy source before automating at scale.

A staged rollout and governance plan

A staged rollout expands only after the previous stage produces enough evidence to make a decision. This sequence adapts GitHub's rollout-at-scale guidance into explicit exit conditions.

Assign explicit owners for product billing, Actions capacity, ruleset policy, false-positive review, and repository onboarding. Keep the gate definition in the normal change-review process. A threshold change can block every merge as effectively as a broken CI workflow.

Coverage deserves a repository-specific baseline. A new service and a large legacy monolith should not inherit one arbitrary percentage. Prefer a maximum-drop rule first, then raise the minimum only after the baseline workflow is stable. For quality findings, start with errors, review warnings in evaluate mode, and avoid “all findings” until notes have proven consistently actionable.

If your team also uses automated reviewers, the Codex Code Review rules guide explains how repository-specific instructions differ from deterministic CI. The OpenAI Agents SDK guide covers guardrails for broader agent workflows, while the mobile coding-agent comparison helps separate review policy from the client used to supervise an agent.

Metrics that justify expansion

Do not use total findings as the primary success metric; a noisier detector can make that number rise while trust falls. Track a compact scorecard by repository and detection type.

GitHub's 67.3% pre-merge figure is a useful vendor reference, not a target to copy. Freeze your definitions before comparing periods. A resolved finding, a dismissed finding, and an Autofix accepted without tests are not equivalent outcomes.

If the public preview was already enabled

GitHub says there is no technical migration or reconfiguration for preview users. Existing configurations continue under the current GitHub agreement, now as a paid product. The urgent work is commercial and operational:

• Export the list of enabled repositories and map them to owners.
• Calculate the current 90-day active-committer population rather than using repository membership as a proxy.
• Verify who can draw from the shared AI-credit pool and set a hard-stop budget.
• Inspect runner minutes and queue time from preview scans.
• Check whether the AI detections page remained enabled from preview; GitHub's cost guide says that page is off by default for new use but remains on for repositories that enabled it during preview.
• Reconfirm any ruleset gate, especially the coverage rule's current release label.
• Disable repositories whose owner, budget, or value cannot be established.

Billing began automatically on July 20, 2026. Waiting for a later migration window does not defer that start date.

Roll back without losing the audit trail

Use the smallest rollback that addresses the problem.

1. Gate problem: Change an Active ruleset back to Evaluate or disable only the failing quality or coverage rule. Confirm ordinary pull requests can merge again.
2. Repository problem: Open Repository → Settings → Security → Code quality, select Disable, and save.
3. Organization problem: Set Repository access to a smaller selected set or No repositories. Turn on Enforce access if repository administrators must not re-enable it.
4. API-managed repository: Patch setup to state=not-configured, then read the configuration back and verify no later scans begin.
5. Cost overrun: Apply the hard-stop budget and reduce enabled scope; a budget does not remove license or already accrued usage.

GitHub's disablement guide says disabling stops future scans and new Actions or AI consumption immediately. Existing findings, scores, and scan history remain available if Code Quality is re-enabled. Usage and licenses already accrued in the billing cycle still appear on the next bill. Verify the setting, watch the Actions tab for later triggers, and record the disable timestamp and reason.

Use it or skip it

Pilot GitHub Code Quality when teams want a GitHub-native quality workflow, already use Actions, and can assign owners for spend, thresholds, and dismissal review. The combination of deterministic rules, reviewable Autofix, coverage deltas, organization targeting, and findings APIs is most useful when it feeds an existing engineering policy rather than creating a separate quality program.

Wait before enforcing gates when Code Quality checks are not reliable on representative pull requests, the repository lacks a default-branch coverage baseline, or teams have not classified dismissal reasons. Observe first; enforcement magnifies configuration errors.

Skip or disable it when the organization is on GitHub Enterprise Server, cannot accept the three-part cost, or already has an established quality system whose migration cost exceeds the value of consolidating in GitHub. Keep deterministic tests, linters, ownership review, and branch protections regardless of the product decision.

Official sources

Launch, availability, and billing

• GitHub Code Quality general availability announcement — July 20 release, availability, new capabilities, pricing summary, preview transition, and vendor-reported adoption figures
• About GitHub Code Quality — analysis model, supported use cases, licensing boundaries, languages, and optional Copilot delegation
• GitHub Code Quality billing — Actions, AI-credit, active-committer, bot, and unique-user definitions
• Viewing and managing Code Quality costs — usage reports, AI usage views, budgets, preview AI-detection setting, and cost controls

Setup, findings, and organization rollout

• Enabling GitHub Code Quality — repository and organization UI paths, prerequisites, runners, and billing confirmation
• Code Quality enablement across organizations and enterprises — repository-access modes, filters, custom properties, enforcement, and change behavior
• Rolling out GitHub Code Quality at scale — pilot selection, evaluate mode, tuning, enforcement, and expansion
• Fixing findings on a pull request — rule-based and AI comments, Autofix review, dismissal, and optional delegation
• Metrics and scores reference — maintainability, reliability, severity, and default-branch score definitions

Coverage, gates, API, and rollback

• Setting up code coverage — Cobertura XML generation, permissions, upload action, branch triggers, and pull-request display
• Code coverage reference — percentage and per-file delta calculations
• Setting code quality thresholds — severity choices, prerequisites, and organization or repository rulesets
• Setting code coverage thresholds — minimum coverage, maximum drop, evaluate mode, and current public-preview label
• REST API endpoints for Code Quality — findings and setup operations, permissions, request fields, and responses
• Disabling GitHub Code Quality — repository and organization paths, retained data, billing cutoff behavior, and verification