Ahab

Posted on Aug 25 Originally published at indieseek.co

GitHub Copilot Default Model Policy Checklist

#ai #programming #github #productivity

Originally published on IndieSeek.

GitHub Copilot default model availability: reconcile inherited access before August 26

Quick answer

On August 26, 2026, GitHub Copilot Business and Enterprise change how unconfigured generally available models behave. Each eligible model that an administrator has not explicitly enabled or disabled will become inherits default. If the Default availability for released models policy is enabled—the initial default—the model becomes available. If the policy is disabled, it stays unavailable. The inherited state remains live, so changing the default later changes every inherited model immediately. Explicit per-model decisions are preserved.

This is an access policy, not a way to choose which model Copilot's Auto mode uses. Treat those as separate controls. Before the cutover, snapshot both enterprise and organization settings, calculate effective access, and test representative users. Do not rely on one admin screen or one model picker.

Who this is for

This guide is for enterprise owners, organization owners, security teams, platform engineers, and FinOps owners responsible for Copilot Business or Enterprise. Individual subscribers are outside this policy change.

It is especially useful when your enterprise delegates optional models to organizations, uses targeted model rules, or is testing enterprise-team model access. If you are evaluating one newly released model rather than the default policy, use the Claude Opus 5 Copilot rollout checklist or the Kimi K3 availability checklist.

What changes on August 26

GitHub's policy has been configurable during a 28-day preparation window, but it has not affected availability. At cutover, existing and future eligible GA models that remain unconfigured follow the default. Several categories do not auto-enable: explicitly disabled models, pre-GA models, open-weight models such as DeepSeek and Kimi, models outside GitHub's data-retention agreement, and models excluded by data-residency or FedRAMP restrictions.

The difficult part is that effective access may depend on two policy layers:

Enterprise state	Organization state	Effective result after cutover
`Enabled`	Any	Available; enterprise baseline wins
`Disabled`	Any	Unavailable; the organization cannot override it
`Optional`	Explicitly enabled	Available in that organization
`Optional`	Explicitly disabled	Unavailable in that organization
`Optional`	Unconfigured + default enabled	`inherits default` → available
`Optional`	Unconfigured + default disabled	`inherits default` → unavailable

If enterprise-team model access preview is enabled, organization model settings are deactivated. The effective set becomes the enterprise baseline plus grants from every enterprise team the user belongs to. Do not mix that preview's additive team rules with the normal organization table.

A six-step reconciliation workflow

1. Identify the actual authority path

For each test user, record the Copilot seat source, enterprise, organization, and whether enterprise-team model access preview is enabled. GitHub notes that a user can receive policy through multiple organizations or enterprises, and policy combination rules vary. Start with the license path instead of guessing from repository membership.

2. Capture a before-state ledger

Record the default policy at every active enterprise and organization. Then inventory each model as Enabled, Disabled, Optional, or Unconfigured. Include targeted model rules and enterprise-team grants in separate columns.

Use a reviewable record:

checked_at: 2026-08-25T09:00:00+08:00
authority_mode: organizations # or enterprise-teams-preview
enterprise_default: disabled
organization_default: enabled
model: example-ga-model
enterprise_state: optional
organization_state: unconfigured
expected_after_cutover: enabled-via-inherited-default
owner: platform-team
rollback: disable-organization-default

Screenshots are useful evidence, but keep the normalized ledger so reviewers can compare settings across many organizations.

3. Choose one governance posture deliberately

For manual approval, disable the default policy and explicitly enable vetted models. For rapid GA access, keep the default enabled and explicitly disable models that fail compliance, cost, or evaluation requirements. Do not turn every current model into an explicit setting merely to preserve a screenshot; that defeats the live-default mechanism and creates future policy drift.

4. Reconcile expected access before touching users

Calculate the expected effective state with the matrix above. Keep exclusions as a separate gate: a model cannot inherit availability if it is pre-GA, open weight, outside the retention agreement, or incompatible with an enforced residency policy.

For larger rollouts, compare this result with the managed-settings rollout checklist so model access and client access are not confused. A model can be allowed while a specific Copilot client remains disabled.

5. Run six harmless canaries

Use representative test accounts and a harmless prompt. Do not change production repositories.

With default disabled, an unconfigured eligible GA model stays absent.
With default enabled, the same model becomes available through inherits default.
An explicit model deny remains denied under an enabled default.
An explicit model enable remains enabled under a disabled default.
An excluded model remains unavailable regardless of the default.
In enterprise-team preview, a user sees the enterprise baseline plus team grants, while organization settings have no effect.

Check at least GitHub.com and one supported IDE. For Copilot CLI, /model shows the models available to that user. Record account, client version, observed picker list, timestamp, and expected state. A picker match proves visibility, not which model Auto will select for a task.

6. Verify behavior after cutover and keep rollback ready

Re-run the same six canaries after August 26. Review the audit log for policy changes and download the AI usage report after a representative interval. GitHub's report includes per-model input, output, cache-read, cache-write tokens, and AI credits, which helps detect unexpected adoption; zero usage does not prove a model was unavailable.

If access expands unexpectedly, disable the relevant default policy. All inherited models follow it immediately, while explicit per-model settings remain intact. Then re-run the negative canary before declaring rollback complete.

Decision tree

Do you require explicit approval for every new GA model?
  yes -> disable Default availability for released models
         explicitly enable only reviewed models
  no  -> keep the default enabled
         explicitly deny exceptions

Is enterprise-team model access preview enabled?
  yes -> reconcile enterprise baseline + additive team grants
  no  -> reconcile enterprise state + organization state + org default

Do all six canaries match the ledger after cutover?
  no  -> disable the relevant default, inspect policy authority, retry
  yes -> monitor audit log and per-model usage; keep the ledger current

Common mistakes

Confusing default availability with the Auto model selection algorithm.
Reading an organization setting when enterprise-team preview has deactivated it.
Assuming Unconfigured means unavailable after August 26.
Expecting open-weight or pre-GA models to inherit the default.
Testing only the admin UI, without a licensed user on a real client.
Treating model-picker visibility as proof of usage, cost, or Auto routing.
Disabling the global default without preserving intentional explicit enables.

FAQ

Does this affect individual Copilot plans?

No. GitHub documents the policy for Copilot Business and Copilot Enterprise.

Will explicit model settings be overwritten?

No. Explicit enables and disables are preserved. Only unconfigured eligible GA models move to inherits default.

Does enabling the default make every model available?

No. Pre-GA, open-weight, retention-excluded, and policy-incompatible models do not qualify for automatic enablement.

Does this set the model Copilot Auto will use?

No. It controls which models can be available. Auto selection is a separate runtime choice.

Sources

Read the maintained bilingual original on IndieSeek.

DEV Community