Spending credits where it pays

The previous lesson kept gesturing at a cost. For current plans, heavier usage draws on a budget of GitHub AI Credits. Some existing individual subscriptions may still use the older premium-request system, but those are separate billing models. In either case, the principle is simple: the more expensive the model or feature, the more usage budget it can consume. The exact cost depends on the plan, model, surface, and current GitHub pricing.

You don’t need to memorize a fixed per-request price - availability and rates change. The useful mental model is qualitative: use the stronger model or feature where it can change the outcome, and check the usage view for your plan. On the shared-lib refactor, extra reasoning may be worth the budget; on routine orders-service CRUD, a lighter or automatically selected model may be enough.

The dials wear Copilot’s names here - a higher-reasoning model and a wider context window rather than an effort slider - but the ledger underneath is the same one. Run a day of it and watch where a pinned premium setting leaks:

A lumpy day: four kinds of task, and two dials on each - which model answers, and how much effort it spends thinking. Everything starts where most people leave it: pinned to the expensive corner. Re-dial each task and watch what the day costs.

• copy tweaksmechanical · five today

  Fix the onboarding typo, reword two error strings, update the footer year - one obvious answer each.

  modellightcapableeffortlowhigh

  top dollar, one answer

  The most expensive corner on the board, spent on work the cheap corner ships identically. This is where a pinned dial leaks.

• pattern-following endpointsmechanical · three today

  Add list/create endpoints that mirror the handler in the next file over.

  modellightcapableeffortlowhigh

  premium for boilerplate

  Nothing about list/create forks or surprises; the expensive reasoning has nothing to grip. Reserve this corner.

• the intermittent failurehard · once, thankfully

  A test that fails one run in five, timing-dependent, with the cause three files from the symptom.

  modellightcapableeffortlowhigh

  matched - spend it here

  A genuine reasoning problem: timing-dependent, cause far from symptom, no pattern to copy. This corner exists for exactly this task.

• the design forkhard · once

  Choose how rule conflicts resolve in the categorisation engine - several defensible designs, one gets built on.

  modellightcapableeffortlowhigh

  matched - the wrong call costs a rewrite

  Several reasonable designs, and whichever wins gets built on. The delta between corners here is noise next to the cost of unpicking a bad choice later.

presetspin everything expensiveroute by taskunderpower the hard task

first runs495 unitsredo tax0 unitsvs the matched day1.9×

Everything ships - no failures, no redo tax - and the day still costs 1.9× what it should. That’s the quiet leak of a pinned dial: the mechanical work bills like hard work, five and three times over. Dial it down to the cheapest corner that ships it; the hard problems keep their budget.

Numbers are illustrative - the ratios are the point (capable ≈ 5× per token, high effort ≈ 3× the tokens). The redo tax counts an underpowered task’s failed attempts plus the escalation you’d run anyway, not the hour lost to confident wrong answers.

On a company plan, the ceiling isn’t yours

There’s a wrinkle that lands hardest for the enterprise reader, and it’s a callback worth making explicit. When you signed in back in Getting started, we flagged that at a company that provides Copilot, what you can do is partly decided above your account - your access and your policies come down with your organization’s plan. Model availability is one of the specific places that bites.

It connects to the hierarchy you met in the Rules chapter: personal settings, repository settings, and the organization sitting above both. Here that hierarchy shows up as a budget and a menu. Your org’s plan and policies can determine which models appear in your picker and how much shared AI-credit budget is available. If a setting you expect isn’t there, the answer may be a plan or organization policy rather than a VS Code setting. Tune the dials you’ve got, and check the current plan documentation before treating a number as stable.

Both dials, one habit

Step back and look at what the last two chapters gave you. Permissions tuned how much Copilot may do; models and credits tune how hard it thinks. Two different dials, one identical instinct: spend the expensive setting only where it changes the outcome. Long leash and deep reasoning for the high-stakes shared-lib work; short leash and light reasoning for routine app code. You now have both knobs, and the judgment to set them - which is the judgment that closes Act 1.

Act 2 is a different posture entirely. The careful, in-editor work is behind you; what’s left is a backlog of routine follow-up issues on orders-service - exactly the low-stakes, well-scoped work you’d never spend premium reasoning on. So you’re going to stop doing it in the editor at all, and hand it to a Copilot that works on its own, in the cloud, and comes back with draft PRs. Next chapter: Automation - the cloud coding agent.