GitHub Copilot Models Explained

GitHub Copilot Models ExplainedPrompting, Models & Customization8Intermediate/github-copilot/customization/models/

GitHub Copilot currently offers 32 models from 7 providers. That is a lot of choice for a tool most people use by typing a question into a box, and the natural reaction — which one is best? — has no answer.

This lesson covers what a model actually changes, what the categories mean, and the operational facts around them: auto selection, plans, credits and retirement.

Key takeaways

• 32 models, 7 providers: OpenAI, Anthropic, Google, Microsoft, Fine-tuned GPT-5 mini, Moonshot AI, xAI.
• GitHub groups models by task area — general-purpose, fast, deep reasoning, visual — rather than ranking them. Neither does this site.
• Auto selection is available on every plan. On Free and Student, models are reachable only through auto.
• Paid plans get a documented 10% discount on model cost while using auto.
• Premium requests are multiplier-based, and only your prompts count — the agent’s own tool calls do not.
• Models retire on announced dates. 7 currently have one.

Why there are so many

Three forces are at work, and understanding them explains the shape of the list far better than memorising the names on it.

Different tasks want different things. Explaining a function and debugging a concurrency bug are not the same computational problem. One wants speed; the other wants sustained multi-step reasoning. A single model tuned for both is worse at each than two models tuned for one.

Cost scales with capability. Reasoning-heavy models cost more per request. Routing everything to the most capable available model would be wasteful for the large fraction of requests that are simple — and on a team, that waste compounds into a real number rather than a rounding error.

No provider is uniformly ahead. GitHub sources from OpenAI, Anthropic, Google, Microsoft, Fine-tuned GPT-5 mini, Moonshot AI, xAI, which is a hedge against any single provider’s availability, pricing or capability changing. It also means the leader on any given dimension moves, which is a further argument against building habits around one name.

What actually differs

Four dimensions matter in practice.

Reasoning depth. How well a model holds several constraints at once and works through consequences. This is what separates “explain this function” from “work out why this fails only under load”.

Speed. Latency to first token and overall. For an interactive completion, slow is worse than slightly less accurate.

Context handling. How much a model can consider and how well it uses the far end of it. All models degrade as context fills; they degrade differently.

Multimodality. Whether a diagram, screenshot or rendered output can be part of the question.

Notably absent from that list: “coding ability” as a single number. It is not published, it is not measured consistently across providers, and a table purporting to give it would be an opinion formatted as data. The four dimensions above are real and they trade off against each other, which is precisely why a single ranking cannot exist — a model that wins on speed loses on reasoning depth, by construction.

GitHub’s task groupings

Rather than ranking, GitHub places models into task areas. This is the most useful published signal available.

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.

Models GitHub groups under general-purpose coding

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

The general-purpose group is the default answer for most work. GitHub’s own phrasing is a “balanced all-round choice for everyday interactive and agentic coding”, which is where most work belongs unless something specific argues otherwise.

Optimised for speed and responsiveness. GitHub suggests them for quick edits, utility functions, syntax help and lightweight prototyping.

Models GitHub groups under fast, simple or repetitive work

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

Speed matters most when the answer is not in doubt and waiting is the real cost — boilerplate, format conversions, quick explanations.

For tasks that require step-by-step reasoning, complex decision-making, or high-context awareness.

Models GitHub groups under deep reasoning and debugging

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	Google	Public preview	Deep reasoning and debugging; Working with visualsRetires 2026-09-01

For tasks needing step-by-step reasoning, complex decisions, or high context awareness. This is where the difference between models is most visible.

For questions about screenshots, diagrams, UI components or other visual input. These models support multimodal input.

Models GitHub groups under visual reasoning

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	Google	Public preview	Deep reasoning and debugging; Working with visualsRetires 2026-09-01

Multimodal input, so a screenshot of a broken layout or a diagram of an intended architecture can be part of the question.

