Spending credits where it pays

The previous lesson kept gesturing at a cost. Here’s what’s actually being spent. Copilot’s heavier usage draws on a budget of AI credits — what get billed as premium requests. The principle is simple and it’s the whole reason the picker is a decision and not a habit: the more you ask for, the more it costs. Reaching for a higher-reasoning model spends more than a routine one. Asking Copilot to hold a larger context window — more of the codebase in view at once — spends more than a tightly scoped request. Bigger thinking and bigger context both run the meter faster.

You don’t need to count credits per request, and you shouldn’t try — the awareness here is qualitative, not arithmetic. The mental model is enough: the deep-reasoning, wide-context settings are your premium budget, so save them for the work that needs them. This is the same spend-where-it-pays logic one more time. On the shared-lib refactor, the expense is the point — that’s exactly the work worth your best reasoning. On routine orders-service CRUD, paying premium rates for an answer the lighter model would have gotten right is just burning budget. Match the spend to the stakes, the way you’ve matched everything else.

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.

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.

Units are illustrative — one unit is roughly the light model running a small task at low effort. A capable model bills ~5× per token; high effort generates ~3× the tokens; the ratios are the point, not the prices. The redo tax counts an underpowered task’s failed attempts plus the escalation you do anyway — not the hour you spend reading confident wrong answers, which is the real bill.

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 sets which models even appear in your picker and how much premium-request budget you have to draw on — and that’s true regardless of which mode or model you’d personally reach for. If a setting you expect isn’t there, the answer usually isn’t in VS Code; it’s a policy your organization set. That’s not a wall to fight, just the shape of working inside someone else’s plan: tune the dials you’ve got, and know the outer limits were drawn before you opened the editor.

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.