If you’re among the people who use WhatsApp as your primary messaging app, you’d know that the experience in Windows is beyond unusable. And because Meta is a trillion-dollar company with more than 75,000 employees, and all the data centres and AI chops to go with it, it’s not like they can’t fix the awfully slow WhatsApp for Windows.

WhatsApp has 3 billion monthly active users. Windows has 1.6 billion users. WhatsApp for Windows has millions of users, and I can confirm that there is not a single person who has a good experience using it, because I tested the web-wrapper-based WhatsApp for Windows on low-end, midrange, and high-end hardware. Props to Meta for giving the same experience on any budget!

After restarting my PC, I screen-recorded how much RAM the web-based WhatsApp uses even without it opening. It was already touching 400 MB.

You might be thinking that WhatsApp is syncing all my chat history in the background so that when I open it, it’s all up to date, right?

Well, no. Because I haven’t even logged into it yet. I’m not making this up.

That’s how bad the situation is with WhatsApp for Windows, and I’m just getting started. Honestly, I should’ve just left WhatsApp when we first broke the news a year ago about Meta planning WhatsApp’s switch to WebView2 from UWP, but WhatsApp is just so popular with my friends and family.

Instead, I logged out of WhatsApp for Windows and now use WhatsApp Web in a browser, which, ironically, is faster than the dedicated Windows app. I do prefer a proper chat app over a browser tab, but that preference only holds if the app is worth using.

WhatsApp for Windows is a performance nightmare

After logging in and scrolling through chats, RAM usage easily jumped toward 1.2 GB. Idle, it still holds on to around 600 MB.

I wouldn’t mind the RAM usage if the app were fast. But it is slow, and heavy at the same time. Sending a message has an anxiety-inducing delay before the single tick appears, which means the message has not even left your device. People on the other end feel like you are toggling between online and offline because messages show up in bursts, not in real time. Chat switching takes a visible second or more. Scrolling is choppy compared to what the UWP app used to deliver.

For anyone wondering, the old UWP WhatsApp ran over 100 one-to-one chats and around 30 active groups, and it used less than 100 MB at idle!

Obviously, I’m not alone, and everyone has been raising the same concerns since Meta pushed the update. Reports of the app freezing, messages not delivering on time, and the app feeling “half-broken” after waking a PC from sleep are widespread. Waking from hibernate has logged out users on multiple occasions, which Windows Latest also noticed during testing.

Closing the window does not quit the app either. It minimises to the system tray and continues running in the background, holding a sizeable chunk of RAM, just to receive notifications via service workers.

The old UWP app used Windows’ built-in notification APIs, so it did not need to stay alive in the background for that. With the new one, if you exit it from the tray and miss a message, the notification only says “You may have new messages”. Helpful.

And if you closed the app, Exit it from the system tray, open it the very second, it would take a lot of time for WhatsApp to load up.

On a 10-year-old PC, it gets worse

My dad’s PC is a good example of what most people with older hardware are dealing with. It runs Windows 11 on a 6th-generation Intel Core i3 with 8 GB of RAM. My brother has installed a sizeable stack of software on it for his studies, including data analytics tools, machine learning libraries, visualization apps, Cursor, and more. Despite all of that, Windows itself is still fast and smooth on that machine.

Of all the apps installed, only one is slow. WhatsApp.

My dad is not a phone person. He prefers typing on a keyboard and catching up with old school friends on WhatsApp groups from his PC. But ever since Meta pushed the new web-wrapper update, he cannot reply in time. In active group conversations, messages come in slowly. His replies reach others slowly. He gets left behind in conversations he should be part of. On the CPU side, WhatsApp alone was consuming 22.4% of CPU while doing nothing but sitting with one chat open.

There was nothing wrong with the UWP app on that PC. It used around 100 MB and ran without a single hiccup. The switch to WebView2 literally made my dad’s life difficult!

What is a web wrapper, and why does it make for a bad messaging app

A web wrapper is not a standalone app in any native sense. When you open WhatsApp for Windows now, it is essentially loading web.whatsapp.com inside a Chromium-based container called WebView2, which is Microsoft’s rendering engine. The “app” is a shell.

