GitHub Updates & Release Notes

Usage-based billing is active for all Copilot plans

As announced in our recent blog post, usage-based billing for GitHub Copilot is now live for all users and Copilot code review consumes GitHub Actions minutes, in addition to GitHub AI Credits.

As part of this release, we’re also launching new user-level budget controls and enabling upgrades to Copilot Max.

As of June 1, all Copilot plans bill based on GitHub AI Credits consumed. Each plan comes with monthly included usage. To find more details about what’s included in each plan, please review the documentation for usage-based billing for individuals and usage-based billing for organizations and enterprises.

After you consume your included AI Credits, you can continue to spend additional AI Credits and be billed at the end of the month by setting an additional spending budget. For individual plans, we may limit your total additional AI Credits based on your usage patterns, billing history, and verification status for your user account. To continue spending AI Credits, we recommend upgrading to the next plan for more included and additional usage limits.

Configure a default Actions runner for Copilot code review

As of June 1, Copilot code review consumes Actions minutes, in addition to GitHub AI Credits. By default, Copilot code review will use a standard GitHub-hosted runner, but organization admins can now set a default runner to be used automatically across all repositories, without requiring each repository to be individually configured. To learn more, see Configure runners at the organization level.

Control spending with user-level budgets

For customers needing more granular spend controls, user-level budgets are now generally available for organizations and enterprises. Admins can now set a universal budget for users or override for specific sets of users. As users approach their budgets, admins will receive email notifications and can adjust budgets anytime from their billing settings. For AI credits, user-level budgets control total usage, not just additional spend. See our budget management documentation for more details.

Copilot Max: optimized for power users

Copilot Max is available today as an upgrade for existing Student, Pro, and Pro+ subscribers, with higher included usage and higher spending limits to support more intensive workflows. New user sign-ups will open in the coming weeks.

New sign-ups remain paused

New user sign-ups remain paused for Copilot Student, Pro, Pro+, and Max plans. We’ll reopen sign-ups in the coming weeks.

Join the discussion within GitHub Community.

The post Updates to GitHub Copilot billing and plans appeared first on The GitHub Blog.

To help you tell a deeper Copilot adoption story—not just who is active, but how they’re using Copilot—the Copilot usage metrics API now classifies each engaged user into an AI adoption phase based on their Copilot product usage over a rolling 28-day window. A new ai_adoption_phase field is available on user-level reports, and a new totals_by_ai_adoption_phase array surfaces per-phase metrics on enterprise- and organization-level reports.

What’s new

Each engaged user is assigned to one of four phases based on the Copilot surfaces they’ve used on at least two days in the last 28-day window:

• Phase 0 — No cohort: User did not meet the engagement criteria for any phase.
• Phase 1 — Code first: User engaged with code completion and/or IDE agent mode.
• Phase 2 — Agent first: User engaged with a single GitHub-based agent surface (i.e., Copilot cloud agent, Copilot code review, or Copilot CLI).
• Phase 3 — Multi-agent: User engaged with two or more GitHub-based agent surfaces, or with the new GitHub Copilot app.

Each ai_adoption_phase value includes a version field (starting at v1) so the classification logic can evolve as Copilot’s product surface grows, without breaking historical context.

On the enterprise- and organization-level reports, the new totals_by_ai_adoption_phase array groups engagement and activity metrics by phase, including:

• Total engaged users (2-day-in-28 engagement window)
• User-initiated interaction average
• Code generation and acceptance activity averages
• Lines of code added and deleted averages
• Pull requests created, merged, and reviewed averages
• Median time-to-merge average

Aggregated metrics report the average per user within each phase rather than the sum.

Why this matters

• Tell the maturity story: Move beyond simple active-user counts and show which Copilot capabilities your developers are actually adopting.
• Track cohort progression: Watch users graduate from code-first usage into agent-first and multi-agent workflows over time.
• Target enablement: Focus training, documentation, and rollout programs on the phases where you see the biggest opportunity.

Important notes

• These metrics are available to enterprise administrators and organization owners who have access to Copilot usage metrics through the REST API.
• You can use this release in combination with the teams filter ship for greater granularity.
• Join the discussion within GitHub Community.

The post Copilot usage metrics API adds cohorts for AI adoption appeared first on The GitHub Blog.

Enterprise administrators and billing managers can now set hard budget limits for GitHub Advanced Security (GHAS) SKUs, preventing teams from exceeding their allocated license budgets.