Reading a model name

Model names carry information once you know the conventions, and recognising the pattern is more durable than memorising a list that turns over every few months.

Family and version. GPT-5.4, Claude Opus 4.8, Gemini 3.7. A higher number within a family generally indicates a newer release, and families do not compare across providers — Claude Opus 4.8 and GPT-5.4 are not “the same generation”.

Size or tier within a family. Anthropic uses Haiku, Sonnet and Opus in ascending capability and cost. OpenAI uses nano, mini and unqualified names similarly. Google uses Flash for the fast tier and Pro for the capable one.

Specialisation suffixes. A name containing “Codex” or “Code” signals coding focus. “Fast mode” on a capable model signals a latency-optimised variant of something otherwise heavyweight.

Codenames. Some models carry names that encode nothing — Luna, Sol, Terra within one family. Where the name tells you nothing, the task grouping is the signal to use.

The practical takeaway: within a provider, tier names are reliable and version numbers are reliable. Across providers, neither means anything, and GitHub’s task groupings are the only cross-provider comparison published.

Context windows and why they matter less than expected

Context window size is the specification people ask about most and the one that matters least in day-to-day use, for two reasons.

Everything degrades before it fills. A model with an enormous window does not attend evenly across it. Information in the middle of a long context is used less reliably than information at either end, and this is true of every model regardless of the advertised number. A larger window buys headroom; it does not buy uniform attention.

Relevant beats maximum. Filling a large window with an entire repository produces worse answers than supplying three relevant files, because the signal is diluted. This is the central argument of the context lesson and it applies regardless of which model you chose.

Where window size genuinely matters is a long agentic session, where conversation history, tool output and file contents accumulate whether you intended it or not. There, running out is a real failure mode — the symptom is a model that starts ignoring constraints it followed twenty turns earlier.

Auto selection

Auto is worth understanding because it is a reasonable default and because its behaviour is documented rather than mysterious.

It combines two systems: one tracking real-time model health and availability, the other evaluating task complexity. Together they route the request.

GitHub does not publish which models auto routes to. Its documentation says only that auto chooses from supported models, subject to your policies and subscription type. An earlier version of this page named four specific targets; that list was an inference rather than a documented fact, and one of the four was deprecated while it sat here. If you need to know which model answered, read it from the response — do not reason from a routing table nobody published.

Three facts worth holding.

It is available on every plan. On Copilot Free and Copilot Student, model access is available only through auto — there is no manual selector.

Paid plans get a 10% discount on model cost while using auto in Copilot Chat, Copilot CLI, the GitHub Copilot app, or the cloud agent.

It honours administrator policy. If your organization restricts models, auto routes within what is permitted.

Plans and access

Model availability depends both on your Copilot plan and on the surface you are using at the time. Free and Student are the most restricted — auto only. Paid plans open manual selection, with the specific list varying.

Organization and enterprise administrators can restrict which models are available to their members, which means the list you see may be shorter than GitHub’s published list. That is a policy decision rather than a bug, and it is worth knowing before you spend time working out why a model everyone online recommends does not appear for you. Auto respects those restrictions too, routing only within what your administrator permits.

Credits and cost

Model choice has a billing dimension, and the mechanics are worth knowing even if you never think about them again.

Every plan includes a monthly allowance of GitHub AI Credits, and model choice is what spends them. Paid individual plans split the allowance into base credits — fixed, and matched to the subscription price — and a flex allotment on top that GitHub can adjust as model economics change. Base credits are spent first, and the same rates apply in your IDE, on GitHub.com and in Copilot CLI.

A single prompt is one interaction regardless of how much work it causes: actions the agent takes on its own, including tool calls, are not charged separately. A prompt that triggers twenty tool calls is still one interaction. What varies is the per-model rate — a more capable model consumes more of the same allowance, which is the entire billing argument for not defaulting to the largest model available.

Current monthly allowances:

