Spending credits where it pays

The model-picker lesson kept gesturing at a cost. For current plans, heavier usage draws on a budget of GitHub AI Credits - individual plans carry their own allotments and usage views, covered with the tiers on the plans page. 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 do not 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 a shared-library refactor, extra reasoning may be worth the budget; on routine CRUD in your own service, a lighter or automatically selected model may be enough.

The widget keeps generic dials - model capability and thinking effort - where Copilot’s equivalents are choosing a stronger model and asking for deeper reasoning on the same context; the ledger underneath is the same one. Run a day of it and watch where a pinned premium setting leaks - and note the asymmetry the day exposes: skimping on a hard problem is the costly mistake, because failed attempts plus the escalation you run anyway cost more than starting on the capable corner:

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 categorization 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 is a wrinkle that lands hardest for the enterprise reader. When you signed in back in Getting started, the setup flagged that at a company providing Copilot, what you can do is partly decided above your account - your access and 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 is not there, the answer may be a plan or organization policy rather than a VS Code setting. Tune the dials you have, and check the plans 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 what it can figure out and 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 library work; short leash and light reasoning for routine app code. You now have both knobs, and the judgment to set them.

There is also a posture change waiting. The careful, in-editor work is behind you; what remains in the course’s orders-service scenario is a backlog of routine follow-up issues - exactly the low-stakes, well-scoped work you would never spend premium reasoning on. So the next chapter stops doing that work in the editor at all: it hands each issue to a Copilot that works on its own, in the cloud, and comes back with pull requests for your review. Next chapter: Automation - the cloud coding agent.