GitHub Copilot Changes Model Access on August 26: Which AI Models Can Turn On Automatically?

Short answer: on August 26, 2026, GitHub Copilot Business and Copilot Enterprise will start applying a new Default availability for released models policy to generally available AI models that admins have not explicitly configured.

If that default policy is enabled — which GitHub says is the default — eligible unconfigured models can become available to users automatically. If the policy is disabled, those models stay off until an admin deliberately enables them.

This is not a blanket switch that enables every model. Explicit per-model choices are preserved, preview models are excluded, open-weight models are excluded, and models outside GitHub's data-retention agreement are excluded. Enterprises with data-residency or FedRAMP restrictions also keep those constraints.

The practical implication is bigger than one settings change: silence is about to become a policy decision. Teams that previously relied on “we never enabled that model” should decide whether new generally available models should be opt-out or opt-in before August 26.

Policy check — August 19, 2026: GitHub's current changelog and documentation say the setting is already visible but does not affect model availability until August 26, 2026. The change applies to Copilot Business and Copilot Enterprise, not individual Copilot subscriptions.

What changes on August 26?

GitHub introduced the policy on July 29 with a 28-day preparation window.

Today, an enterprise or organization can have models that are effectively unconfigured: nobody has explicitly decided to enable or disable them at that level.

On August 26, those eligible models are relabeled inherits default and begin following the new default policy.

The important phrase is explicit choices are preserved. GitHub is not overriding a model that an administrator deliberately disabled.

The change affects the models where no explicit choice exists.

Which models can turn on automatically?

GitHub's documentation defines the eligible group narrowly: new and existing unconfigured generally available models.

At the enterprise level, an unconfigured model is one that has not been added to the model list on the enterprise model-configuration page.

At the organization level, it can be a model that the enterprise has made Optional but the organization owner has not explicitly enabled or disabled. GitHub notes that this organization-level behavior differs for enterprises participating in its enterprise-teams model-access preview.

If the relevant default policy is enabled, those eligible models can become available without a separate per-model approval step.

Models that do not inherit the automatic default

GitHub currently lists several exclusions:

• models an administrator has explicitly disabled;
• models that have not reached general availability;
• open-weight models, including examples such as DeepSeek, Kimi K2.7 Code and Kimi K3;
• models not covered by GitHub's data-retention agreement, with Claude Fable 5 given as the current example;
• for enterprises restricting Copilot to data-resident or FedRAMP-compliant models, models that do not meet those requirements.

This is why “GitHub is turning on every new AI model” would be inaccurate. The policy is a default for an eligible subset, with existing governance boundaries still applied.

Why this matters even if the model picker is not a security boundary

For a small team, another model appearing in Copilot may feel like a minor product change. For a larger organization, model availability can affect several operational decisions at once:

• which providers developers are allowed to use;
• which models have completed internal legal, security or procurement review;
• whether a model is approved for regulated or data-resident workloads;
• how teams document supported AI workflows;
• how quickly new models are tested before broad use;
• whether help-desk and developer-enablement teams know what users can select.

The new policy changes the default workflow from approve each eligible model before it appears to allow eligible GA models unless the default or the individual model is blocked.

Neither approach is universally correct. The useful question is which governance model matches the organization.

Choose the policy by operating model, not by enthusiasm for AI

A simple decision matrix makes the choice clearer.

The last row is the most practical one. If nobody can answer who is responsible for reviewing a newly released model, an automatic-enable default turns an organizational gap into a product setting.

The subtle difference between “optional” and “inherits default”

Enterprise admins can set a model to Enabled, Disabled, or Optional.

• Enabled means it is enabled for everyone at the enterprise baseline.
• Disabled means it is explicitly unavailable at that baseline.
• Optional means more granular controls can decide who gets it.

For organizations using the standard organization-based model controls, an Optional model can then be enabled or disabled by an organization owner. If the organization leaves it unconfigured, the August 26 default-availability policy can determine the outcome.

That means an enterprise can delegate a model decision without necessarily forcing each organization to make a manual choice. After August 26, an organization that leaves the model untouched is still making an effective choice through its default policy.

GitHub also offers targeted model rules for enterprises that need to control exact model access for selected organizations, and an opt-in enterprise-teams preview for more role-based access.

A 15-minute pre-August-26 admin checklist

1. Find the default policy

For an enterprise, GitHub's current instructions route through the enterprise's AI controls and Copilot model settings. Organizations have corresponding model-availability controls when the enterprise policy allows them to manage model access.

Locate Default availability for released models and record its current value.

