How to Choose the Best Model in GitHub Copilot
There is no best model, and an article that named one would be wrong within a month — either because the model retired or because a better one arrived.
What survives is a method: a small set of questions about the task in front of you that narrow 32 options down to a category, and a default for when none of them applies.
Key takeaways
- Start with auto. It is available on every plan, routes on task complexity and model availability, and carries a 10% discount on paid plans.
- Choose manually when you know something auto has to infer — usually that a task needs sustained reasoning.
- The decision is about task shape, not about which model is generally better.
- On Free and Student, there is no decision: models are reachable only through auto.
- Model choice is the smallest of the five levers. If output is disappointing, check context and instructions first.
Start with the default
Auto is a genuinely good default, and saying so up front will save most readers the rest of this lesson.
It combines real-time model health with an assessment of task complexity, routes accordingly, and respects administrator policy. On a paid plan it costs 10% less than selecting the same model manually. And it absorbs churn: a session on auto keeps working through a retirement that would have broken a pinned choice.
Manual selection earns its place when you know something auto must infer. That is a real scenario and a narrower one than the volume of online discussion suggests.
The decision
Four questions, in the order that is worth asking them.
Is the answer in doubt?
If not — boilerplate, a format conversion, a syntax reminder — the cost is waiting, not accuracy. A fast model is the right answer, and a reasoning model is actively worse because you pay latency for judgement the task does not need.
Optimised for speed and responsiveness. GitHub suggests them for quick edits, utility functions, syntax help and lightweight prototyping.
| Model | Provider | Status | GitHub groups it under |
|---|---|---|---|
| GPT-5.6 Luna | OpenAI | GA | Fast help with simple or repetitive tasks |
| Claude Haiku 4.5 | Anthropic | GA | Fast help with simple or repetitive tasks |
| MAI-Code-1-Flash | Microsoft | GA | General-purpose coding and writing; Fast help with simple or repetitive tasksRetires 2026-09-10 |
Does it require holding several things at once?
This is the question that most often justifies manual selection. Debugging that spans three modules, a race condition, an architectural trade-off with real constraints, a refactor whose correctness depends on facts scattered across the codebase.
The signal is not difficulty; it is interaction. A hard problem with one moving part is fine on a general model. An easy-sounding problem where four things interact is where reasoning depth shows, and it is also where a weaker model produces its most confident wrong answers — because each part looks tractable in isolation.
For tasks that require step-by-step reasoning, complex decision-making, or high-context awareness.
| Model | Provider | Status | GitHub groups it under |
|---|---|---|---|
| GPT-5 mini | OpenAI | GA | General-purpose coding and writing; Deep reasoning and debugging; Working with visuals |
| GPT-5.5 | OpenAI | GA | Deep reasoning and debugging |
| GPT-5.6 Sol | OpenAI | GA | Deep reasoning and debugging |
| Claude Opus 4.7 | Anthropic | GA | Deep reasoning and debugging |
| Claude Sonnet 4.6 | Anthropic | GA | Deep reasoning and debugging; Working with visualsRetires 2026-09-01 |
| Gemini 3.1 Pro | Public preview | Deep reasoning and debugging; Working with visualsRetires 2026-09-01 |
Is part of the question visual?
A screenshot of a broken layout, a diagram of an intended architecture, a rendered chart that looks wrong. If so, the model needs multimodal input and most do not have it.
For questions about screenshots, diagrams, UI components or other visual input. These models support multimodal input.
| Model | Provider | Status | GitHub groups it under |
|---|---|---|---|
| GPT-5 mini | OpenAI | GA | General-purpose coding and writing; Deep reasoning and debugging; Working with visuals |
| Claude Sonnet 4.6 | Anthropic | GA | Deep reasoning and debugging; Working with visualsRetires 2026-09-01 |
| Gemini 3.1 Pro | Public preview | Deep reasoning and debugging; Working with visualsRetires 2026-09-01 |
Otherwise
General-purpose, or auto. GitHub’s phrase for this group is a “balanced all-round choice for everyday interactive and agentic coding”, and most work lives here.
GitHub's description: common development tasks needing a balance of quality, speed and cost efficiency, and a good default when you have no specific requirement.
| Model | Provider | Status | GitHub groups it under |
|---|---|---|---|
| GPT-5 mini | OpenAI | GA | General-purpose coding and writing; Deep reasoning and debugging; Working with visuals |
| GPT-5.3-Codex | OpenAI | GA | General-purpose coding and writing |
| GPT-5.6 Terra | OpenAI | GA | General-purpose coding and writing |
| MAI-Code-1-Flash | Microsoft | GA | General-purpose coding and writing; Fast help with simple or repetitive tasksRetires 2026-09-10 |
| Raptor mini | Fine-tuned GPT-5 mini | GA | General-purpose coding and writingRetires 2026-09-01 |
A note on the fourth question
Large-repository analysis is the case where the framework’s advice is counter-intuitive, so it is worth separating out.
The instinct is that a big codebase calls for a big context window. Sometimes it does. More often the better move is to supply less: three relevant files rather than thirty, the specific error rather than the whole log. A model given a focused set of evidence outperforms the same model given everything, because attention across a long context is uneven regardless of the advertised capacity.
Where capacity genuinely matters is a long agentic session, where history and tool output accumulate whether you meant them to or not. There, running out is a real failure mode and the symptom is distinctive: constraints followed early in the session start being ignored later.
So the fourth question is better phrased as “will this session accumulate a lot of context?” than “is this repository large?”. The first is about how you will work; the second is about a number that rarely decides anything.
Task by task
Applying the framework to the work people actually do.
Explaining code. Fast, or general-purpose. Explanation is a strength across the board and rarely the place to spend on reasoning depth.
Generating boilerplate. Fast. The answer is not in doubt, so waiting is the only cost.
Writing tests. General, mostly. Reasoning helps when the interesting part is working out which cases matter rather than writing them.
Debugging something simple. General. A stack trace pointing at one function does not need sustained reasoning.
Debugging something that spans modules. Reasoning. This is the clearest case for manual selection in the whole cluster.
Refactoring. Depends entirely on scope. Extracting a function is general; restructuring a module whose behaviour must not change is reasoning.
Architecture and design. Reasoning, and ask for the case against as well as the recommendation.
Code review. General for a small diff. Reasoning for anything where correctness depends on interactions. Note that code review is billed at a flat rate regardless of model, which removes cost from this particular decision.
Large repository analysis. Context handling matters most. Reducing what you supply usually beats reaching for a bigger window — see context engineering.
Agentic work. General or reasoning depending on the task, and consider that an agentic session accumulates context whether you intended it or not, so capacity matters more than in chat.
Shell and infrastructure. General. The failure mode here is missing environment knowledge rather than insufficient reasoning, and no model choice fixes that — an instruction file naming your distribution, package manager and init system does. Cluster 5’s Linux lesson makes the same point from the other direction.
How auto decides, and where that leaves you
Understanding auto’s inputs clarifies when it is likely to be right and when your own knowledge beats it.
Auto combines two signals: real-time model health and availability, and an assessment of task complexity. The first is information you do not have — you cannot see which models are rate-limited or degraded at this moment, and auto can. The second is an inference from your request.
That split tells you exactly where manual selection wins. Auto is strictly better at availability, because that is live operational data. You are sometimes better at complexity, because you know things about the task that your prompt does not say.
The typical case: you are about to debug something you already know spans several modules and involves a race condition, but your opening prompt is “why does this test fail intermittently?” — which does not look complex. You know it is; auto has to guess.
The inverse also happens. A prompt that reads as complex — long, detailed, many constraints — may be a mechanical task with a lot of specification, and auto may route it more expensively than needed.
Cost as a factor
Model choice has a billing dimension, and it deserves proportionate rather than obsessive attention.
Premium requests are deducted by a per-model multiplier, so a reasoning model consumes more allowance than a fast one. Only your prompts count — the agent’s own tool calls do not, so a single prompt driving twenty tool calls is one request.
Three practical consequences.
Auto is cheaper on paid plans, by a documented 10%, which is a reason to treat it as the default rather than a fallback.
Reasoning models are worth their cost when the task needs them and are simply waste when it does not. That is the entire cost argument, and it is the same argument as the quality one.
Code review is flat-rate, which removes cost from that particular decision entirely.
For anyone who finds themselves running low, the useful audit is not “which model am I using” but “how many of my requests are ones I could have avoided” — a better prompt that gets it right first time costs one request, and three rounds of correction cost three.
Choosing for a team
Individual model choice is a preference. Team-level model policy is a different question, and it comes up once an organization is paying attention to spend.
Do not mandate a specific model. It will retire, and the mandate will outlive it. Mandate a default posture instead — “use auto unless you have a reason” — and let people exercise judgement on the exceptions.
Do communicate administrator restrictions. If your organization has limited the available models, say so and say why. Developers who do not know about a restriction will spend time trying to select something that is not there, and will conclude the tool is broken.
Do not build model names into shared configuration unless you are willing to maintain them. A prompt file pinning a model, a workflow specifying one, a runbook naming one — each becomes an edit when that model retires, and the expensive part is finding them all.
Do talk about task shape rather than model names when helping a colleague. “I use X” ages badly; “for cross-module debugging, reach for a reasoning model” does not.
What not to choose on
Provider loyalty. No provider is uniformly ahead, and the leader on any given dimension moves.
Recency alone. A newer version number within a family usually indicates improvement. Across families it means nothing.
Benchmark scores from third parties. They measure self-contained puzzles, not your codebase with your conventions and your half-finished migration. And what reaches you through Copilot is not the raw model.
What worked for someone else. Different codebase, different task shape, different instruction files.
Checking your choice was right
The honest test is whether the output improved, and it is worth running deliberately once rather than assuming.
Same task, same context, two models. Any variation in input makes the comparison meaningless. Same prompt, same files, same instructions in force.
Judge on what you care about. Did it find the real cause? Stay in scope? Notice the constraint you did not state? Was it fast enough to be worth it?
Run it more than once. These systems are non-deterministic. One good answer is a sample of one.
The result is frequently that the difference is smaller than expected — which is useful information, because it means the time is better spent on the levers that matter more.
Switching mid-task
Model choice is not a decision you make once and live with. Switching partway through is normal and occasionally the right move.
Start fast, escalate on difficulty. A reasonable pattern for debugging: begin on a general or fast model, and if two exchanges produce shallow or circular answers, switch to a reasoning model and restate the problem. You have lost two cheap requests and gained information about what kind of problem it is.
Start with reasoning, drop down for execution. The inverse suits design work: use a reasoning model to agree an approach, then a faster one to implement it, since implementation of an agreed plan is mechanical.
Switch when the conversation changes shape. A session that began as “explain this” and became “now fix it across four files” has changed category, and the model that was right for the first half may not be right for the second.
In the CLI, /model changes the model for the session. In IDE chat, the selector
is in the chat interface. The mechanics are simple; the habit worth building is
noticing that the task has changed rather than persisting with a choice made when
the task looked different.
Common mistakes
Choosing before understanding the task. The framework above needs a task shape as input. If you do not yet know whether the problem is a one-line oversight or a cross-module interaction, start on auto and find out.
Treating a capable model as insurance. A reasoning model on a mechanical task is slower, more expensive, and no more correct. It is not a safety margin.
Assuming the model is why generated code is wrong. Usually it is missing context or an unstated constraint. Both are cheaper to fix and fix the problem permanently rather than for one request.
Chasing releases. A new model is an option, not an obligation. The cost of evaluating every release exceeds the benefit for almost everyone.
Never revisiting. The opposite failure. A choice made a year ago, encoded in a prompt file, still being used because nobody looked. Retirement announcements are the natural prompt to review.
When model choice is not the problem
Worth stating plainly, because reaching for the model selector is the most common first move and usually the wrong one.
A more capable model cannot see a file you did not mention. It cannot know a convention you never wrote down. It cannot verify its own output. If any of those is the actual problem, changing models produces a differently-worded version of the same disappointment.
The diagnostic order that works: did it see the right context, were the constraints stated, are the instructions in force, then is the model a poor fit.
Why this article does not name a winner
Search engines are full of pages titled “the best Copilot model”, and most of them are a snapshot of one person’s preference at one moment, presented as a finding.
Three reasons this page refuses to join them.
The list changes. Models retire on announced dates and new ones arrive between them. A recommendation written today has an expiry date it does not carry.
“Best” is not a property of a model. It is a property of a model-task pair. The fast model that is wrong for cross-module debugging is right for the twenty boilerplate requests you will make this afternoon, and a page that names one winner is wrong about most of your day.
The measurement does not exist. GitHub publishes task groupings, not scores. Any ranking is either citing a third-party benchmark measuring something narrower than your work, or it is an opinion in a table.
What is durable is the method: work out the shape of the task, match it to a capability, and default to auto when nothing about the task argues for a specific choice. That framework will still be correct when every model name in this cluster has been retired.
Next
Model comparison is the current factual matrix — providers, status, task grouping and retirement. Models explained covers the concepts underneath this framework.
For the levers that matter more, context and instructions are where most disappointing output is genuinely fixed.
Sources
Every version-sensitive claim on this page was checked against first-party documentation. Only sources actually used are listed.
Your progress
Saved in this browser only. No account, no server, and nothing leaves your device. Clearing site data resets it.Sync across devices if you want it everywhere.
Saved in this browser and synced to your account, so it follows you between devices. Manage or delete it.
Was this lesson helpful?
We record which lesson you rated and whether it helped. Nothing identifies you — no account, no cookie, no session.