GitHub Copilot Model Policy API: Automate Model Governance After the October 2026 Deprecations

GitHub gave Copilot administrators two reasons to review model governance on October 19, 2026. First, it retired six models across most Copilot experiences. On the same day, it made the Copilot model policy REST API generally available for enterprises, enterprise teams, enterprise apps, and organizations.

The timing matters. A model retirement is not only a model-picker change: it can break saved instructions, internal documentation, extensions, scripts, and agent workflows that assume a particular model remains selectable. The new API gives administrators a repeatable way to inventory policy state, enable approved replacements, and prove what changed.

This guide separates confirmed GitHub behavior from operational recommendations. It does not compare model quality, claim benchmark results, or assume a public model identifier from a display name. The safe pattern is to read the live policy response first and then patch only the identifiers that GitHub returns for your account.

What changed on October 19, 2026

Confirmed by GitHub: the following models were deprecated across most Copilot experiences, including Copilot Chat, inline edits, ask and agent modes, and code completions. GitHub says no action is required to remove the retired models, but administrators may need to enable alternatives through model policies.

Use the October 19 retirement notice as the source of truth for that final mapping. The earlier September announcement listed different suggested versions for several models; the day-of-retirement notice supersedes it.

Also confirmed on October 19: GitHub announced generally available GET and PATCH endpoints for model policy management. The four scopes are enterprise, enterprise team, enterprise app, and organization. This creates a practical path from a time-sensitive migration notice to a controlled configuration change.

The four policy scopes

There is one documentation detail worth catching before you automate. The October 19 changelog shows a team path with {team_slug}, while the current REST reference documents {team_id} and shows an integer team_id parameter. For a production script, follow the live REST reference and test against a non-critical team rather than copying the announcement path verbatim.

The enterprise AI controls reference covers enterprise, team, and app endpoints. Organization endpoints live in the separate Copilot model policy management reference.

Understand the policy states before patching

Enterprise baseline and delegation

An enterprise can set default availability to enabled, disabled, or—where organization-based management applies—delegate_to_organizations. Individual model policies can also be delegate_to_teams_and_apps. These settings define the governance hierarchy; they are not all interchangeable.

At the team and app levels, GitHub documents enabled, disabled, and optional. In this context, optional removes the stored team or app policy for that model. It does not mean “the user may choose later.” Always inspect editable and enterprise_policy_state in the response before issuing a write.

Organization behavior

The organization GET endpoint returns the effective policy for every model available to the organization. Organization updates are atomic: if any requested change cannot be applied, none of the changes are saved. GitHub also instructs callers to use the model_name values returned by GET. Inherited enterprise policies may be locked, and default availability cannot be changed when editable is false.

Enterprise teams mode is additive

GitHub currently describes enterprise teams model access as an opt-in preview. In that mode, organization-level model settings are deactivated. A model disabled at enterprise level cannot be enabled by a team; a model enabled at enterprise level remains enabled for all teams; and a user gets the union of the enterprise baseline plus models enabled for every team they belong to.

Operational inference: migrating to teams mode deserves its own change window. GitHub warns that models delegated to organizations become unavailable until they are enabled for specific teams. A direct switch without a team mapping can therefore create an access regression even when no model was intentionally denied.

A safe audit-first workflow

1. Inventory the live response

Use a read-scoped token first. GitHub documents read:enterprise for classic tokens on enterprise GET operations and “Enterprise AI controls” read permission for supported fine-grained GitHub App tokens. Organization endpoints require organization administration permission; check the current reference because SAML authorization and OAuth app restrictions may also apply.

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/enterprises/$ENTERPRISE/copilot/model-policies" \
  | tee copilot-model-policies-before.json

Inspect the response instead of guessing identifiers:

jq '.default_availability,
    (.models[] | {
      model_name,
      display_name,
      policy_state,
      editable,
      enterprise_policy_state
    })' copilot-model-policies-before.json

If you need to share or review the response, run it through Rubic8's JSON Formatter. Validate any hand-edited payload with the JSON Validator before PATCHing.

2. Map retired display names to returned identifiers

Compare the six retired display names with the alternatives in GitHub's final notice. Then locate each approved alternative in the GET response. Store the exact returned model_name; do not derive it by lowercasing or replacing spaces. Model catalogs and identifiers can change independently of your script.

Your inventory should capture at least the administrative scope, display name, returned identifier, current policy state, editability, enterprise policy state, intended owner, and rollback value. This small table becomes both the change plan and the audit record.

3. Patch the smallest possible scope

Once the replacement identifier has been verified, PATCH only the intended scope. The following enterprise example deliberately uses a variable populated from the prior GET response:

MODEL_NAME="replace-with-model_name-from-get"

jq -n --arg model "$MODEL_NAME" \
  '{models:[{model_name:$model,policy_state:"enabled"}]}' \
  > enable-model.json

curl -L -X PATCH \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/enterprises/$ENTERPRISE/copilot/model-policies" \
  --data-binary @enable-model.json