Previously, license-based products like GHAS only supported soft budgets. Admins could set a spending target and receive email notifications at 75%, 90%, and 100% thresholds, but the product did not enforce the limit. This could lead to accidental overspending, especially during user onboarding flows such as IdP group provisioning where licenses are automatically assigned.

With hard budget limits, once a GHAS budget threshold is reached, additional license usage is blocked, and GHAS won’t be enabled on new repositories until the budget is increased or licenses are freed. This gives enterprises precise control over their security spending at the organization level.

What’s new

• Enforceable license limits for GHAS: Set a hard budget in license count and GitHub will prevent new license assignments once the limit is met.
• License-to-cost transparency: When configuring a budget, a real-time estimate shows the dollar equivalent (e.g., X licenses ≈ ~$Y/month), so admins always know their remaining capacity, even for mid-month additions.
• Smart defaults for existing usage: If your enterprise already has active GHAS licenses, the new budget floor will be set to at least your current billable license count to avoid disruption.
• Continued alerting: Email notifications at 75%, 90%, and 100% thresholds remain active alongside hard limits, keeping admins informed as usage approaches the cap.
• Organization-level control: Enterprises can allocate license budgets scoped to a cost center and limit spending for the organizations assigned to the cost center. Organizations on the Team plan can also allocate license budgets for the organization to limit spending.

Getting started

Hard budget limits for GHAS can be configured in your enterprise billing settings under Budgets & alerts. Both new and existing customers can create hard budgets. Existing soft budgets can be migrated to the new license-based format through in-product flows.

To learn more, see Preventing overspending in the GitHub documentation.

Join the discussion within GitHub Community.

The post Hard budget limits now available for GitHub Advanced Security appeared first on The GitHub Blog.

CodeQL is the static analysis engine behind GitHub code scanning, which finds and remediates security issues in your code. We’ve recently released CodeQL 2.25.5, which includes accuracy improvements across C/C++, Java/Kotlin, and GitHub Actions queries.

Language and framework support

Java/Kotlin

We’ve introduced a new sink kind, path-injection[read], for Models-as-Data rows that only read from a path (such as ClassLoader.getResource, FileInputStream, and FileReader). This helps queries distinguish read-only path sinks from more dangerous ones.

GitHub Actions

We’ve extended the poisonable_steps modeling to detect additional sinks, including scripts executed via Python modules and go run in directories.

Query changes

C/C++

The cpp/cleartext-transmission query no longer raises an alert on calls to fscanf (and variants) when the call reads from an input that isn’t a socket, reducing false positives.

Java/Kotlin

The java/zipslip query no longer reports archive entry names that flow only to read-only path sinks such as ClassLoader.getResource, FileInputStream, and FileReader, reducing false positives.

GitHub Actions

The actions/unpinned-tag query now analyzes composite action metadata (action.yml and action.yaml files) in addition to workflow files, providing more comprehensive detection.

We’ve fixed the help file descriptions for the actions/untrusted-checkout/critical, actions/untrusted-checkout/high, and actions/untrusted-checkout/medium queries.

We’ve renamed actions/untrusted-checkout/high to more clearly describe which parts of the scenario run in a privileged context.

For a full list of changes, please refer to the complete changelog for version 2.25.5. Every new version of CodeQL is automatically deployed to users of GitHub code scanning on github.com. The new functionality in CodeQL 2.25.5 will also be included in GitHub Enterprise Server (GHES) release 3.22. If you use an older version of GHES, you can manually upgrade your CodeQL version.

The post CodeQL 2.25.5 improves query accuracy for GitHub Actions appeared first on The GitHub Blog.

Claude Opus 4.8, Anthropic’s latest Opus model, is now available in GitHub Copilot. In our early testing, Opus 4.8 demonstrates a clear step forward in code understanding and generation across a range of real-world coding tasks. It also handles complex problem-solving and large-codebase navigation with notable improvement to previous versions.

This model is launching with a 15X premium request multiplier until Usage Based Billing launches on June 1, 2026.

Availability in GitHub Copilot

Claude Opus 4.8 will be available to Copilot Pro+, Business, and Enterprise users.

You’ll be able to select the model in the model picker in:

• Visual Studio Code in all modes (i.e., chat, ask, edit, and agent)
• Visual Studio
• Copilot CLI
• GitHub Copilot cloud agent
• GitHub Copilot App
• github.com
• GitHub Mobile iOS and Android
• JetBrains
• Xcode
• Eclipse