Do not assume “we have never touched it” means disabled. GitHub says the default is enabled.

2. Inventory models with explicit decisions

Separate the current model catalog into three buckets:

This is more useful than reviewing model names one by one without knowing which settings will actually change behavior.

3. Decide whether the organization is opt-in or opt-out by design

Write the policy in one sentence.

For example:

Eligible generally available Copilot models are available by default unless explicitly blocked.

Or:

New Copilot models require explicit approval before organization-wide access.

If the sentence and the GitHub setting disagree, change the setting rather than relying on tribal knowledge.

4. Explicitly disable known exceptions

Keeping the global default enabled does not mean giving up model-level control.

GitHub says an explicitly disabled model is not eligible for default enablement. So an organization can keep automatic access for normal GA releases while blocking a small set that does not fit its requirements.

That is usually cleaner than repeatedly changing the global default to deal with one exception.

5. Check higher-level compliance restrictions

Enterprises using data-residency or FedRAMP model restrictions should verify those policies before interpreting the model list.

GitHub says models that do not respect those restrictions are excluded from automatic default enablement. The new default therefore sits inside those boundaries rather than replacing them.

6. Assign an owner for future model releases

The policy is dynamic. GitHub says an inherits default model continues tracking the default, and newly released GA models start unconfigured.

Someone should therefore own a lightweight recurring review of:

• new model announcements;
• changes in GA status;
• data-handling constraints;
• provider or model retirements;
• internal exceptions.

The goal is not to hold a governance meeting for every model. It is to make sure “nobody noticed the release” is not the process.

A practical test: what happens when a new GA model launches?

Imagine GitHub adds a future generally available model called Model X.

Scenario A: default enabled

1. Model X is released as an eligible GA model.
2. No administrator sets an explicit model rule.
3. It inherits the enabled default.
4. Eligible users can receive access according to the rest of the enterprise or organization policy stack.

Scenario B: default disabled

1. Model X is released.
2. No administrator sets an explicit rule.
3. It inherits the disabled default.
4. Users do not receive access until an administrator deliberately enables it.

Scenario C: default enabled, but Model X is explicitly blocked

1. Model X is released.
2. An administrator explicitly disables it.
3. The explicit setting wins.
4. It stays unavailable even though the default is enabled.

That three-scenario test is the easiest way to explain the change internally. The question is no longer just “what models have we enabled?” It is also “what happens when nobody clicks anything?”

What this change does not decide

The August 26 policy does not answer every Copilot model question.

Model availability still depends on the Copilot plan and client. GitHub documents different supported models across GitHub.com, Copilot CLI, Visual Studio Code, Visual Studio, JetBrains IDEs and other clients, and some recent models require minimum client or extension versions.

The policy also does not make preview models generally available, override explicit blocks, or bypass data-residency and FedRAMP restrictions.

And it does not guarantee that every future model will be eligible for default enablement. GitHub can classify models differently based on release stage, weight availability, provider agreements and compliance characteristics.

The durable admin practice is therefore to manage the rule, not to memorize today's model list.

What to watch after August 26

Three things are worth checking after the policy becomes active.

1. Whether the effective model list matches the intended policy

Confirm that models expected to inherit the default have the correct availability and that explicit enables/disables were preserved.

2. New GA announcements

GitHub recommends following its changelog for model releases. Under an enabled default, an eligible future GA release can matter immediately even when nobody opens the admin page that day.

3. Model retirements and replacements

Availability is not only expanding. GitHub's supported-model documentation also lists scheduled model retirements. A governance process should handle both sides: new models arriving and older models leaving.

Conclusion

GitHub Copilot's August 26 change is not “all AI models become enabled.” It is a change in the meaning of no explicit decision.

For Copilot Business and Enterprise, eligible generally available models that are unconfigured will begin inheriting a default policy. With the default enabled, they can become available automatically; with it disabled, they remain off. Explicit model choices and major compliance exclusions remain intact.

The best pre-deadline action is simple: decide whether the organization wants model access to be opt-out or opt-in, make the GitHub default match that decision, and explicitly configure the exceptions.

That turns August 26 from a surprise model-picker change into a predictable governance rule.

Sources

Checked August 19, 2026:

• GitHub Changelog — Default model enablement for Copilot Business and Enterprise
• GitHub Docs — About default availability of Copilot models
• GitHub Docs — Managing availability of models in your enterprise
• GitHub Docs — Configuring access to AI models in GitHub Copilot
• GitHub Docs — Supported AI models in GitHub Copilot