GitHub is making another model-picker change that enterprise Copilot administrators should treat as an operating-policy update, not just a new option in a dropdown.
The company says Gemini 3.8 Flash is now available in GitHub Copilot, with gradual rollout across Visual Studio Code, Visual Studio, Copilot CLI, Copilot cloud agent, the Copilot app, JetBrains IDEs, Xcode, and Eclipse. In a separate September 3 changelog post, GitHub said several older Copilot models will be deprecated across all Copilot experiences on October 2, 2026.
Together, the posts show how quickly AI coding environments are becoming managed model portfolios. New models arrive, older ones leave, provider pricing changes, and enterprise administrators have to keep access policies aligned with how teams actually work.
Gemini 3.8 Flash enters Copilot’s coding surface
GitHub says Gemini 3.8 Flash is Google’s latest Flash model and performed strongly in early GitHub testing on complex terminal-based coding tasks. The model is available to Copilot Pro, Pro+, Max, Business, and Enterprise users, though rollout is gradual.
The supported-surface list is broad. Gemini 3.8 Flash is not being limited to a single editor integration. GitHub says it will appear in IDEs, the CLI, the Copilot cloud agent, and the Copilot app. That matters because enterprise developers increasingly move between local editing, terminal workflows, web agents, and background coding sessions.
GitHub also says Gemini 3.8 Flash is billed at introductory provider pricing under usage-based billing through December 31, 2026. For teams already managing Copilot budgets, that makes model selection both a capability and cost-control question.
Four older models now have an October deadline
GitHub’s deprecation post lists four models scheduled to be removed across all Copilot experiences on October 2, 2026: Gemini 3.5 Flash, Gemini 3.6 Flash, Kimi K2.7 Code, and Claude Opus 4.7. GitHub suggests Gemini 3.8 Flash, Kimi K3, and Claude Opus 5 as alternatives depending on the outgoing model.
No action is required to remove the deprecated models after the deadline, but that is not the same as saying no action is required for engineering teams. Workflows, documentation, saved prompts, internal training, evaluation baselines, and automation assumptions may all refer to a model that disappears from Copilot surfaces.
For Copilot Business and Enterprise customers, administrators may also need to enable access to replacement models through Copilot model policies. That detail matters because a suggested alternative is only useful if the enterprise policy allows teams to select it.
Copilot model governance is becoming routine infrastructure
This update lands one day after GitHub added enterprise-managed default model settings and made content exclusions generally available in the Copilot app and CLI. The pattern is getting clearer: Copilot is adding more agentic surfaces, and model governance is becoming a regular administrative responsibility.
That governance work is not glamorous. It means knowing which models are permitted, which teams have different defaults, which excluded files are honored across each Copilot surface, what usage-based billing exposure exists, and when model retirements will break internal guidance.
The enterprises that handle this well will treat Copilot model configuration like production infrastructure. They will keep policy owners, evaluate replacement models before deadlines, and publish migration notes before developers find out through a missing model selector.
