← FinOpsAid blog

Which Copilot model should we default to? Model choice is now a cost lever

Copilot credits burn at each model's own token rate, so the model your developers pick sets the bill. How to choose a default per use case without slowing anyone down.

Until recently, which model your developers used inside Copilot was a quality question. Somebody preferred one for refactoring, somebody else liked another for tests, and none of it touched the invoice because the invoice was a flat per-seat charge.

That stopped being true on 1 June 2026. Credits are consumed at the published token rate for the model that served the request, which means the dropdown in your developers' editors is now a pricing control that almost nobody has been told about.

The spread is wide and getting wider

GitHub added several models to Copilot in July 2026 alone — Claude Opus 5, Gemini 3.6 Flash, three GPT-5.6 variants, Kimi K2.7 — on top of an already broad roster. They are not priced alike, and they are not close. Frontier reasoning models and small fast models differ in token rate by a large multiple, which propagates directly into credit consumption for identical work.

The practical consequence: two teams doing the same volume of the same work can produce very different bills purely through model preference. No difference in adoption, no difference in output, entirely a difference in what was selected in a dropdown.

That's an unusual kind of cost driver. It requires no behaviour change to fix, no reduction in usage, and no trade-off against developer experience if you get the mapping right. It's close to free money, which is rare.

Match the model to the task, not to the developer

The instinct when this lands is to mandate the cheapest model. Don't — it's the version of this that fails. A cheap model that can't complete the task gets retried, re-prompted and eventually escalated anyway, and you've paid for the failures on top of the eventual success. Worse, you've spent credibility.

The workable pattern is a default per use case, which developers can override:

Routine, bounded work — explaining a function, writing a test for existing code, small mechanical edits, straightforward chat. A fast, cheap model handles this well, and this is the bulk of daily volume.

Genuinely hard reasoning — architectural questions, subtle debugging, unfamiliar codebases, anything where a wrong answer costs an hour. Use the frontier model. The token cost is trivial next to the engineering time it saves, and pretending otherwise is false economy.

Long-context work — large diffs, wide repository context. Here the input token count dominates, so the cheaper-per-token model matters more than usual, and trimming the context matters more still.

Agent runs — the expensive case, because an agent makes many calls per task. This is where model choice compounds hardest, and where a default is worth the most.

The overrides are the point

A default that can't be overridden is a mandate, and mandates around developer tooling get routed around or resented. The goal isn't to constrain the choice — it's to make the sensible option the one that happens when nobody is thinking about it, which is most of the time.

Give people the escape hatch and tell them when to use it. "Default to the fast model; switch to the frontier model when you're stuck or the problem is genuinely hard" is a rule engineers will follow, because it matches how they already think about their own attention.

What you should watch afterwards isn't compliance. It's whether the mix drifts — and if it drifts toward the expensive end, whether that's because the work got harder or because the default stopped being sensible.

Track model mix as a first-class number

Most organizations can't currently answer "what share of our credits went to which model?", which is why this lever sits untouched.

Track the mix by tier — frontier, mid, small — as a share of consumption rather than a share of requests. Requests are misleading here, because a handful of frontier-model agent runs can outweigh thousands of cheap chat exchanges. Consumption share is the number that maps to the bill.

Then watch it move. A rising frontier share is not automatically bad; it may mean your team is tackling harder problems, or that a new model genuinely earns its rate. It's bad when nobody chose it — when the share moved because a default changed upstream, or because a new model appeared in the picker and became fashionable.

This is also the number to bring when someone proposes cutting Copilot spend. "We shifted 40% of routine chat to a cheaper model and consumption fell without a single complaint" is a far better answer than reducing seats, and it's available to almost everyone because so few organizations have looked.

Worth doing

• Publish a default per use case. One short paragraph, not a policy document.
• Never mandate the cheapest option. Retries and escalations cost more than the model you avoided.
• Set the default hardest for agent runs. That's where model rate compounds across many calls.
• Measure mix by consumption, not by request count. Only one of them predicts the invoice.
• Re-check when new models land. They arrive monthly now, and each one shifts the frontier of what "sensible default" means.
• Watch drift, not compliance. A mix that moves for a reason is fine. One that moves because nobody decided is the finding.

Model choice is the cheapest cost lever GitHub has handed anyone in years, and it's sitting unused in most organizations because it looked like a preference setting rather than a pricing one.

FinOpsAid surfaces the mix directly: Copilot breaks credit consumption down by model and tier alongside adoption, so a rise in spend resolves to which model and which surface rather than a total — and what actually consumes credits stays visible next to what it cost.

Frequently asked questions

Does the Copilot model my developers pick affect the bill?

Yes. Since 1 June 2026 credits are consumed at the published token rate for the model that served the request, so the model dropdown is now a pricing control. Two teams doing identical work can produce very different bills purely through model preference.

Should we mandate the cheapest Copilot model?

No — that is the version of this that fails. A cheap model that cannot complete the task gets retried, re-prompted and escalated anyway, so you pay for the failures on top of the eventual success. Publish a sensible default per use case that developers can override instead.

How should I measure Copilot model mix?

By share of consumption, not share of requests. Requests are misleading because a handful of frontier-model agent runs can outweigh thousands of cheap chat exchanges. Consumption share is the figure that maps to the invoice, and it is the number to bring when someone proposes cutting Copilot spend.

Want to see where your credits go by model? Connect your GitHub org — read-only and free during beta — or explore the demo dashboard first.