How VS Code Copilot Chat Premium Features Leak into Subagents (and Why It Matters)

A surprising Copilot Chat vulnerability (or, depending on your perspective, a billing logic bug) popped up this week: you can route “premium” model usage through subagents while being billed as if you were using a cheaper/free model.

It’s documented publicly in a VS Code issue titled “Billing can be bypassed using a combination of subagents with an agent definition, resulting in unlimited free premium requests” (microsoft/vscode#292452) and discussed on Hacker News (HN item 46936105).

This post breaks down what’s going on, why it matters beyond a single product, and what we (and anyone building agent systems) should do about it.

The core bug: metering is attached to the wrong boundary

Copilot’s “premium requests” model is supposed to make cost predictable: you pick a model tier, and requests to more expensive models consume more premium request budget.

The issue report shows a path where:

• A user starts a chat on a “free” model (e.g. a cheaper model included in the plan).
• The user (or an agent prompt) invokes a subagent via tooling.
• The subagent runs with an agent definition that specifies a premium model.
• The system executes the premium model work, but meters the interaction as if it stayed on the initial (free) model.

The report also suggests a second class of problems: “tool calls” / agent loops where extensive work happens “inside” tool invocations and doesn’t increment request counters in the expected way.

Why subagents are the perfect hiding place

Agent systems often have three layers:

• Orchestrator / planner: decides what to do next
• Tools: e.g. file operations, web fetch, code execution
• Subagents / specialists: spawn a new model instance with a different system prompt, different model, different context window, etc.

If you charge for “user messages,” but subagents can do meaningful premium work without generating additional “user messages,” you’ve created a gap.

How the bypass works (conceptually, not as a step-by-step exploit)

The public issue includes reproduction instructions and sample agent files. I won’t repeat the full procedure here; instead, here’s the conceptual model you can apply to any multi-agent system:

The ingredients

• A parent interaction that’s billed at Tier A (free/cheap)
• A spawn mechanism (subagent / tool / function) that can run Tier B (premium)
• A server-side enforcement gap where:

The critical design mistake

> Billing is derived from the initiating model (or the UI-selected model), not from the executed model(s).

Once you allow “agent-defined paths” (agent files / prompt frontmatter / tool schemas) to select or override models, you have to treat those paths as first-class billable actions.

If you don’t, users can deliberately shape a conversation so that the “billable” surface looks cheap while the “execution” surface does expensive work.

The subtle point: this isn’t only about money

It’s tempting to call this “just a billing bypass.” But it’s also an example of a broader class of failures:

• Policy bypass: safety controls applied at one layer don’t hold at another
• Quota bypass: rate limits apply to the wrong primitive
• Audit gaps: the system log shows Tier A, but Tier B was actually used

Why this matters for LLM-based tooling: metering is a security boundary now

In 2024, metering was mostly finance.

In 2026, metering has become part of the security model.

Why? Because agentic systems convert “usage” into real-world side effects:

• expensive inference cost
• code changes
• API calls to third-party services
• data access
• background tasks that keep running

1) Predictable cost is necessary for trust

Teams adopt Copilot-style products because they’re predictable compared to raw APIs. The “premium request” idea is basically a fixed-price abstraction.

If that abstraction breaks, the product becomes:

• harder to budget for providers
• easier to abuse by users
• harder to reason about operationally

2) Model tier selection is often tied to safety posture

Different models and modes often have different:

• tool access
• context limits
• content policy tuning
• “refusal” behavior

3) “Tool calls are free” is a footgun

The issue report highlights a pattern many platforms share: “tool calls” are treated as internal actions rather than billable compute.

But tool calls are often the mechanism by which the model:

• does more thinking (via nested calls)
• does more reading/writing (files, network)
• does more execution (code runners)

What this means for BuildrLab’s multi-agent architecture

We build multi-agent workflows all the time: planners, code-gen agents, QA agents, doc agents, research agents.

So the first question we should ask is blunt:

> Are we vulnerable to the same class of bug?

The risk pattern (applies to us)

We’re vulnerable if all of the following are true:

• The user (or upstream agent) initiates a request in a “cheap” mode.
• That request can spawn subagents with a different model tier.
• Our billing / metering / quota enforcement is anchored to the parent request.
• The server does not validate “who is allowed to run which model” at execution time.

• internal cost budgets per workspace / org / user
• rate limits
• safety policies (what tools can do, what data can be accessed)

How to prevent this class of failure

The fix is less about patching one path and more about adopting a principle:

> Enforcement must be attached to the execution primitive — not the UI primitive.

Concretely, for a multi-agent backend:

• Server-side model authorization

• Child calls inherit billing context

• Meter on actual model execution

• Tool and subagent caps as first-class policy

• Audit logs that match reality

• Treat agent definitions as untrusted input

A simple litmus test

If you can answer “yes” to this question, you likely have the same bug class:

> Can a request that is accounted as Tier A cause the backend to execute Tier B compute without debiting Tier B?

Practical takeaways for anyone building agent systems

Whether you’re building an IDE agent, a “chat with your repo” assistant, or an internal automation bot, here’s a checklist you can apply immediately.

1) Define your billable primitives

Don’t bill “messages.” Bill the things that cost money:

• model inference calls
• tool executions that invoke third-party services
• long-running background jobs

2) Make the server the source of truth

Anything enforced only on the client will eventually be bypassed.

• model selection
• quota checks
• tool permissions
• max request depth

3) Treat subagents as first-class actions

Subagents shouldn’t be a loophole. They should be a clearly defined part of your execution graph.

• subagent calls must be authenticated
• they must be authorized
• they must be metered
• they must be traceable

4) Build “budget-aware” orchestration

Instead of “keep going until done,” give agents explicit budgets:

• max tokens
• max tool calls
• max wall-clock time
• max subagent spawns

5) Assume prompt files will be weaponized

Agent definitions and prompt files are not documentation — they’re executable configuration.

If users can edit them, they can:

• coerce different model selection
• force loops
• attempt to disable safety controls

Where Copilot goes from here

I don’t have inside information on how Microsoft/GitHub will resolve this, but the fix likely needs to land in two places:

• Accounting/metering: tie billing to actual execution (including subagents)
• Policy enforcement: ensure agent definitions can’t silently escalate compute tier without debit and authorization

If you’re building agent products, this is your warning shot.

References

• GitHub issue: Billing can be bypassed using a combination of subagents with an agent definition, resulting in unlimited free premium requests — https://github.com/microsoft/vscode/issues/292452
• Hacker News discussion: Billing can be bypassed using a combo of subagents with an agent definition — https://news.ycombinator.com/item?id=46936105