GitHub's Default Model Enablement — The Policy Window Just Closed

GitHub’s default model enablement policy — announced July 29 with a 28-day grace period — takes effect today, August 26. Any Copilot Business or Enterprise organization that hasn’t explicitly configured its model allowlist now auto-inherits whatever GitHub considers the default roster. The timing is not accidental: Grok 4.6 landed in Copilot on August 14, sixteen days into the grace period, making this the first significant model addition to arrive while the governance rules were actively shifting underneath enterprise admins.

TL;DR

• What: GitHub’s 28-day grace period for default model enablement expires today — unconfigured orgs now auto-inherit GitHub’s model defaults
• Grok 4.6: Arrived in Copilot August 14 across 8 surfaces, priced at $2/$6 per million tokens, but requires explicit admin opt-in for Business/Enterprise
• The real risk: Most enterprise admins missed the July 29 policy change, and tomorrow they’ll discover their model roster shifted without a deliberate decision
• Action: Check your Copilot org settings today — not tomorrow

GitHub’s Default Model Enablement — What Happened

On July 29, GitHub published a changelog entry that most enterprise admins probably skimmed past: starting August 26, all GA models in Copilot would become available by default to Business and Enterprise organizations. The old behavior — new models require explicit admin approval — was being inverted. Unless you actively set models to “disabled” within the 28-day window, you opted in by inaction.

That window closes today.

The policy carves out open-weight models and those without GitHub data retention agreements — they won’t be automatically enabled. But for closed, commercially licensed models with retention agreements in place, the default flips to “on.” This is a meaningful governance shift. Previously, enterprise admins operated in a whitelist paradigm: nothing new appears until you approve it. Now they’re in a blacklist paradigm: everything new appears unless you block it.

Two weeks into this grace period, on August 14, xAI’s Grok 4.6 arrived in GitHub Copilot. The model is available across all eight Copilot surfaces — VS Code, Visual Studio, Copilot CLI, the cloud agent, the Copilot app, JetBrains IDEs, Xcode, and Eclipse. For Enterprise and Business plans specifically, Grok 4.6 requires manual admin enablement — it ships with the policy toggled off. That’s a separate gate from the broader default enablement mechanism, and the distinction matters: Grok 4.6 today requires opt-in, but the infrastructure for future models to appear without admin action is now live.

The Grok 4.6 opt-in gate and the default enablement policy are two separate mechanisms. Grok 4.6 currently requires explicit admin approval. But the broader policy means the next GA model that lands in Copilot may not — unless your org has configured its allowlist.

Why This Matters

The story here isn’t really about Grok 4.6. It’s about GitHub quietly changing the governance model for Copilot’s model roster while simultaneously onboarding the most aggressively priced frontier model in the ecosystem.

Grok 4.6 bills at $2 per million input tokens and $6 per million output tokens. That’s a fraction of what other frontier models charge through Copilot, and for organizations tracking AI credit consumption, the pricing alone makes it interesting. The model brings a 500,000 token context window and four configurable reasoning levels — low, medium, high, and xhigh — with explicit optimization for multi-step agentic tasks. The fact that one of the eight enabled surfaces is Copilot’s cloud agent is not decorative: xAI is positioning Grok 4.6 for long-running autonomous workflows, not just autocomplete.

But the governance angle is what enterprise teams should actually be sweating about. Compare how model onboarding used to work versus how it works after today. Before July 29, adding a new model to your org’s Copilot was a deliberate, auditable decision. An admin reviewed the model, enabled it, and the change showed up in logs. After today, models arrive by default unless someone actively prevents it. The compliance implications are obvious: if your org has data residency requirements, model-specific risk assessments, or simply a policy that says “we evaluate before we adopt,” the default enablement mechanism undermines all of that — silently.

I’d wager most enterprise admins missed the July 29 changelog. It wasn’t a blog post with a splash graphic. It was a changelog entry — the kind of update that lands in an RSS feed, gets glanced at, and gets buried under fourteen other notifications. The 28-day grace period was generous by GitHub’s standards, but it assumed admins were paying attention to a policy change that arrived during peak summer vacation season.

Check your org’s Copilot model settings now: Organization Settings → Copilot → Policies → Model availability. GitHub’s official documentation on default model availability walks through the configuration. If you haven’t touched this since before July 29, your defaults may have shifted. Setting models to “disabled” after the grace period still works — but you’re now reacting instead of preventing.

The distribution speed is worth noting separately. xAI released Grok 4.6 on August 12. Two days later, on August 14, it was live across all eight Copilot surfaces. That’s not normal vendor onboarding velocity — it suggests pre-negotiated integration work that was ready to ship the moment the model went public. When a model provider can go from public release to full Copilot availability in 48 hours, the “we’ll review new models as they appear” approach to governance becomes untenable. Models will appear faster than review cycles can process them.

This is the pattern that the Copilot credits billing shock story hinted at: GitHub is building a multi-model marketplace inside Copilot, and the economics and governance rules are evolving faster than most organizations’ procurement processes. The MAI Code 1.1 Flash admin gate was another data point — each new model addition tests whether enterprise controls are keeping pace. With default enablement now active, the answer for most orgs is: they aren’t.

The Take

The real exposure isn’t Grok 4.6. It’s that GitHub shifted from a whitelist to a blacklist governance model for Copilot, and most enterprise admins will discover this tomorrow — not today. The 28-day grace period was technically sufficient but practically invisible. A changelog entry during summer, with no email notification to org admins, no banner in the admin console, and no forced acknowledgment before the policy took effect.

I think GitHub made the right product decision — defaulting to availability reduces friction and lets developers access the best models faster. But they made a poor governance decision by not forcing admin awareness. A modal dialog in the admin console saying “your model defaults are changing on August 26 — review now” would have cost nothing and prevented the exact scenario that’s about to play out: admins discovering policy changes after the fact.

If you’re an enterprise Copilot admin reading this today: go check your model settings. Not because Grok 4.6 is dangerous — it’s gated behind its own opt-in — but because the mechanism that will deliver the next model is now live, and you need to decide whether your org operates on GitHub’s defaults or your own. That decision should be deliberate. After today, for a lot of orgs, it wasn’t.