Rollout will be gradual. Check back soon if you don’t see it yet.

Enabling access

Copilot Enterprise and Copilot Business plan administrators must enable the Claude Opus 4.8 policy in Copilot settings.

Learn more

To explore all models available in GitHub Copilot, see our documentation on models and get started with Copilot.

Share your feedback

Join the GitHub Community to share your feedback.

The post Claude Opus 4.8 is generally available for GitHub Copilot appeared first on The GitHub Blog.

Starting today, new sign-ups for GitHub Classroom are no longer available as we transition to partner solutions.

If you already have a GitHub Classroom account or existing classrooms, you can continue to use GitHub Classroom as usual, including creating classrooms and inviting students.

On August 28, 2026, GitHub Classroom will fully transition to partner solutions. After that date, users won’t be able to sign in to manage classrooms, and the GitHub Classroom website will be decommissioned. GitHub user accounts, repositories, and organizations won’t be affected.

For more information about this transition and recommended partner solutions, please refer to the GitHub Educator Community Discussion.

The post GitHub Classroom sign-ups are no longer available appeared first on The GitHub Blog.

Copilot Memory now includes improved memory deletion, adds a repository-level off switch, and brings further memory controls into the Copilot CLI. Copilot Memory is in public preview and available to all paid Copilot plans.

What’s changing

• Deletion guidance: When you ask Copilot to forget something, it now points you to the right place to remove the memory and down-votes the memory where voting is available.
• Repository-level off switch: Repository admins can now disable Copilot Memory for a repository from the existing Copilot feature controls in repository settings. Repository-level facts will no longer be stored or read. Preexisting facts are not deleted. User-level preferences are unaffected.
• /memory command in the Copilot CLI: Use /memory on to enable Copilot Memory, /memory off to disable it, and /memory show to check its current status. Your choice persists across sessions.
• Clearer scope at capture time: The store_memory permission prompt now explicitly states whether the entry will be a user-level preference (i.e., visible only to you, used in your sessions across repositories) or a repository-level fact (i.e., visible to all contributors on the repository).

Managing memories

• Your user-level preferences: Review or delete them in your personal Copilot Memory settings.
• Your repository’s facts: Repository owners can review, delete, or turn off Copilot Memory for the repository under Repository Settings > Copilot > Memory.
• Learn more about managing stored memories.

Share your feedback

For more information, see About GitHub Copilot Memory.

We’re continuing to evolve Copilot Memory and plan to bring it to more features in the future. To share feedback or join the discussion, visit the GitHub Community.

The post Copilot Memory has more controls for deletion, scope, and the Copilot CLI appeared first on The GitHub Blog.

You can now programmatically enable and configure GitHub Code Quality on individual repositories using the new Repository Enablement API, available today in public preview.

Two new endpoints are now available:

• PATCH /repos/{owner}/{repo}/code-quality/setup: Enable or disable Code Quality default setup for a repository, configure the languages to analyze, and specify the runner type.
• GET /repos/{owner}/{repo}/code-quality/setup: Retrieve the current Code Quality configuration for a repository, including state, languages, runner type, and analysis schedule.

Supported languages include csharp, go, java-kotlin, javascript-typescript, python, and ruby.

This feature is available in public preview on github.com and is not available on Enterprise Server.

To learn more about GitHub Code Quality, check out the documentation for code quality.

The post GitHub Code Quality: Repository Enablement API appeared first on The GitHub Blog.

Enterprise owners now have granular control over which GitHub Copilot models are available to each organization. With targeted model rules, you can allow specific models for specific organizations instead of relying on a single enterprise-wide setting. This capability is now in public preview.

We’ve also refreshed the experience for managing default model availability across your enterprise, making it easier to see and configure which models are available to your organizations.

What’s new

Targeted model rules let you create rules that allow specific Copilot models for selected organizations, giving you fine-grained control beyond enterprise-wide defaults.

What’s improved

The default model availability experience has a refreshed interface. From a single page, you can:

• Choose which default Copilot models are available to organizations in your enterprise.
• Set each model’s availability to Enabled (automatically on for all organizations) or Optional (organizations decide whether to enable it).

Who can use this

Customers on Copilot Business and Copilot Enterprise plans can use targeted model rules.

