Copilot models policy update - default on and enterprise teams targeting

[gpadak]

🏷️ Discussion Type

Product Feedback

Body

We are simplifying how enterprise customers control access to models in Copilot. The current policy experience is difficult to understand, difficult to target precisely, and difficult to evolve as we add more models. For GitHub Enterprise customers that have Copilot Business or Copilot Enterprise licenses, we are changing a couple things:

Default on global policy for generally available models

We're introducing a global default enablement policy for all GA Copilot models for Copilot Business and Copilot Enterprise customers. Instead of requiring admins to manually enable each new model as it ships, models that reach GA will be on by default with a single opt-out control for enterprises & organizations that need stricter governance.

Open-weight models and those that require data retention will not be automatically enabled, regardless of this global policy choice.

Rollout schedule

• July 29, 2026: the global policy is available but does not have effect. Access to unconfigured models stay as-is (disabled) for next 28 days.
• August 26th, 2026: Unconfigured models honor the global policy, on or off, and will state that they inherit the global policy decision. For most customers, this means those unconfigured models become available to their users.

AI administrators are always encouraged to make an explicit enable/disable decision for every model.

Enterprise teams targeting - public preview July 30th+

We are launching a preview that changes models policy to directly support user-based governance flows. AI administrators can set a baseline of available models for the entire enterprise, and then allow additional models to specific enterprise teams. This allows model access differentiation based on job role, training level, or experimentation with new models by frontier teams.

At the enterprise level, models can be:

• enabled: available to all members of the enterprise
• disabled: not available to any member of the enterprise
• optional: models are available to be assigned to enterprise teams

Enterprise Teams model access evaluates in a least-restrictive strategy, which means that if a user gets a model from any one enterprise team the user will have access to the model everywhere.

This is an opt-in preview

Enabling this preview will replace a customers' existing models policy and organization (resource-based) decisions in favor of enterprise teams. There is a toggle to turn on "Enterprise teams mode" that will allow you to get started. The rollback strategy is to turn off "Enterprise teams mode", which will reset the customer's policy to the last configuration.

Tell us your thoughts

If you're an administrator, setting AI standards for your business, a developer, or any user of Copilot Business/Enterprise we'd love to hear from you.

[Fadl84]

Hello,
To ensure predictable billing, it is crucial for us to estimate potential token consumption before an AI agent begins a task.
Additionally, we need a way to track actual consumption per task upon completion. This will allow us to accurately charge clients and manage bills across multiple parallel projects.

[FR-Frank-Ye]

It would be very helpful to tell us what exactly this new policy is called. I am having difficulties in finding it so I could review this change.

[925dk]

💯. When announcement email was sent it wasn't even there! Now it is (for me). Copilot -> Models. Top of page "Default availability for released models".

[FR-Frank-Ye]

Thanks! Now I see it too.

[oliveruhrig]

Does this functionality, of defining an enterprise team and granting it access to specific models include BKOY custom models?

[gpadak]

The models policy global default only covers the models included with your Copilot license and does not extend to those that are added via BYOK

[huntc]

I welcome this simplification as a user not really invested in the whos-who of models, but a couple of points:

1. "Default availability for released models" - there is no explicit definition of "released models". It would be nice to see a list of those, or at least an explanation.
2. Once a model is enabled or disabled, it can no longer be set to "Unconfigured" (inherits default). The dropdown of each model should provide this third setting.

[gpadak]

Hey @huntc this is helpful feedback. Generally available models are those available in the enterprise models policy and don't have a preview tag. There's a case to be made to make that list available outside of that interface, and would probably be best served by an API.

Once a model is enabled or disabled, it can no longer be set to "Unconfigured" (inherits default). The dropdown of each model should provide this third setting.

The goal is for an administrator to make an explicit decision for models where they can - and until they do, the global policy will provide a fallback decision to enable or disable a model for the enterprise by default.

There is a third setting of optional today which delegates that decision to an organization. In the upcoming enterprise teams targeting preview, this would be delegated to a team instead of an organization.

A question back to you... we've considered eliminating the unconfigured state entirely and having the global policy of enable/disable be the explicit decision for that model when a new model is launched. So instead of "inherits default" it would just take on the state of the global policy that is enabled or disabled. Would that be preferable to you?

[huntc]

Hey @huntc this is helpful feedback. Generally available models are those available in the enterprise models policy and don't have a preview tag. There's a case to be made to make that list available outside of that interface, and would probably be best served by an API.

I think also having that information listed in the GH UI would be valuable.

Once a model is enabled or disabled, it can no longer be set to "Unconfigured" (inherits default). The dropdown of each model should provide this third setting.

The goal is for an administrator to make an explicit decision for models where they can - and until they do, the global policy will provide a fallback decision to enable or disable a model for the enterprise by default.

There is a third setting of optional today which delegates that decision to an organization. In the upcoming enterprise teams targeting preview, this would be delegated to a team instead of an organization.

I'm not seeing that option yet:

A question back to you... we've considered eliminating the unconfigured state entirely and having the global policy of enable/disable be the explicit decision for that model when a new model is launched. So instead of "inherits default" it would just take on the state of the global policy that is enabled or disabled. Would that be preferable to you?

I personally welcome the decision making to be taken care of for me. I have no real interest in the models themselves, but I'd like to think that I'm getting the latest-and-greatest so that we can compete in what we do.

My goal is to have you make the best model selection decision for me, within the confines of my monthly budget. If you need to tell me to spend more along with justification, that's the decision making I want to make.

[OliverMeyerDSA]

Does the enterprise teams setting (should be available tomorrow) only affect enterprises or organisations with team plans as well?

The email is not clear:

Model Access by Enterprise Teams (Preview)
Today, model policies are all-or-nothing at the enterprise or org level.
...
• Organization-based targeting does not carry forward when you enter “enterprise teams mode”.

[petersonjdNIH]

I built NIH GitHub, where there's a diverse group of 40+ organizations. Some of those organizations belong to separate agencies that are not subject to the same policies or security posture of NIH, but do inherit quite a lot from them.

For that reason, I would encourage GitHub to think about this feature carefully. Especially allowing GitHub Orgs to run as self-sufficient as possible. GitHub Enterprises should be able to set per-Org or per-provider allowances that either result in full automony for the Org Admins to determine their stance and not gate approval behind Enterprise Admins who may have too much on their plate to be responsive to how fast the Frontier providers are moving. Another alternative approach would involve letting the Enterprise Admins to set this/these Frontier providers can be managed by the Org Admins, but these other ones cannot be and have a default posture across the GitHub Enterprise.

Thanks for working on this! More Enterprise policies can only improve things, but they must be thoughtfully done and not default stifling innovation or keeping older models around by default. That helps no one do anything well.

[kobayashikzu]

I really like the direction here — model control at the Enterprise Team level is exactly what we need. That said, at the moment it looks like configuration is designed to go through the UI (the "Enterprise teams mode" toggle).

It would be great to have a way to set and retrieve model policies at the Enterprise Team level via the API. Additionally, a machine-readable way to retrieve the model identifiers used in that API would be really helpful.

For some context: I'm on the team responsible for centralized operations at our company, and we provide Copilot Business to a large number of teams (i.e., Enterprise Teams). The idea is to let each team choose the models they want, and have our central desk apply everything collectively. But since we're dealing with several hundred teams, clicking through the UI manually doesn't really scale.