Chromium does not run as a single process. It spawns separate processes for GPU rendering, networking, audio, storage, sandboxing, and crash reporting. Each of these runs independently in the background. So, you end up with a cascade of WebView2 sub-processes all eating CPU and RAM.

A messaging app needs to be running in the background at all times. A native app can hook into the operating system’s notification APIs and sit idle with minimal footprint. A web wrapper cannot do that without keeping a live browser process running, which is why even closing WhatsApp for Windows does not free your RAM.

Running everything through a browser engine is the wrong architectural choice for a communications app. And given that RAM prices have nearly doubled driven by AI data center demand crowding out consumer supply, an app that casually consumes 600 MB to 1.2 GB for messaging is not a small inconvenience. It’s even worse for anyone with 8 GB of RAM.

Microsoft should not be doing this either

Microsoft should get the blame first. Microsoft Teams, which serves enterprise customers who depend on it daily, is still a WebView2-based web wrapper. As we recently reported, Teams claims to be more responsive now, but still eats RAM while doing nothing. At idle, it sits at around 1 GB of RAM.

Microsoft’s response has been to restructure the app rather than rewrite it. A new process called ms-teams_modulehost.exe handles calling features separately from the main process, which is a band-aid over a fundamentally web-based architecture. Microsoft also has a separate problem in that its Teams UI is crowded enough to cause accidental screen shares during calls, an embarrassment the company has since acknowledged and promised to fix.

The company that owns Windows, knows Windows better than anyone, and ships software on Windows, is still running its flagship communication app as a web wrapper. If Microsoft cannot lead by example, there is little incentive for anyone else to.

Why Windows keeps getting web apps instead of native ones

The deeper problem here is a trust deficit. As a developer explained to Windows Latest in April 2026, one of the reasons developers gravitate toward web apps is that Microsoft’s own native framework history is inconsistent. Microsoft built UWP, pushed it heavily, then quietly moved on. Developers who invested in UWP saw Microsoft’s commitment fade.

I believe this is one reason why Meta ditched UWP in favour of a web app for WhatsApp. The company built a solid UWP WhatsApp app. It was lightweight, fast, and used native Windows APIs. Then Microsoft’s enthusiasm for UWP cooled, WinUI emerged as the successor, and Meta made the calculation that maintaining a native Windows app was not worth the risk of betting on another framework Microsoft might eventually abandon. So they shipped a web wrapper instead.

Microsoft also confused the ecosystem in recent months. We reported that Microsoft was considering dumping native Copilot in favour of a web wrapper, and separately, encouraged developers to build Electron apps on Windows, saying native code was not required. Sending such signals while simultaneously expecting developers to commit to WinUI is contradictory.

Also, note that WinUI is still not devoid of flaws, as Microsoft recently confirmed its lack of proper window resizing with noticeable tearing. Fortunately, the company also said that they are fixing it.

Microsoft is finally pushing back, but needs to bring Meta along

To be fair, Microsoft has started course-correcting. At Build 2026, the company encouraged developers to build native apps using WinUI and announced it is killing web app slop in Windows 11. Microsoft is also rewriting Windows 11’s own shell components in native code, replacing sluggish React Native and WebView elements with WinUI.

The company has committed to building 100% native apps for Windows 11, is hiring engineers to build native apps as web apps continue to hurt the OS experience, and a Microsoft engineer has stated that native apps are back. There is also a concrete signal with Microsoft committing to native UI as users push back against web app slop.

All of this is good news. But it is hollow unless Microsoft can bring third-party developers back to native development, and that requires trust. The company has to make WinUI genuinely easy to build with, well-documented, and stable enough that a company like Meta would not fear waking up one day to find it deprecated. If Microsoft leads with inbox native apps that are fast and visibly better than web wrappers, and makes a clear, long-term commitment to WinUI, developers will follow.

1.5 billion Windows users, and still no native WhatsApp

I wouldn’t have written this article if Meta were consistent with this behaviour of making their desktop app a web wrapper for all desktop operating systems. But no. macOS, which has a tiny market share compared to Windows, already has a well-functioning WhatsApp, and funnily enough, even fewer people use it as they prefer Apple’s own iMessage.

It’s fine. It’s macOS. They get all the native apps. But the same Meta that couldn’t allocate resources to make a native Windows app has made a well-optimized WhatsApp for the Apple Watch.

