Know Which Models Your Team Can Use
Inherited model settings can change what your team can access. Record the effective setting before depending on a model.
- GitHub announced enforcement of its Copilot model-availability defaults for Business and Enterprise, rolling out from August 26 through September 1, 2026.
- Unconfigured generally available models inherit the global setting. Deliberate per-model choices are preserved.
- Open-weight models and models outside GitHub’s data-retention agreement are excluded from default enablement.
This announcement concerns Copilot administration: which models are available and how settings are inherited. It does not establish legal requirements for a product.
A team instruction that names a model is useful only if colleagues can access it. Our practical inference: document the model setting alongside the workflow that depends on it.
Ask the administrator to inspect the effective settings for the models your workflow needs. Note which choices are explicit, which inherit a default, and whom to contact when access differs. Inspection is enough for this exercise; changing settings requires a separate team decision.
Put it to work 20 minutes
A model-access note for one team workflow
In 20 minutes, choose one Copilot workflow, record the setting behind its preferred model and agree a fallback. If you cannot inspect the settings, write the question for your administrator and mark access as unconfirmed.
See a worked example
Illustrative team handoff. The model names and observed settings must come from your own account; this example does not assert any account configuration.
- Workflow and preferred model
- Review a small pull request. Record the team’s chosen model and confirm that each reviewer can select it.
- What controls access
- Access unconfirmed. Ask the administrator whether this model is explicitly enabled or follows an organization or default setting.
- If access is unavailable
- Use the team’s manual review checklist while access is checked. The reviewer records the decision and any remaining uncertainty before merging.
Your turn
Use one real task. Name the model only if your team has chosen one.
Record an observed setting, who checked it and when. Use “unconfirmed” if you cannot inspect it.
Name the next action and how you would check that it works.
Your draft stays in this browser. No account needed.
A documented default does not establish the effective setting in your account. Check the actual organization or enterprise configuration.
The dated GitHub announcement supports the description of model settings. Your account’s current effective configuration still needs inspection.
Can everyone who needs this workflow access the chosen model, or use the agreed fallback?
Watch: Administrator confirmation · A team member’s access check · Fallback review notes