To get started, see Managing availability of default models and Managing default models for your organization.

Join the discussion in GitHub Community.

The post Target Copilot models to organizations with model rules appeared first on The GitHub Blog.

Dependabot now supports sbt. Add sbt as a package ecosystem in your dependabot.yml file. Dependabot will then monitor your build.sbt inputs and open pull requests when newer commits are available upstream. This applies to version updates, not security updates.

Get started

Add an sbt entry to your .github/dependabot.yml file, and Dependabot will start opening pull requests on the next scheduled run.

Learn more

Configuring Dependabot version updates

Introduction to sbt

Community discussion on sbt support

The post Dependabot version updates now support the sbt ecosystem appeared first on The GitHub Blog.

What’s changing

This week, we’re rolling out two improvements to our delegated workflows for secret scanning.

Sort bypass and dismissal requests in the UI: You can now choose between ascending and descending order for approval request lists in the UI.

New is_bypassed REST API filter: You can now filter by an is_bypassed query parameter when listing alerts, closing a gap with filtering that was already available in the UI.

These changes make it easier for organizations to manage requests at scale.

Sort bypass and dismissal requests

Previously, push protection bypass requests and alert dismissal requests appeared in a fixed order (newest-first). For large organizations, lack of control over sorting made it challenging to manage high volumes of requests. You can now order requests by Newest, Oldest, Recently updated, and Least recently updated directly in the filter UI bar, allowing security analysts and developers to focus on soonest-expiring requests.

Sorting is available at the repository, organization, and enterprise levels for both push protection bypass requests and alert dismissal requests. This improvement makes it substantially easier to manage requests at scale from the UI list view.

New is_bypassed REST API filter

Previously, the bypassed:true,false qualifier was supported from the UI list view for push protection bypass requests, without an equivalent filter option in the REST API. This improvement makes it easier to programmatically filter alerts by push protection bypasses without additional processing.

The secret scanning alerts API now accepts an is_bypassed boolean query parameter on all three list endpoints:

GET /repos/{owner}/{repo}/secret-scanning/alerts
GET /orgs/{org}/secret-scanning/alerts
GET /enterprises/{enterprise}/secret-scanning/alerts

Pass is_bypassed=true to return only alerts where push protection was bypassed, or is_bypassed=false to exclude them.

Learn more

Learn more about secret scanning and the secret scanning REST API in our documentation. These improvements were shaped by your feedback. Let us know what you think in the community discussion.

The post Filter secret scanning approval requests by sort order and bypass status appeared first on The GitHub Blog.

Code coverage metrics are now in public preview for all GitHub Code Quality users on github.com.

You can now see an aggregate percent of code covered directly on pull requests, giving reviewers a clear signal to help evaluate test completeness before merging. With coverage context in the pull request experience, your team can make faster, higher-confidence review decisions without switching to a separate tool.

To get started, enable code coverage for your repository and upload a Cobertura report from your existing CI workflow using the upload-code-coverage action.

Permissions

GitHub Apps and Actions workflows require the new code-quality:write fine-grained permission to upload code coverage reports to GitHub.

Availability and pricing

GitHub Code Quality is available today for GitHub Enterprise Cloud and Team, but isn’t yet available on GitHub Enterprise Server. It’s free during the preview period.

Learn more

Learn more about Code Coverage in documentation

Read the GitHub Code Quality documentation

Join the discussion and leave feedback on the Code Coverage announcement in the GitHub Community

The post Code coverage on pull requests is now in public preview appeared first on The GitHub Blog.

Today we’re shipping two updates focused on supply-chain security for npm:

• Staged publishing is generally available.
• New --allow-* install source flags (--allow-file, --allow-remote, --allow-directory) complement the existing --allow-git flag.

Both are available in npm CLI 11.15.0 or newer.

Staged publishing is generally available

Staged publishing is now generally available on npm. Instead of a direct publish that immediately makes a package version available to consumers, the prebuilt tarball is uploaded to a stage queue where a maintainer must explicitly approve it before it becomes installable. The queue is visible both on npmjs.com and in the npm CLI.

Staged publishing reinforces proof of presence on every publish, including those that originate from non-interactive CI/CD workflows and those using trusted publishing with OIDC. A human maintainer with a 2FA challenge is required to approve a staged package before it is released to the registry.

Staged publishing is live today, and so are the docs.

Overview and getting started

CLI reference and permissions