This shows where their priorities lie. Windows users, who are the majority of the world and from different life circumstances, who may use a budget Windows PC, because they can’t afford MacBooks, are all stuck with a sluggish web app.

Meta has been logging more Windows users out to force them onto the new web-wrapper version since late 2025. Windows Latest first reported the UWP-to-Chromium switch back in July 2025, confirmed the transition date in October 2025, and even tracked Meta testing a “Resume” feature to pick up Android chats on Windows, a feature that would be compelling if the app were not so slow to begin with.

Adding features to a broken foundation is not progress. If Meta can build a native WhatsApp for macOS and watchOS, it can do the same for Windows. The resources are there. The platform has 1.5 billion users. There is no excuse for shipping a browser tab as a desktop app and calling it an update.

My message to Meta

There has never been a better time to build a native WhatsApp for Windows. Microsoft has committed to WinUI as the long-term native framework for Windows 11, with no signs of abandoning it the way UWP was quietly sidelined. The company is rewriting its own shell in native code, pushing developers toward WinUI at Build 2026, and investing in making the framework easier to build with. The uncertainty that may have once made the native Windows investment feel risky is gone. If Meta builds a WinUI WhatsApp now, it is building on a foundation Microsoft has publicly and repeatedly committed to.

The post WhatsApp is eating 1.2GB RAM on Windows 11, even as Microsoft kills web app slop appeared first on Windows Latest

Microsoft has spent years subsidizing Xbox rather than profiting from it, CEO Satya Nadella acknowledged this week, as he addressed the gaming division’s need for a new approach. 

His comments came during a Wednesday evening taping of The New York Times’ “Hard Fork” podcast, released Friday. Hosts Kevin Roose and Casey Newton pressed Nadella on the future of Xbox a few hours after the division’s leadership signaled an upcoming reset.

“No one can accuse Microsoft of not having invested for the last 25 years,” Nadella said of the Xbox and games business. “And now we have to turn this into a sustainable business.” 

For all the entertainment value Xbox provides, he said, Microsoft hasn’t been monetizing that entertainment, and has actually been subsidizing it. He added with a chuckle, “In fact, there’s more monetization of Xbox games happening on YouTube than at Microsoft.”

Earlier in the day, Xbox CEO Asha Sharma had told employees in a memo that the division’s heavy spending and declining revenue cannot continue. Sharma, about 100 days into the job, said Xbox will finish the fiscal year at roughly a 3% margin by an internal Microsoft measure, after the company spent more than $20 billion over five years even as annual revenue fell.

Bloomberg News reported that the division is planning major job cuts next month. 

On the podcast, Nadella described two pressures on the business. One is temporary: a run-up in prices driven by the shortage of semiconductors and memory, which is squeezing PCs, phones and other consumer electronics, and which he said Microsoft will get through. 

The other is lasting — the question of what the Xbox business model should be going forward. 

“I think we have to find ways to deliver the games in which it’s economically relevant for the customer and for us,” Nadella said when Newton asked whether he could offer any sort of “carrot” for gamers, or whether consoles and games would simply get more expensive. 

Nadella didn’t detail what the new model would look like. Sharma said in her memo that she’ll spend the next 100 days taking what she called a fresh look at the business.

The Information reported Friday that Microsoft hasn’t ruled out restructuring Xbox — potentially as a wholly owned subsidiary, a joint venture, or a spin-off — though it has no imminent plans to do so. The outlet, citing three people with direct knowledge, said Sharma plans to pair layoffs with heavier investment in big franchises like Halo and Fallout, a plan Nadella and CFO Amy Hood have signed off on.

See above for the full conversation, which otherwise focuses largely on artificial intelligence, including the AI backlash over data centers, AI’s impact on jobs, whether the U.S. government should take stakes in AI companies, and how much he buys the idea that AI is about to automate entire jobs.

In agentic systems, more delegation isn’t always better. Imagine asking Copilot CLI to make a simple change. Instead of handling it directly, it spins up a helper agent that searches the repository, waits on a result, and stalls. Work that should have taken one step now takes three. While some tasks genuinely benefit from a specialist subagent—like exploring an unfamiliar repository, checking an independent area of the code, or running a long command while the main agent keeps moving—delegation isn’t free. Every handoff adds coordination overhead, tool calls, and wait time. If an agent delegates too eagerly, the “help” can become friction.  

