GitHub Copilot’s August 26 Model Policy: What Admins Must Audit
On August 26, 2026, GitHub Copilot Business and Enterprise will change how it handles generally available models that administrators have never explicitly configured. Those models will move from unconfigured to inherits default, and an enabled default policy will make them available without a separate approval for each release.
The practical risk is not that GitHub is switching on every model. It is that a quiet default can become a live access decision across IDEs, GitHub.com, and Copilot CLI. Administrators have three days to decide whether their organization wants automatic adoption or explicit model approval—and to document the exceptions before a separate round of model retirements on September 1.
What Changes on August 26
GitHub announced the change on July 29 in its Copilot changelog. The new Default availability for released models policy already appears in enterprise and organization settings, but it begins affecting access on August 26.
After that date:
- Unconfigured GA models inherit the policy. With the default enabled, eligible models become available; with it disabled, they remain unavailable.
- The inherited state stays live. Changing the default later changes every model still marked
inherits default. - Explicit choices win. A model deliberately enabled or disabled keeps that setting.
GitHub’s default-availability documentation defines unconfigured differently at each layer. At enterprise level, it means a model that has not been added to the configuration list. At organization level, it can mean a model the enterprise marked optional but the organization never enabled or disabled.
That distinction matters. A team can believe it has made no decision while still inheriting a decision from above.
Default Enablement Is a Change-Management Decision
The tempting response is to treat this as a checkbox: leave the default on for faster access, or turn it off for tighter control. That misses the operational problem.
A model choice changes more than answer quality. It can alter provider routing, latency, cost behavior, evaluation results, and the assumptions behind internal guidance. GitHub’s model-hosting reference documents different hosting arrangements and data commitments across OpenAI, Anthropic, Google, xAI, Microsoft, and open-weight models.
GitHub excludes several classes from automatic enablement: pre-GA models, explicitly disabled models, open-weight models including DeepSeek and Kimi variants, Claude Fable 5 because it is not covered by GitHub’s data-retention agreement, and models that conflict with data-residency or FedRAMP restrictions.
Those exclusions are useful guardrails, but they are not a substitute for an internal approval standard. Eligibility for the default does not prove that a model fits your repository sensitivity, regulated workload, evaluation threshold, or spending policy.
Build a Three-Layer Policy Map
GitHub’s enterprise model-management guide gives each model one of three baseline states:
- Enabled: available to everyone in the enterprise.
- Disabled: unavailable across the enterprise.
- Optional: delegated to organizations or, in the enterprise-teams preview, granted to selected teams.
Administrators should map access at three layers rather than review a flat model list.
1. Enterprise baseline
Explicitly enable models that are approved for general use and disable models that violate a firm requirement. Use optional only when a lower layer genuinely owns the decision.
2. Organization or team exceptions
For organization-based control, an optional model may be enabled or disabled by an organization owner. If the organization leaves it unconfigured, it follows that organization’s default-availability policy.
The enterprise-teams preview behaves differently: organization-level model settings are deactivated, and teams receive additive access on top of the enterprise baseline. A user in multiple teams receives the union of the models enabled across those teams.
3. Client and workflow dependencies
Copilot policies can apply across IDEs, GitHub.com, and Copilot CLI, but GitHub warns that not every policy reaches every surface. The Copilot app and Copilot CLI also have separate client policies. Test the surfaces your developers actually use instead of assuming one settings page describes the whole experience.
The September 1 Deprecations Make the Audit Urgent
Five days after the default policy takes effect, GitHub will retire six model entries across Copilot Chat, inline edits, ask and agent modes, and code completions. The official deprecation notice names Gemini 3.1 Pro, Claude Opus 4.5, Claude Opus 4.6, Claude Sonnet 4.5, Claude Sonnet 4.6, and Raptor Mini.
GitHub provides suggested replacements, but administrators may need to enable those alternatives before users can select them. Existing prompts, team documentation, evaluation baselines, and automation instructions that name a model should therefore be treated as dependencies—not preferences.
Do not wait for a user to report that a picker changed. Search internal docs and configuration for retired model names, validate replacements on representative tasks, and record which owner accepted any behavior or cost change.
A 20-Minute Audit Before August 26
Use this sequence to turn the policy change into an auditable decision:
Choose the default posture. Decide whether newly released eligible GA models should be available automatically or require explicit approval.
List inherited models. Identify every model currently unconfigured or optional without a lower-layer choice.
Make exceptions explicit. Disable models that fail security, residency, contractual, evaluation, or cost requirements; explicitly enable models already approved.
Trace delegation. Record whether organizations or enterprise teams own optional-model decisions, and identify users who inherit access from multiple groups.
Plan the September migration. Find references to the six retiring models and test approved replacements before September 1.
Assign an owner and evidence trail. GitHub recommends limiting policy access and using the audit log to monitor policy and organization-enablement changes. Keep the reason for each exception alongside the setting.
The result should be a small policy table with model, state, scope, owner, reason, review date, and replacement. That artifact will outlast the current model catalog.
Limitations
This is an account-policy analysis, not a guarantee that every Copilot client exposes identical models or controls. Availability also depends on plan, client, enterprise restrictions, and GitHub’s evolving catalog.
The model list and hosting terms cited here were checked on August 23, 2026. Administrators should reopen GitHub’s current model-hosting and supported-model documentation during the audit, especially for preview features and provider-specific retention terms.
The Bottom Line
GitHub Copilot’s August 26 change turns absence of configuration into an active policy outcome. Organizations that want fast model adoption can keep the default enabled—but they should do so deliberately, with explicit exceptions and an owner for future releases.
For stricter environments, disable default availability now, approve models individually, and use the September 1 retirements as a test of your migration process. The durable control is not a static allowlist. It is a repeatable way to evaluate, enable, replace, and audit models as the catalog changes.