Trusted publishers (updated)

Requirements

npm CLI 11.15.0 or newer is required to use npm stage.

Update CI/CD workflows to use npm stage publish instead of npm publish where you want staged behavior.

Recommended setup

We recommend pairing staged publishing with trusted publishing (OIDC). A trusted publishing configuration can be limited to stage-only, which means npm publish from that workflow will be rejected and only npm stage publish is accepted. Your CI workflows continue to run non-interactively, and a maintainer later approves the staged version from the website or the CLI.

You can also run npm stage publish locally, but the highest-value setup is CI publishing to the stage queue and a maintainer approving from a trusted device.

If you already manage trusted publishing configurations in bulk, released Feb 2026, you can use it to migrate your packages to staged publishing. Remember to update your CI workflows to the new CLI version and to use npm stage publish.

New install source flags

In npm 11.10.0 we introduced --allow-git to give you control over whether npm install can resolve dependencies from Git sources. Starting in npm 11.15.0, we are adding three more flags so you can apply the same explicit-allowlist approach to every nonregistry install source:

• --allow-file: Controls installs from local file paths and local tarballs.
• --allow-remote: Controls installs from remote URLs, including https tarballs.
• --allow-directory: Controls installs from local directories.
• --allow-git (existing): Controls installs from any Git source, including github:, gitlab:, git+ URLs, and bare owner/repo shorthands.

Each flag accepts all (the current default) or none, and can also be set in .npmrc or package.json config.

Learn more by checking out our docs:

• npm install reference (the --allow-file, --allow-remote, --allow-git variants are on the same page)
• Config reference

As a reminder from the Feb 2026 announcement, --allow-git will change its default from all to none in the next major version of the CLI (v12). The new --allow-file, --allow-remote, and --allow-directory flags are additions in 11.15.0—you can opt into stricter behavior today by setting them to none.

Join the discussion

We’d like to hear how you’re rolling this out. Share feedback and questions in the GitHub Community discussion.

The post Staged publishing and new install-time controls for npm appeared first on The GitHub Blog.

What’s new

Following our previous updates, GitHub Copilot for Eclipse is open source, with the code available on GitHub under the MIT license.

This marks an important milestone for GitHub Copilot in the Eclipse ecosystem. By open sourcing the plugin, we’re inviting the community to explore, learn from, and contribute to how AI-powered developer experiences are built inside Eclipse.

Why open source?

Our primary motivation is community-driven innovation and increased transparency. Eclipse has thrived for decades thanks to its open ecosystem, and we believe AI tooling should be developed in that same spirit (i.e., openly and alongside the IDE itself). Putting the Copilot for Eclipse source in the open lets developers see exactly how the plugin works, reason about what it does, and help shape where it goes next.

What’s open today?

The GitHub Copilot for Eclipse repository is publicly available here: https://github.com/microsoft/copilot-for-eclipse

With the code now open, you can see exactly how Copilot works. Explore the implementation behind chat, code completions, and agentic workflows. Review system prompts, architectural decisions, and how context is handled. You can dig into the codebase and learn how Copilot for Eclipse is built end-to-end, including:

• Code completion: How inline code completions are produced and rendered.
• Next Edit Suggestions (NES): How next-edit suggestions are surfaced as you work.
• Chat: How the chat view, conversation flow, and tool calls are implemented.
• Agent mode: How multistep agentic workflows are wired up inside Eclipse.
• Skills and prompt files: How skills and prompt files are discovered, loaded, and invoked from chat.
• BYOK: How Bring Your Own Key is integrated.
• Advanced agentic capabilities: Custom agents, isolated subagents, plan agent, and Model Context Protocol (MCP) integration.

This is a partial list. There are additional features for you to discover in the codebase.

Contributing and feedback

We welcome contributions and feedback from the community.

Browse the code and open an issue to report bugs or suggest features.

Submit pull requests to fix bugs or improve the experience.

Share feedback and discussions through the project’s issue tracker.

As with any open-source project, we’ll continue to evolve contribution guidelines and collaboration processes alongside the community.

Community contributions

Since open sourcing the project, we’ve already started to see contributions from the community. We’d like to thank contributors, including:

• @iloveeclipse
• @travkin79
• @rsd-darshan
• @arpitjain099
• @raghucssit

You can view the full list of contributors on GitHub.

The post GitHub Copilot for Eclipse is open source appeared first on The GitHub Blog.