We recently released an improvement to our agentic harness called smarter subagent delegation. This makes Copilot CLI more selective by helping the main agent:  

• Stay focused when it can move faster on its own.
• Delegate when a specialist creates real leverage.
• Parallelize work when tasks are truly independent.

Smarter subagent delegation has now rolled out to 100% of Copilot CLI production traffic. If you want to get started today, simply update GitHub Copilot CLI by running the /update command in your terminal to version 1.0.42 or later. 

In a production A/B test, this improvement reduced tool failures per session by 23%, including a 27% reduction in search tool failures and an 18% reduction in edit tool failures. It also improved total user wait time by 5% at P95 and 3% at P75, with no quality regression. Here, P95 captures wait time near the slowest 5% of sessions, while P75 reflects wait time toward the slower end of typical sessions. This means fewer unnecessary handoffs, fewer repeated searches, fewer failure-prone tool paths, and less waiting during long-running coding tasks. 

In this post, we’ll walk through how we identified unnecessary delegation in Copilot CLI, what we changed to make delegation more selective, and how we validated those changes through offline evaluation and production A/B testing. We’ll also show why those changes led to fewer failures and less waiting—and what that looks like for developers using Copilot CLI day to day. 

The problem: Delegation is powerful, but not free

Subagents are one of the most important capabilities in an agentic CLI. They let Copilot break down complex work, run investigations in parallel, and keep the main agent focused on coordinating the final answer. For large codebases and multi-step engineering tasks, that can be the difference between a slow linear workflow and an efficient parallel one. 

But delegation introduces its own failure modes: 

• Unnecessary handoffs for simple tasks that the main agent could complete faster on its own. 
• Overuse of exploration subagents when the handoff already contains enough context.
• Repeated or overlapping searches across the main agent and subagents. 
• Sequential delegation, where the main agent waits for a subagent instead of treating delegation as an opportunity for parallel work. 
• Failure-prone subagent paths, including stale file paths, moved files, incorrect relative paths, and workspace mismatches.  

Our goal: help developers use subagents when they create leverage, avoid them when they add overhead, and parallelize work when the task genuinely benefits from independent execution. 

From problem signals to shipped improvement

The way we identified the problem became the way we solved it. Instead of treating agent trajectory analysis, product changes, evaluation, and rollout as separate activities, we used them as one feedback loop: observe the agent behavior, isolate the orchestration bottleneck, make a targeted change, validate it offline, measure it online, and ship only once the end-to-end workflow improved. 

1. Analyze: Let LLMs identify the delegation bottleneck

Instead of manually reviewing agent sessions, we used LLMs to analyze full trajectories and identify where orchestration was helping versus where it was adding overhead. That analysis surfaced a consistent pattern: subagents were sometimes being invoked for tasks that were already narrow, obvious, or fully described in the handoff. 

In those cases, the subagent could spend time re-searching the repository even though the main agent already had enough context to act directly. That clarified the improvement target: keep simple discovery-and-edit tasks in the main agent, and reserve subagents for work that is broader, cross-cutting, or naturally parallelizable. 

2. Change: Refine the orchestration policy

After identifying the bottleneck, we used LLMs to help translate that diagnosis into a more selective orchestration policy.

Copilot CLI should handle focused work directly: find a file, read it, make a targeted change, and verify it. Delegation is more useful when the work requires independent context, broad exploration, or parallel execution.

In practice, that means starting with the narrowest effective path, escalating when complexity or uncertainty creates value, and stepping back down when the task becomes focused again. Subagents should be treated as a parallelism tool, not a pause button. When Copilot launches a subagent, the main agent should continue making progress on independent work rather than simply waiting for the result.

When a subagent is used, the handoff should also be specific: what the user asked, what is already known, what the subagent owns, and what kind of result the main agent needs back. 

3. Validate: Test offline, confirm online, then ship

Before broad rollout, we validated the change with automatically generated regression cases and existing benchmarks. This helped confirm that the new delegation guidance reduced avoidable overhead without breaking cases where subagents genuinely add value. 

Finally, we moved through staff and public A/B testing, then analyzed production metrics across reliability, responsiveness, subagent workload, and quality. The gains did not come primarily from making individual LLM calls faster. Instead, it reduced orchestration overhead by avoiding unnecessary subagent paths and lowering subagent workload per user. 