Copilot Pro — $10 USD per month (free for verified teachers and popular OSS maintainers), 1,500 AI credits.

Copilot Pro+ — $39 USD per month, 7,000 AI credits.

Copilot Max — $100 USD per month, 20,000 AI credits.

Copilot Business — $19 USD per granted seat per month, 1,900 AI credits.

Copilot Enterprise — $39 USD per granted seat per month, 3,900 AI credits.

Credits are worth $0.01 each and do not roll over between months. When the allowance runs out you can upgrade, or set an additional usage budget to buy more.

Legacy premium-request billing

Before 2026-06-01, individual paid plans were billed in premium requests rather than credits. GitHub’s documentation now scopes that scheme to

Copilot Pro and Copilot Pro+ subscribers on an existing annual plan who remained on premium request-based billing after 1 June 2026.

If that describes you, the mechanics were: allowances deducted by a per-model multiplier, code review charged flat at 13 requests regardless of model, additional requests at $0.04 each, and counters resetting on the 1st at 00:00 UTC with no roll-over. The allowances were Copilot Pro at 300, Copilot Pro+ at 1,500.

These figures are retained because grandfathered subscribers still search for them. They are not the current allowances, and the numbers above are.

Model availability by surface

The list you see depends on where you are, not only on your plan. GitHub’s own wording is that availability “depends on your Copilot plan and where you’re using Copilot, such as GitHub.com or an IDE” — and most models are reachable across GitHub.com, VS Code, the CLI, Visual Studio and JetBrains, with variation by model.

Three consequences follow.

A model you use in one place may not appear in another. This is the most common surprise, and it is not a bug. A colleague’s screenshot showing a model you cannot select may simply be a different surface.

Automation inherits this. A script or workflow pinning a model needs that model available where the automation runs, which is a different environment from your editor.

Prompt files that pin a model are doubly constrained. They already work in only three IDEs; pinning a model narrows that further to the intersection.

The practical advice is the same as for retirement: prefer auto unless you have a reason, and where you do pin, expect to revisit it.

Custom model providers

Some Copilot surfaces support supplying your own model credentials — bring your own key — which routes requests to a provider account you control rather than through Copilot’s allowance.

This is a real capability and it is a narrower topic than it sounds. It matters for organisations with specific compliance requirements about where inference happens, or with existing provider commitments they want to use. It does not change anything about prompting, context or instructions, and it does not make a model behave differently.

If it applies to you, the CLI documents its support under copilot help providers, and the configuration is surface-specific. If it does not apply to you, nothing else in this cluster depends on it.

Retirement

Models are removed on announced dates. This is normal, and it has a consequence worth planning for: any tutorial, prompt file or configuration that names a specific model has a shelf life.

Models with an announced retirement date

Model	Provider	Status	Retires
Claude Opus 4.5	Anthropic	GA	2026-09-01Suggested alternative: Claude Opus 4.7, Claude Opus 4.8 or Claude Opus 5
Claude Opus 4.6	Anthropic	GA	2026-09-01Suggested alternative: Claude Opus 4.7, Claude Opus 4.8 or Claude Opus 5
Claude Sonnet 4.5	Anthropic	GA	2026-09-01Suggested alternative: Claude Sonnet 5
Claude Sonnet 4.6	Anthropic	GA	2026-09-01Suggested alternative: Claude Sonnet 5GitHub states Claude Sonnet 4.6 remains available to individual Copilot subscribers on annual plans, so they retain a Sonnet offering; the deprecation does not apply to those customers.
Gemini 3.1 Pro	Google	Public preview	2026-09-01Suggested alternative: Gemini 3.6 Flash
MAI-Code-1-Flash	Microsoft	GA	2026-09-10Suggested alternative: MAI-Code-1.1-FlashAlso the named successor for Raptor mini, which is deprecated on 1 September — nine days before this model is. Anyone following that migration path should go straight to MAI-Code-1.1-Flash.
Raptor mini	Fine-tuned GPT-5 mini	GA	2026-09-01Suggested alternative: MAI-Code-1-FlashGitHub names MAI-Code-1-Flash as the replacement, and MAI-Code-1-Flash is itself deprecated on 10 September. MAI-Code-1.1-Flash is the destination that survives both dates.

