GitHub moved Copilot Business and Enterprise to GPT-5.3-Codex and paired the change with a 12-month LTS window through February 4, 2027.
What Changed for Copilot Business and Enterprise
GitHub has set GPT-5.3-Codex as the default model behind Copilot for its Business and Enterprise plans. Rather than leaving the underlying model as a moving target, GitHub is treating this version as a stable base that organizations can build their workflows around. For teams, the practical effect is that the code completions, chat responses, and agentic behaviors they rely on now trace back to one named, documented version instead of whatever happened to be current that week.
The other half of the announcement is a long-term support window: GitHub is committing to keep this model available for twelve months, through February 4, 2027. That combination — a specific base model plus a fixed support horizon — is aimed squarely at organizations that need to know what they are deploying and for how long.
Why the LTS Window Matters
Model changes are not free for large teams. A new default can shift how completions are phrased, how the assistant handles ambiguous prompts, or how it structures multi-step tasks. When those behaviors drift unannounced, prompt templates, internal guidelines, and review expectations can quietly fall out of sync. A 12-month LTS window turns the model into something closer to a versioned dependency: a known quantity you can test against, document, and schedule upgrades around.
For regulated or security-conscious environments, this predictability is the point. Teams can validate the model against their own code review standards, capture its behavior in internal runbooks, and plan any migration well before the support window closes rather than reacting to a surprise cutover.
How Teams Should Prepare
Treat the LTS window as a planning horizon, not an excuse to defer everything to the last month. The gap between now and February 4, 2027 is enough time to standardize how your organization uses Copilot and to establish a baseline you can compare future models against.
- Document the current default model in your engineering guidelines so everyone knows which version they are working with.
- Capture a set of representative prompts and expected outputs to serve as a regression baseline when the next model arrives.
- Review your Business or Enterprise settings to confirm the base model and any policy controls match your compliance requirements.
- Put a reminder on the calendar ahead of the support window closing so upgrade testing starts early, not under pressure.
Reading the Signal Behind the Move
Pairing a specific model with an explicit support commitment reflects how AI tooling is maturing inside the enterprise. Early adoption often meant accepting that the assistant would change underneath you; naming a base version and attaching a support timeline reframes the assistant as infrastructure that can be governed like any other dependency. That is a meaningful shift for platform and security teams who are accountable for what runs in their build and review pipelines.
The near-term takeaway is straightforward: know which model your organization is on, use the support window to build repeatable practices around it, and plan the eventual transition deliberately. The stability GitHub is offering is only useful if teams take advantage of it to standardize now, while the base is fixed and the timeline is clear.