That end-to-end process let us move from problem signal to shipped improvement while keeping the user experience stable: fewer avoidable handoffs, fewer failure-prone tool paths, and no quality regression. 

Outcomes

After rolling smarter subagent delegation to production traffic, we saw measurable percentage improvements across reliability and responsiveness (Table 1): 

Dimension	Metric	Delta
Reliability	Tool failures per session	23% reduction
Reliability	Search tool failures	27% reduction
Reliability	Edit tool failures	18% reduction
Responsiveness	Total user wait time at P95	5% lower
Responsiveness	Total user wait time at P75	3% lower
Quality	Quality metrics	No regression

Metric	Delta vs. control	Interpretation
Failed raw subagent search calls	15% reduction	Reliability – fewer failure-prone subagent search paths.
Average subagent LLM duration per user	12% lower	Responsiveness – reduced orchestration overhead per user.
P95 subagent LLM duration per user	18% lower	Responsiveness – better worst-case subagent overhead.

These results show that better orchestration can improve the developer experience even when the visible feature surface doesn’t change. By teaching Copilot CLI when to delegate, when not to delegate, and how to parallelize the right work, we reduced friction in the agent loop itself. 

That is the power of GitHub Copilot as a system: the experience gets better not because developers are given more switches to manage, but because Copilot becomes better at allocating models, tools, and subagents behind the scenes. 

How this benefits developers today

For developers using Copilot CLI, this should feel like a smoother day-to-day experience. Straightforward tasks are more likely to be handled directly, complex tasks still get specialist help when it adds value, and long-running sessions keep moving with less unnecessary waiting. In practice, Copilot CLI becomes more efficient and less noisy without asking developers to work differently. 

The change is intentionally behind the scenes. Your workflow stays the same, but Copilot CLI is better at coordinating the work: fewer unnecessary handoffs, less repeated search work, fewer failed tool paths, and faster progress on long-running or multi-step tasks. 

What’s next

This work is one step toward our larger goal of improving how Copilot CLI chooses the right model, agent, and tools across your workflow. While having more agents and models available expands what Copilot can do, the value to developers depends on how well Copilot applies them across the work they are already doing, like reading files, running commands, and moving from an issue toward a pull request. 

As tasks become more complex, the quality of that orchestration matters more. The best system is not the one that delegates the most, but the one that knows when to act directly, when to delegate, and how to keep work moving without adding friction. 

The next step is making Copilot CLI more adaptive across models, agents, skills, and tools, so developers don’t have to decide whether a task needs a larger model, a specialist subagent, or a procedural skill. Copilot should make that decision based on the task, repository context, policy, and expected outcome. 

We will continue improving how Copilot CLI plans work, coordinates subagents, and measures end-to-end outcomes. That includes better visibility into main-agent and subagent behavior, deeper analysis of failure reasons, and stronger proxy metrics for orchestration quality. The goal is simple: less waiting, fewer avoidable failures, and more useful progress from every agent session. 

Get started today and share feedback

Update GitHub Copilot CLI by running the /update command in your terminal to version 1.0.42 or later.  

Already tried it? We’d love to hear what you think. Share feedback with the /feedback command in a CLI session or open an issue in our public repository. 

Acknowledgements

Smarter subagent delegation was made possible by collaboration across Code|AI, Copilot CLI, experimentation, human evaluation, and product teams. Thanks to everyone who helped identify the problem, design the process, validate the outcome, and ship the improvement to production. 

The post How we made GitHub Copilot CLI more selective about delegation appeared first on The GitHub Blog.

Picture this. A user types something sensitive into Copilot. Now you're left wondering what happens to it, how to prevent it from going out, and what to do after the fact.

That's a conversation I have with customers a lot. How do you get proactive about securing what goes into Copilot and stop sensitive information from going out, instead of just cleaning up after it happens.

Copilot's web grounding sends prompts out to Bing Search when it needs more context to answer a question. That's useful. It's also the problem, because once a prompt crosses your tenant boundary to Bing, it sits outside the privacy and security terms in your Microsoft agreements.

For a while, the fix was to turn off web grounding entirely. That closed the gap but left users with a weaker Copilot.