Two patterns in that table are worth noticing. GitHub sometimes names a successor and sometimes does not, so a retirement is not always an instruction about what to move to. And retirements can carry exceptions — one of the models above remains available to individual subscribers on annual plans despite the general deprecation, which means the answer to “is this model still available” can depend on who is asking.

Why benchmarks are not on this page

The obvious thing to want here is a table with a number per model, and the reason there is not one is worth explaining rather than asserting.

GitHub does not publish coding-quality scores. It publishes which models exist, who makes them, and what task areas they suit. Anything more specific would have to come from elsewhere.

Public benchmarks measure something narrower than they appear to. A score on a set of self-contained programming puzzles tells you about performance on self-contained programming puzzles. It does not tell you how a model behaves across a forty-thousand-line codebase with your conventions, your instruction files and your half-finished migration — which is the situation you actually care about.

Benchmark results age faster than the models. A comparison published three months ago may involve two models that have since been superseded and one that has been retired.

Copilot is not the raw model. What reaches you has been shaped by GitHub’s prompting, context assembly and tooling. A model’s standalone benchmark score is measuring a different system from the one you are using.

None of that means comparison is impossible — it means the honest comparison is qualitative and about fit rather than a leaderboard. The model comparison lesson gives the factual matrix GitHub does publish, without inventing the parts it does not.

Evaluating models for yourself

If you want to know which model suits your work, the only reliable method is to try them on your work.

Pick a task you have already done. Something where you know the right answer, and ideally something that took you a while. A bug you eventually found, a refactor you completed.

Give each model identical input. Same prompt, same context, same instruction files in force. Any variation makes the comparison meaningless.

Judge on the things you actually care about. Did it identify the real cause, or a plausible-sounding wrong one? Did it stay in scope? Did it notice the constraint you did not state? Was it fast enough for the interaction to feel worth it?

Repeat once or twice. These systems are non-deterministic, and a single run is a sample of one. A model that gets it right once and wrong twice is not better than one that is consistently adequate.

What model choice does not fix

The honest framing, and the reason this lesson sits eighth rather than first in the cluster.

Model choice is one of five levers, and it is the one with the smallest effect on a well-configured project. A more capable model cannot see a file you did not mention, cannot know a convention you never wrote down, and cannot verify its own output.

If results are disappointing, the diagnostic order is: did it see the right context, were the constraints stated, are the instructions in force, then is the model a poor fit. Reaching for the model selector first is common and usually misdirected.

Where model choice genuinely helps: sustained multi-step reasoning, debugging that requires holding several interacting facts at once, and architectural questions with real trade-offs. Where it helps least: anything mechanical, and anything failing because of missing information. The second category is much larger than the first, which is the whole reason this lesson sits where it does in the cluster rather than at the front.

Keeping up without chasing

32 models today, and a list that will look different in three months — seven of them carry a retirement date already. Trying to track every release is a poor use of attention. Three habits give most of the benefit.

Check the list when something changes for you, not on a schedule. A new project, a task that is going badly, a model that stopped appearing — those are the moments the inventory matters.

Read retirement announcements, ignore launch announcements. A new model is an option you can take or leave. A retirement is a thing that will break, on a date, whether or not you noticed.

Let auto absorb the churn. The strongest practical argument for auto is not routing quality; it is that a session using auto keeps working through a retirement that would have broken a pinned configuration.

Next

Choosing a model turns this into a decision framework based on the task in front of you. The comparison is the current factual matrix.

For the levers that matter more, context and instructions are where most disappointing output is actually fixed.