Unconfigured stops meaning off on October 22

On Thursday GitHub added a dropdown to the Copilot admin settings of every organization and enterprise on a Business or Enterprise plan. For 28 days it does nothing at all. On October 22 it starts deciding, on your behalf, whether the Copilot features nobody at your company has ever made a decision about are switched on for your whole team.

The changelog announcing it lists the three values you can choose and does not tell you which one you already have. The documentation does. From GitHub's page on default availability of Copilot features and models: "This policy is enabled by default. If you don't take action, unconfigured features will be enabled on October 22."

That is the piece. Everything else here is what is in scope, what "on" spends, and how to pick a value in about fifteen minutes.

Who this is and is not about

If your company pays for GitHub Copilot Business at $19 per granted seat per month, or Copilot Enterprise at $39, somebody at your company owns this decision. If nobody is sure who that is, it is whoever can open the organization's settings page, which in a shop under fifty people is usually the owner, the one technical hire, or an ops lead who inherited the admin account from somebody who left.

If you are on Copilot Pro, Pro+, Max or Free as an individual, this does not touch you; the plans page puts organization-wide policy management in the Business and Enterprise columns only. If you have no GitHub organization at all, skip this one.

There is a real case for reading it anyway if you run an agency and your client work lives in a GitHub org you administer. The features in scope include things that read repository contents and post into pull requests. Whose code that is, and what you told the client about who touches it, is a question the dropdown answers for you if you leave it alone.

What counts as a "feature"

This is narrower than "everything in Copilot" and wider than it sounds. Per the docs, the policy governs every policy on the enterprise "Features & clients" page, plus two specific ones that live elsewhere: the Copilot code review policy on the Agents page, and the MCP servers in Copilot policy on the MCP page.

It applies to three categories:

• New features that ship as generally available
• Features that graduate from preview to generally available
• Existing generally available features currently sitting on Unconfigured in your settings

Three things are explicitly out of scope. Preview features stay opt-in. Explicit decisions are preserved, so anything you have already deliberately switched on or off is never touched. And a short exception list is unaffected regardless of what you pick: the two restrictive model policies on GHE.com, and "Store local sessions in the Cloud" for Copilot CLI and VS Code.

The preview carve-out deserves a second read, because it is the part most likely to be misremembered as a guarantee. A preview you opted into keeps your choice when it goes generally available. A preview you never touched, once it goes generally available, becomes an eligible feature and follows your default. Third-party coding agents are the obvious live example. GitHub's plans page lists third-party agents as public preview today, and the organization policy docs describe what enabling one does: Anthropic Claude and OpenAI Codex "have access to the same repositories that Copilot cloud agent has been enabled in." That is a preview, so it is not in scope this month. It is not a preview forever.

There is also a layer above you if your organization belongs to an enterprise account. Enterprise-level policy wins; an organization owner cannot override a decision an enterprise owner has made. The new default reflects that, and it is worth understanding because it changes what your own dropdown means. At the enterprise level the policy applies to features marked Unconfigured. At the organization level it applies only to features the enterprise owner set to "Let organizations decide" and the organization owner then never configured. If your org sits under an enterprise you do not control, your real question is what that enterprise picked, not what you picked.

The docs describe the organization case in terms of delegation from an enterprise and do not spell out the behaviour for a standalone organization with no enterprise account above it, which is the common shape for a small company. That is a gap in the published documentation rather than a reason to assume either way, and the check below resolves it in about a minute: GitHub says the policy settings show a banner counting how many eligible policies are currently unconfigured, so the banner tells you whether you have skin in this.

This already happened once, in August

The feature policy is the second run of this mechanism, not the first, and that is the most useful fact available to you today.

On July 29 GitHub announced the same thing for models: a global default enablement policy, configurable for 28 days with no effect, taking effect on August 26. Models you had not explicitly configured were relabelled from "unconfigured" to a live state that tracks the policy, and if the policy was enabled, which was the default, those models became available to your users. It is active now. The supported models reference shows the label as "Delegate to Default Policy", and a handful of exclusions that stay off regardless: pre-GA models, open-weight models including DeepSeek and Kimi K3, and models not covered by GitHub's data retention agreement, currently Claude Fable 5 and 5.1.

So go and look at your model settings before you touch anything else. If most of them say "Delegate to Default Policy" and the policy says enabled, and nobody at your company remembers deciding that, you have just learned something more valuable than the October 22 date. You have learned that nobody there is reading the GitHub changelog, which means the feature policy will land exactly the same way, and so will the third one when it comes.

If instead you find deliberate choices in that list, somebody is paying attention, and the rest of this is a fifteen-minute confirmation rather than a fire.

What "on" spends

Governance is the obvious lens on this, and it is not the only one. Copilot Business and Enterprise bill usage in AI credits, and GitHub's billing documentation is unusually direct about the arithmetic: one AI credit is one cent.