Microsoft's answer was to extend Purview's data loss prevention into Copilot prompts, giving IT teams the proactive controls they've been asking for. I talked through this with Arlie, one of our Purview solutions engineers and a former CISO, and walked through how it works.

I sar down with Principal Solution Engineer Arlie Hartman to talk about DLP for Copilot Prompts

 

 

Two ways to block a prompt

The first version Microsoft shipped stops Copilot from processing a prompt at all. If the prompt matches a DLP rule, conditioned on a sensitive information type or a custom keyword list, the user gets a flat response: "This request cannot be completed because your organization has blocked Copilot from processing or responding."

That worked, but customers wanted more. They wanted Copilot to keep reasoning and responding using its existing knowledge and whatever's already in the tenant's Microsoft Graph data, just without invoking a web search. So Microsoft added a second action: block web grounding only. Copilot still answers, but tells the user it can't use web search because of the org's security policy.

Building the policy

You build this as a DLP policy in Purview, scoped to the Microsoft 365 Copilot and Copilot Chat workload, then scoped to users or groups. Inside the policy, you create rules made of a condition and an action: if the prompt contains a sensitive information type, a custom keyword list, or matches a sensitivity label, then either block the prompt or block web search.

One catch worth knowing up front: each rule can only take one of those two actions, and you can't combine a sensitivity label condition with a sensitive information type condition in the same rule. If you want both, build two policies. Arlie splits these out: one policy for keyword-based blocking, one for sensitivity-label-based web search restriction.

Sensitivity labels add another layer. Tag a document "Highly Confidential" and you can stop Copilot from touching it at all, or let it summarize and reformat that document but never let it trigger a web search from that content.

What you can see in the logs

With the full Purview suite, every Copilot interaction lands in Activity Explorer under AI activity. You can see the prompt, the matched rule, the confidence score, and whether it got blocked or just flagged. Filter by policy and date range to see how a rule is performing.

That's where simulation mode comes in. Before turning a rule on for real, run it in simulation for a week or so. You'll get the DLP violation logged without blocking anything for the user. Tune the rule until you're catching real violations without burying your admins in false positives.

Licensing

DLP for Copilot prompts requires Information Protection and Governance, one of the mini-SKUs that make up the Purview suite under E5. E3 won't get you there.

One policy covers both Copilot Chat and full Microsoft 365 Copilot. Roll out Copilot Chat broadly on E5 but only license some users for full Copilot, and the DLP policy still applies to everyone, regardless of which Copilot license they're on.

Where this fits

Most security around AI tools has been reactive: something goes out, you audit it, you coach the user after the fact. This gives IT teams a way to balance user ability with protection of the organization, stopping sensitive data from leaving in plain text before it happens, while users still get value from Copilot.

If you're on E5 and haven't looked at this, set up one policy in simulation mode this week and see what you're working with.

898. Randall Munroe joined me last October to talk about his language-themed xkcd cartoons, his simple-language project Up Goer V, his biggest pet peeve, his favorite words, and his new book "What If? 2." But I have to confess that my favorite part was his tidbits about the bee laws.

Encore Episode: This episode originally aired in October of 2022.

🔗 Join the Grammar Girl Patreon.

🔗 Share your familect recording in Speakpipe or by leaving a voicemail at 833-214-GIRL (833-214-4475)

🔗 Watch my LinkedIn Learning writing courses.

🔗 Subscribe to the newsletter.

🔗 Find a transcript on your podcast app or QuickandDirtyTips.com

🔗 Get Grammar Girl books.

| HOST: Mignon Fogarty

| Grammar Girl is part of the Quick and Dirty Tips podcast network.

• Audio Engineer: Dan Feierabend
• Director of Podcast: Holly Hutchings
• Advertising Operations Specialist: Morgan Christianson
• Marketing and Video: Nat Hoopes, Rebekah Sebastian
• Podcast Associate: Maram Elnagheeb

| Theme music by Catherine Rannus.

| Grammar Girl Social Media: YouTube. TikTok. Facebook. Threads. Insta

---

Hosted on Acast. See acast.com/privacy for more information.

Download audio: https://sphinx.acast.com/p/open/s/69c1476c007cdcf83fc0964b/e/6a2b20a9479dfe546fc1ce65/media.mp3