For enterprise writes, GitHub documents admin:enterprise for classic tokens or “Enterprise AI controls” write permission for fine-grained GitHub App tokens. Prefer a short-lived GitHub App token with the narrowest required permission over a broadly scoped personal token.

4. Read after write and compare

A successful HTTP 200 confirms that GitHub accepted the request. It does not by itself prove that every intended user can select the model. GitHub explicitly notes that team and app policy responses are not necessarily the final access decision for an individual user.

Repeat the GET, save an “after” file, and compare only the relevant fields:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/enterprises/$ENTERPRISE/copilot/model-policies" \
  > copilot-model-policies-after.json

diff \
  <(jq -S '.default_availability, .models' copilot-model-policies-before.json) \
  <(jq -S '.default_availability, .models' copilot-model-policies-after.json)

Finally, test with a representative licensed user. GitHub says an enabled alternative should appear in the Copilot Chat model selector in VS Code and on GitHub.com. That human-facing verification catches seat, client, rollout, and inherited-policy issues that the policy response alone cannot settle.

Automation guardrails that prevent policy drift

• GET before every PATCH. Treat model IDs and editability as live data, not constants.
• Use an allowlist. Fail closed if the returned display name or identifier does not match the reviewed change plan.
• Respect editable. Skip locked entries and report the controlling enterprise state.
• Keep payloads small. A focused request is easier to review and roll back than rewriting the whole catalog.
• Save before-and-after responses. Redact tokens; policy JSON itself is useful evidence for change management.
• Handle documented failures. Enterprise endpoints may return 401, 403, 404, 422, or 503. Retry 503 with bounded backoff; do not retry permission or validation errors blindly.
• Pin the API version header. The current examples use 2026-03-10. Review GitHub's versioning policy before changing it.

Roll out without surprising developers

Policy automation is only half of the migration. A developer may have selected a retired model in an IDE, copied it into team instructions, or documented it in an onboarding guide. Even when Copilot falls back gracefully, the behavior a team sees after retirement may no longer match the workflow it tested.

Start with a small cohort that represents your actual client mix: VS Code, GitHub.com, command-line and any IDE extensions your organization supports. Confirm that the approved alternative is visible, selectable, and usable in the relevant Copilot experience. Record the client version and account context with each test result so an access-policy problem is not confused with an outdated client.

For enterprise teams mode, select a pilot team whose membership you can inspect. Because team access is additive, a pilot user who belongs to several enterprise teams may receive a model through a different team and create a false positive. Your validation account should have a membership graph simple enough to explain.

Plan rollback as a policy change

A rollback does not restore a retired model. It restores the previous policy state for the replacement—for example, changing a newly enabled team entry back to optional, or restoring an enterprise model to its earlier delegated state. Keep the before-state beside the approved change ticket and generate the rollback payload before rollout.

Do not use disabled when you mean “remove this team override.” GitHub documents optional as the value that clears a stored team or app policy. At organization scope, the available explicit states are enabled and disabled; an inherited enterprise policy can also make an entry non-editable. These differences are why a generic cross-scope rollback script is risky.

Operational inference: a useful deployment gate is “policy accepted, GET diff matches, and representative user can see the model.” If any of those checks fails, pause expansion. A 200 response is necessary, but the inheritance model means it is not sufficient evidence of end-user access.

What this API does not solve

The policy API controls model availability. It does not migrate prompts, validate extension compatibility, measure answer quality, or select the best replacement for a workload. GitHub's suggested alternatives are migration guidance, not performance guarantees.

Practical recommendation: use GitHub's mapping to restore supported availability, then test your own representative tasks. That may include repository Q&A, inline edits, agent tool calls, code review, and completion latency. Keep those results internal unless you can publish a reproducible methodology; this guide intentionally makes no invented benchmark or search-volume claim.

If your organization also runs agent workflows locally, pair model governance with execution controls. Rubic8's GitHub Copilot local sandboxing guide covers that separate risk surface. For API-side model migrations outside Copilot, see the OpenAI migration checklist and the Gemini 3.8 Flash migration guide; their model identifiers and policies are provider-specific and should not be copied into Copilot configuration.

Recommended migration checklist

1. Export enterprise, organization, team, and app policy responses that apply to your users.
2. Search internal documentation, extensions, instructions, and scripts for the six retired model names.
3. Confirm replacement display names against GitHub's October 19 notice.
4. Resolve each replacement to the live model_name returned by GET.
5. Review delegation mode before changing organization or team policies.
6. PATCH one administrative scope at a time with least-privilege credentials.
7. GET again, diff the result, and retain the audit artifacts.
8. Verify model visibility with representative users in supported Copilot clients.
9. Test real workflows and record any prompt, extension, or agent compatibility changes.
10. Remove temporary write credentials and update the runbook for the next retirement.

Bottom line

The October 19 retirements make Copilot model governance an immediate operational task, while the same day's GA policy API makes that task automatable. The durable pattern is simple: discover live identifiers, understand inheritance, patch the narrowest scope, read after write, and verify from a real client. That approach survives changing model catalogs better than hard-coded migration scripts—and produces an audit trail your security and platform teams can actually use.