GitHub added two related entries to its changelog on October 28.
"Route and orchestrate models with GitHub Copilot Fusion" — multi-model routing and orchestration. "GitHub Copilot Fusion now supports selection of local models" — local model selection support.
These two entries represent different aspects of the same capability. The first asks "how do we route across multiple models?" The second asks "can we also select local models alongside cloud models?"
From Single Model to Multi-Model
Existing GitHub Copilot provides a single model by default. Unless the developer explicitly selects a different model, the system uses one model.
Copilot Fusion is different. It can use multiple models simultaneously or sequentially, orchestrating each model's output.
Existing Copilot: single model
↓
Developer question → Model A response → Result
Copilot Fusion: multi-model
↓
Developer question → Model A (simple task)
→ Model B (complex task)
→ Model C (local model, sensitive code)
→ Orchestration → Integrated result
This diagram illustrates the design concept. The actual Fusion system may not automate all these steps automatically. But it shows the basic concept of multi-model orchestration.
Why Local Model Selection Matters
Local model selection matters from three perspectives.
Cost: cloud model API call costs versus local model execution hardware costs. Data sovereignty: processing sensitive code locally without sending it externally. Latency: immediate local model execution without network round-trip time.
Cloud model A: fast response, high cost, data sent externally
Cloud model B: medium response, medium cost, data sent externally
Local model C: response speed depends on hardware, free API cost, data stays internal
↓
Fusion: selects model by context
This diagram illustrates the design concept. Actual costs and performance depend on hardware specifications, model size, and network conditions.
SDK Rebranding: "GitHub Copilot SDK → Microsoft Copilot SDK"
The same October 28 changelog also includes "GitHub Copilot SDK is becoming Microsoft Copilot SDK." This is not a simple name change.
The coding tools SDK from GitHub is expanding to Microsoft as a whole. Copilot is no longer a GitHub-only feature, but a platform across the Microsoft ecosystem.
This rebranding and Copilot Fusion point in the same direction. Beyond model selection, the core is the structure that manages execution environment, tools, permissions, and cost policies.
Questions for Practicing Developers
This feature may not directly impact your project today. But the following questions are worth preparing for.
Given the same model, can you compare harness-level success rates and costs? Among the multiple models Copilot Fusion provides, which model is most efficient for the same task?
Where is the boundary between local and cloud models? Which code should be processed locally, and which code is better suited for cloud models? You need to establish criteria.
How do you manage execution environment, tools, permissions, and cost policies? The execution layer matters more than model selection. Check the execution environment controls that Fusion provides.
Conclusion
GitHub Copilot Fusion marks the transition from single-model coding assistant to multi-model orchestration. Local model selection gives developers a balance between cost, data sovereignty, and latency.
But the core is not the model itself — it's the execution layer. "Which environment, tools, permissions, and cost policy govern the execution" matters more than "which model do you use."
There are three actions developers can take today.
- Compare harness-level success rates and costs given the same model.
- Establish the boundary between local and cloud models.
- Check the structure that manages execution environment, tools, permissions, and cost policies.
The model competition has already begun. But the competition after the model — the competition of the execution layer — has just begun.