The invoice a coworker forwarded me with three exclamation marks
That was the whole message. No context, no question, just the PDF. He is a heavy Copilot user, he had a good June, and the total on the last line was the reason for the exclamation marks. If you have not received one of those yet, I am fairly sure someone on your team has, and Microsoft is reading the same threads. The Visual Studio June Stable Channel update quietly ships two features you can feel on a normal Tuesday: a real-time Copilot usage window with proactive alerts, and a trust check that pauses MCP servers whose configuration has changed between sessions.
Neither one is glamorous. Both are the kind of change you only notice in the relief of a Slack thread you did not have to open.
What actually shipped
The cost side is straightforward. Visual Studio now surfaces real-time usage against the token-based model, with proactive alerts as you approach a limit, when you hit it, and when overage billing kicks in. Teams can configure the warning threshold, so the trip wire can sit wherever your team's budget conversation actually happens.
The MCP side is more mechanical. Trust is checked in two places. At startup, the current MCP server configuration is compared against a previously trusted baseline. After startup, a fingerprint of the server's tools, prompts, resources and instructions is compared to the last trusted version. If anything diverges, Visual Studio stops and asks. You can accept the change and update the baseline, always trust the server going forward, or reject and abort startup. First-time connections are treated as implicitly trusted, and built-in or registry-controlled servers skip the prompt entirely.
Why an IDE update matters to a CI/CD reader
Two reasons, and they both land in the same place.
The first is cost. GitHub shifted every Copilot plan from premium request units to usage-based billing on June 1, with the meter now counting tokens instead of requests. DevOps.com cites reports of monthly bills that jumped from roughly $29 to $750, and from $39 to over $800 for the heaviest agentic users. Whether or not your team's numbers match those, the shape is familiar. A background agent runs a loop, the loop is measured in tokens now, and nobody sees the meter until the invoice arrives. Anything that puts the meter back where the engineer is actually looking pulls that feedback loop closer to the decision.
The second is drift in agent tooling. MCP servers are the extension port for AI assistants, exposing tools, prompts, resources and instructions the model can call. When those servers get updated on their own schedule, treating a change in the tool list as a security event, not a startup log line, is the right instinct. You would not silently accept a new binary in your CI runner just because it kept the same filename.
Using both features on a Tuesday
For cost, the practical move is the threshold. Set it low the first week, high enough not to be noise, and let the alert tell you when a session went agentic without you meaning it to. The window will not stop the spend. It will stop the surprise, which is the useful thing an IDE can actually do.
For MCP, the trust dialog is a moment of forced attention. The three options are not equivalent:
- Accept and update the baseline is the day-to-day answer, when a server you know has legitimately added a tool.
- Always trust is the option you should almost never pick, because it turns the tripwire off permanently for that server.
- Reject and abort is the answer whenever the change surprises you. That includes the case where a teammate's server updated overnight and you have not read the release notes yet.
If the last option feels harsh, remember that MCP tools can, by design, call things on your behalf.
Where the update stops short
I like both features. I also want to be honest about where they stop short, because a piece that only celebrates is off-voice.
The alert fires after tokens are spent. It is a rear-view mirror on the current window, not a pre-flight cap. If you are working with a background agent, the alert can arrive several thousand tokens after the decision that triggered them.
Trust is per-workstation. In what the article describes, there is no equivalent yet for an org policy that says "these MCP servers are approved, everything else stays cold". A team of ten Visual Studio users still maintains ten independent baselines.
First-time connections are implicitly trusted. That is a sensible default for a dev tool, but it means the first run is exactly the moment you have to look most carefully at what the server exposes.
And this is Visual Studio, not VS Code, not JetBrains. If your team splits IDEs, only the Visual Studio users get these two panes this month.
Where other tooling stands on the same problems
IDE cost meters are becoming an expected feature, not a differentiator. Most AI coding assistants that meter by tokens now surface a usage view of some kind, whether inline in the sidebar or in the account portal. The interesting question is whether the meter lives where the engineer is actually working. Visual Studio's version at least clears that bar.
MCP trust is a newer conversation. The MCP specification treats configuration as data a host can consume, and it is up to each host to decide what to do when that data shifts. Some hosts prompt on any new tool. Some log the change and continue. Some do nothing. What Visual Studio is proposing is one specific approach: fingerprint the interface surface, compare it to a stored baseline, and pause when the two diverge. It is a defensible default and I would like to see it copied.
For a CI/CD team the interesting extension is on the pipeline side. If your agents run in CI too, the trust primitive belongs there as well, not only in the editor. A container that pulls an MCP server from a registry each run should be diffing that server against a locked baseline before it lets the model call anything. Nothing in this Visual Studio update reaches into the pipeline. That part is still on you.
The signal I am keeping an eye on
Two things.
Whether other IDEs pick up the same fingerprint-and-baseline pattern in the next few releases, because that is when a vendor's opinion starts to become a norm. And whether org-scoped MCP allowlists arrive, because a per-user trust dialog is the right primitive, but a team of ten does not have a policy until one central place says so.
If both land in the second half of the year, we will look back on this June update as the quiet moment the industry started treating MCP configuration as security-relevant. If neither does, we will look back on it as a Visual Studio nicety that saved a few Tuesday invoices, which is not nothing, but not the thing I was hoping for either.
Top comments (0)