Copilot network requests are now routed based on subscription

Note: This feature has been rolled back. For the latest information about this capability, view this new post. 

Starting today, network requests for Copilot are routed based on a user’s Copilot subscription. Requests for Copilot Individual, Copilot Business, and Copilot Enterprise users now route through different endpoints.

This change enables Copilot Business and Copilot Enterprise customers to make sure all Copilot users on their networks are accessing Copilot through their Copilot Business or Copilot Enterprise subscription, and that all Copilot user data is handled according to the terms of their Copilot Business or Copilot Enterprise agreement. In essence, customers will be able to use their network firewall to explicitly allow access to Copilot Business or Copilot Enterprise, and/or block access to Copilot Individual.

In 90 days, on October 31, 2024 we will enable enforcement of the user’s subscription on the new endpoints, ensuring only Copilot Business users can connect to Copilot Business endpoints and only Copilot Enterprise users can connect to Copilot Enterprise endpoints.

Read more about subscription-based network routing here.

GitHub Copilot Chat and pull request summaries are now powered by GPT-4o

Copilot Chat and pull request summary generation now use GPT-4o, bringing the performance of OpenAI’s latest flagship model to all developers.

Copilot Chat is available in Visual Studio, VS Code, JetBrains IDEs, GitHub Mobile apps, and GitHub.com.

To use the new GPT-4o model in your IDE, ensure you are using at least the minimum version of Copilot Chat specified here:

What this means for Copilot users

With this upgrade to GPT-4o, Copilot users will experience the following benefits:

  1. Faster response times – up to 55% faster TTFT (time to first byte)
  2. More accurate and reliable Copilot Chat responses – our testing showed a 60% increase in user satisfaction.

Commitment to quality

The upgrade process focused on our unwavering commitment to quality, safety, and security. Here’s what that entailed:

  1. Offline and online evaluation: We performed rigorous offline and online testing to ensure the model brings tangible benefits to users. This involved thorough benchmarking and running simulations of real-world software development scenarios to validate the improved performance and accuracy of GPT-4o.
  2. Red teaming: To preemptively address any potential safety issues, we conducted extensive red teaming exercises. These tests challenged the model to ensure it meets our high standards for safety and reliability in diverse coding environments.

We can’t wait to see what you create with the new GPT-4o-powered Copilot!

Let us know your feedback and join the discussion within the GitHub Community.

Happy coding!

See more

Repository updates July 31st 2024

We’re excited to bring an updated repository list view experience and the ruleset merge queue rule to general availability, as well as an update to the status check and workflow rules.

Finding repositories in your organization is now easier

With the introduction of custom properties earlier this year we wanted to make it easier to find repositories across your organization. With the new organization repository view and advanced filtering you find repositories based on common parameters like visibility and language, but also custom properties, size, license and a host of additional values.

Screenshot of repository list view filtered by visibility, archived status and a custom property showing a list of 64 repositories.

Repository Rules updates

Repository ruleset merge queue rule is now generally available

In addition to being able to manage your merge queue via rules, you can now see all the pull requests that merged in the same group along with the checks needed for the queue with rule insights.

Screenshot of repository rule merge queue options with default configurations.

Learn more about merge queues in our documentation and repository rules REST API

Avoid required status checks and required workflows when creating branches

Applying status check and actions workflow rules to newly created branches has been a point of friction in rulesets. When creating a new branch will fail unless you add bypass actors or create an intermediate unprotected branch. To alleviate this friction there is a new option available prevent checks and workflows from running on new branches.

Screenshot of require status check rule with the new "Do not require status checks on creation" option enabled

Learn more about status check rules and required workflows rules in our documentation.

Join the discussion within GitHub Community.

See more
View all changes