Each Business seat brings 1,900 credits a month and each Enterprise seat 3,900, and the credits are pooled at the billing entity rather than held per person. GitHub's own worked example is that 100 Business users share 190,000 credits instead of holding 1,900 each. Credits do not roll over; the pool resets at 00:00 UTC on the first of the month and anything unused is gone.

What draws on the pool is any Copilot feature that calls a model. The docs name Copilot Chat, Copilot CLI, Copilot cloud agent, Copilot Spaces, Spark and third-party coding agents, and GitHub's plan comparison also lists code review among the features that consume credits. Code completions and next edit suggestions are not billed at all and stay unlimited on every paid plan.

Put those two paragraphs next to each other and the cost shape of October 22 is clear enough. A feature that switches itself on across an organization is not free just because you already bought the seats. Copilot code review is explicitly in scope for the new policy, and a review that runs on every pull request in every repository draws from the same shared pool your chat and agent usage draws from. I have not measured what a review costs in credits and will not guess at a number; the point is the direction, which is down.

Then there is the other default sitting on the same settings page, and this one is already live. From the billing docs: "Additional usage is enabled by default for organizations and enterprises." When the pooled credits run out, spend continues at published rates and lands on your bill unless an administrator has explicitly disabled the AI credits paid usage policy. There is no automatic fallback to a cheaper model when a budget is exhausted, either; the user is simply blocked.

That combination is the thing to hold in your head while you are on the page. One default decides how much of the product is switched on. A different default decides whether running out of the included allowance stops the spending or just starts billing you for it.

The three values, and the honest case for each

GitHub's wording, verbatim from the changelog:

• Enabled: current and future eligible features will be available to users by default.
• Disabled: current eligible features will remain unavailable, and future eligible features will require administrator approval.
• Let organizations decide: organization administrators can choose whether to enable or disable eligible features.

Enabled is defensible and it is what you have. Your team gets new capability the week it ships without waiting on an admin who is busy. For a shop where the people using Copilot are the same people who would have approved the feature, the approval step is paperwork with no reviewer. The cost is that your tool's surface area changes without a decision, and some of that surface reads your repositories and spends your credits.

Disabled reads like the cautious answer and has a cost people underestimate. It means every future generally available feature needs somebody to notice it exists and go turn it on. In a small company nobody is watching, so what you have actually chosen is a Copilot that quietly falls behind the one your team's peers are using, and a team that starts doing the work in a personal account instead because the paid one cannot do the thing they read about. Friction does not remove the demand.

Let organizations decide is the middle and the honest thing to say about it is that it moves the same unattended decision down one level. It is genuinely right when your organizations differ in what they are allowed to do, a regulated client org next to an internal tools org. It is theatre when you have one organization and one admin, because the decision arrives at the same desk with an extra hop.

If you have one organization, one admin, and code you would not want an unreviewed feature reading, the workable answer is not the dropdown at all. Keep the global default enabled so you are not fighting your own tooling, then explicitly configure the small number of policies whose behaviour you actually care about: code review, MCP servers, and anything that reaches a repository. Explicit choices are preserved forever, so each one you make is a decision the next changelog cannot reverse. The dropdown then governs only the long tail you genuinely have no opinion about.

The pass to make before October 22

GitHub's docs put the enterprise path at the enterprise's AI controls page, with Copilot, Agents and MCP as separate sidebar sections, and the organization path at Settings, then Copilot under "Code, planning, and automation". Twenty minutes, once:

1. Open the policy settings and read the banner that counts your unconfigured eligible policies. That number is the size of the October 22 decision. If it is zero, you are done.
2. Read the model settings for "Delegate to Default Policy" labels, and note whether the state you find is a choice anybody remembers making.
3. Explicitly set Copilot code review and MCP servers in Copilot rather than leaving either to the default, whichever way you set them.
4. Check the AI credits paid usage policy, which is on by default, and decide whether you want overage to bill or to block.
5. Set the global default last, once you know what is left underneath it.

One honest limitation on all of the above: I have read GitHub's changelog and documentation, not your settings page, and the exact labels differ between the enterprise and organization views. Take the paths as the docs' description of them and the banner as the authority on your own exposure.

What you actually own now

The mechanism GitHub has built here is reasonable and it is also a transfer. It moves the default answer on "should this be on" from no to yes, for a class of features that is going to keep growing, at a company where the person who would have said no is not reading the changelog.

You cannot opt out of that transfer by ignoring it, because ignoring it is the input that produces enabled. What you can do is spend twenty minutes converting the handful of policies you have an opinion about into explicit choices, which are the only kind GitHub promises not to touch, and then let the default govern the rest on purpose instead of by default. The date is October 22. The models version of this already went through in August, which is the best available evidence for whether anyone where you work would have noticed.