GitHub shipped a Visual Studio update on August 28 that quietly changes how teams should think about AI coding assistant cost. The headline features: Low/Medium/High thinking-effort controls for supported models, a model management view showing context window size and cost per model, the ability to pin favorites and collapse rarely-used ones, and organization-level custom agents that show up automatically across repos.

The effort dial is the one I care about. It’s a small UI addition with a real architectural implication: effort tuning is finally being exposed as a per-task decision instead of a per-team model policy.

Why this matters: the model-selection trap

Most teams I’ve worked with handle model cost the blunt way — pick one model tier for the whole org (gpt-5.x for everyone, or a cheaper model for “juniors”), set it in policy, move on. That’s the wrong axis. The cost/quality tradeoff that actually matters isn’t which model, it’s how hard should this specific call think.

I wrote about this exact failure mode a few weeks ago covering GLM-4.6/Qwen3.8 reasoning-effort settings — teams cranking reasoning effort to “high” by default because it sounds like a quality lever, then eating 3-5x latency and token cost on requests that didn’t need it (a one-line rename doesn’t need extended reasoning; a cross-file refactor with ambiguous intent does). The lesson there was: reasoning effort is a per-request knob, not a global default, and defaulting it high is usually just burning budget.

Copilot’s new per-model Low/Medium/High control is GitHub finally exposing that same knob inside the IDE workflow, instead of leaving it buried in API parameters only power users touch. Concretely, before this update, if your org standardized on a reasoning-capable model, every Copilot request — autocomplete-adjacent stuff and gnarly refactors alike — paid the same reasoning tax. Now a developer (or an org policy, more importantly) can set effort per task:

Quick inline suggestion, boilerplate, single-file edit  → Low
Multi-file refactor, ambiguous requirements              → Medium
Architecture-level change, security-sensitive code path  → High

What I’d actually configure

If I were rolling this out for a team this week, here’s the policy I’d write, and it maps directly onto the same effort-tiering framework from the reasoning-effort piece:

# .github/copilot-effort-policy.yml (illustrative — check current org policy schema)
default_effort: low
overrides:
  - path_glob: "src/auth/**"
    effort: high
  - path_glob: "src/payments/**"
    effort: high
  - task_type: "multi_file_refactor"
    effort: medium
  - task_type: "inline_completion"
    effort: low

The instinct to resist: don’t set org default to high “to be safe.” That’s the same mistake as defaulting reasoning effort to max on an open model — you pay for it on every trivial completion, all day, across every developer, and the marginal quality gain on a one-line change is close to zero. Reserve high for the paths where a wrong answer is expensive: auth, payments, migrations, anything touching data integrity.

The model management view matters more than it looks

The second feature — a management view showing context window size and cost per model, with pin/collapse controls — is the boring-but-necessary companion to effort tuning. Effort controls only pay off if developers can actually see what they’re trading off. A Low/Medium/High toggle without visible cost context is just vibes. Pairing it with a visible cost/context table is what turns “I’ll just set it high, who cares” into an informed choice at the point of use, which is exactly where FinOps-for-AI conversations keep landing this year: push cost visibility to the point of decision, not to a monthly billing dashboard nobody reads until it’s too late.

Where this still falls short

Two gaps I’d flag before calling this “solved”:

  1. No cost telemetry per effort tier yet, as far as the changelog shows. You can set the dial, but I didn’t see mention of per-developer or per-repo reporting on how effort settings actually affected spend. Without that feedback loop, teams will set the policy once and never revisit it — the same failure mode as static reasoning-effort defaults.
  2. Effort is still manual, not adaptive. The ideal version of this feature infers effort from task complexity automatically (diff size, file count touched, whether the change touches a flagged sensitive path) and only asks the developer to override, not choose from scratch every time. Right now it’s a manual dial, which means adoption depends on developer discipline — historically the weakest link in any cost-control policy.

Net: this is a good, overdue feature. It won’t fix your Copilot bill by itself, but it gives you the lever you need to actually enforce the effort-tiering discipline that was previously only available if you were calling the model APIs directly.

Source: GitHub Changelog: GitHub Copilot in Visual Studio — August update

Export for reading

Comments