Building autonomous AI agents that mutate production state requires moving beyond soft system prompts to a robust zero-trust architecture. To secure Google Agent Development Kit (ADK) workflows against prompt injections and malicious execution, developers must implement hardware-backed cryptographic signatures for database writes, kernel-level sandboxing with gVisor for dynamic code, and deterministic semantic gateways for I/O validation. By enforcing these hard security boundaries at the infrastructure level, you can safely deploy multi-tool AI agents without risking unauthorized data manipulation or server compromise.

In this tutorial, I’ll show you how to scale LLM inference for AI agents using vLLM. I'll help you build an intuition for how LLM inference works, explore why agent workloads create GPU scheduling and memory pressure, and examine how vLLM is designed to improve throughput.

We’ll then run a local vLLM server and connect to it through its OpenAI-compatible API using an AI agent.

Table of Contents

• Background

• Prerequisites

• What Is LLM Inference?

• How LLM Inference Uses the CPU and GPU

• Why AI Agent Workloads Are Hard to Serve

• How vLLM Serves Agent Workloads

• Motivation and Architecture

• Step 1: Install vLLM

• Step 2: Start the vLLM Server

• Step 3: Connect Your AI Agent to vLLM

• Step 4: Run the Agent

• Sample Output

• Why KV Caching, PagedAttention, Continuous Batching and Prefix Caching Matter

• When Should You Use vLLM?

• Conclusion

Background

A simple AI agent usually works fine with one user, one request, and one model response. But production environments look very different.

Imagine hundreds of users sending prompts at the same time. And user requests can easily turn into 10 to 30 separate LLM calls for planning, tool selection, summarization, retries, and final response generation. Multiply that across dozens or hundreds of users, and the inference layer quickly becomes the bottleneck.

Prerequisites

To follow this tutorial, you should be comfortable with basic Python and terminal commands. You should also have Python, a package manager such as pip or uv, and a code editor installed.

Some familiarity with LLM prompts and API clients will help, but no prior experience with AI Agents, vLLM or inference optimization is required. To learn more about AI Agents, you can read this article.

This tutorial uses vLLM-Metal so the example can run locally on Apple Silicon. This tutorial works on macOS, Windows, and Linux. I’m using a MacBook Pro with 32 GB of RAM without an external GPU, but the workflow can also run on more limited hardware by using a smaller pre-trained model.

What Is LLM Inference?

Inference is the process of using a trained model to generate output from an input. For a large language model, this means processing a prompt and predicting the output one token at a time.

Inference is different from training. During training, the model learns by adjusting its weights. During inference, those weights remain fixed, and the model uses what it has already learned to generate a response.

Although the model is no longer learning, inference can still be expensive. Larger models require more memory and computation, longer prompts take more work to process, and longer responses require more generation steps. When many users submit requests concurrently, the inference layer can quickly become a performance bottleneck.

How LLM Inference Uses the CPU and GPU

A model-serving system has two broad responsibilities: coordinating requests and executing the model.

On the host side, the serving system accepts requests, tokenizes prompts, tracks request state, and decides which requests should be included in each execution step. On the accelerator side, usually a GPU, the model performs the tensor operations needed to process prompts and generate tokens.

LLM inference consists of two primary phases: prefill and decode.

During prefill, the model processes all the tokens in the input prompt. Because many prompt tokens can be processed in parallel, prefill tends to be compute-intensive. A long prompt containing conversation history, retrieved documents, or tool instructions can therefore increase the time before the first output token appears.

During decode, the model generates output one token at a time. Each new token depends on the tokens that came before it, making generation sequential across decoding steps. So a long response requires many separate model-execution steps.

In simple terms:

• Long inputs make prefill more expensive.

• Long outputs make decode more expensive.

• More concurrent requests increase both scheduling and memory pressure.

The GPU is limited by both compute capacity and memory. It must hold the model weights, temporary execution data, and the state associated with active requests.

One of the most important pieces of request state is the KV cache. During attention, the model creates key and value representations for previously processed tokens. Storing those representations allows the model to reuse them while generating subsequent tokens instead of recomputing the entire sequence during every decoding step.

KV caching makes autoregressive generation practical, but it also consumes memory. As prompts and generated responses grow, each active request requires more KV cache space. This means that available KV cache memory can directly affect how many requests the server can process concurrently.

Why AI Agent Workloads Are Hard to Serve

AI agents amplify these inference challenges because one user request may trigger many model calls.

An agent might call the model to plan its next action, select a tool, interpret a tool result, summarize retrieved information, recover from an error, or decide whether more work is needed or generate the final response.

A single user interaction can become 10, 20, or even more inference requests. When dozens or hundreds of users are active, the number of model calls grows quickly.

Agent requests are also uneven. One request might contain a short question, while another includes a long system prompt, conversation history, retrieved documents, and several tool results. Their generated responses can also vary significantly in length.

This creates a dynamic workload in which requests arrive at different times, consume different amounts of memory, and finish at different times. Serving these requests efficiently requires more than simply loading a model onto a GPU. The serving layer must continuously schedule work, manage memory, and prevent short requests from being unnecessarily delayed by longer ones.

How vLLM Serves Agent Workloads

vLLM is an open-source inference runtime and serving engine designed for large language models. It exposes an OpenAI-compatible API while managing model execution, request scheduling, batching, and KV cache memory.

Instead of loading the model directly inside the application and calling a method such as model.generate(), the application sends an HTTP request to the vLLM server. This separates the application or agent logic from the inference infrastructure underneath it.

When multiple requests are active, vLLM schedules them together instead of processing each request through an isolated model loop. This allows the serving layer to use the available accelerator more efficiently.

Several vLLM features are particularly relevant to agent workloads:

• Continuous batching updates the active batch as requests arrive and finish. When one request completes, another can take its place in a subsequent execution step without waiting for every request in the original batch to finish.

• PagedAttention manages KV cache memory in fixed-size blocks rather than requiring each request to occupy one large contiguous region. This reduces memory fragmentation and makes freed cache blocks easier to reuse.

• Automatic prefix caching allows requests with matching prompt prefixes to reuse existing KV cache blocks. This can be valuable when agent requests share the same system prompt, tool definitions, conversation history, or retrieved document.

• OpenAI-compatible APIs allow existing applications and agent frameworks to connect to vLLM with relatively small config changes.

Ordinary KV caching is a standard part of modern autoregressive inference. vLLM’s advantage comes from how it schedules requests and manages, allocates, and reuses KV cache memory across concurrent workloads.

Prefix caching specifically reduces repeated work during the prefill phase. It doesn't make the generation of new output tokens faster, so its benefit is greatest when requests share long prefixes.

Together, these optimizations make vLLM useful when an agent application moves beyond a single-user prototype and begins handling concurrent, uneven, and memory-intensive inference workloads.

Motivation and Architecture

Once an AI agent starts handling concurrent traffic, model inference can become one of its main performance bottlenecks. The agent may spend most of its time waiting for the model to process prompts and generate tokens.

Instead of rewriting the agent logic, you can improve the model-serving layer underneath it. This is where vLLM fits: it provides an OpenAI-compatible inference server designed to process concurrent requests efficiently through features such as continuous batching and KV cache management.

The request flow looks like this:

User sends prompt
          ↓
Agent sends an OpenAI-compatible request
          ↓
vLLM receives request and schedules the request
          ↓
Prompt enters continuous batch
          ↓
Prefill processes the prompt and populates the KV cache
          ↓
Decode generates tokens while reusing the KV cache
          ↓
vLLM returns the generated response
          ↓
Agent receives final text

When multiple requests arrive concurrently, vLLM can combine compatible work into continuously changing batches. New requests can enter as earlier requests finish, helping improve hardware utilization and overall throughput.

Step 1: Install vLLM

Standard vLLM installations are primarily designed for Linux systems with supported accelerators such as NVIDIA GPUs. On an Apple Silicon Mac, you can use vLLM-Metal, a community-maintained vLLM hardware plugin that uses MLX and Apple’s Metal framework.

$ curl -fsSL https://raw.githubusercontent.com/vllm-project/vllm-metal/main/install.sh | bash

$ source ~/.venv-vllm-metal/bin/activate

$ pip install openai

The official docs provide platform- and environment-specific installation notes, especially for GPU and CUDA setups (read more here in the docs).

Step 2: Start the vLLM Server

Now start the OpenAI-compatible server with a model:

vllm serve mlx-community/Qwen2.5-0.5B-Instruct-4bit --host 127.0.0.1 --port 8000

The vllm serve command launches a local OpenAI-compatible API server for model inference.

The vLLM server will show output like below on startup:

...
(APIServer pid=35422) INFO 08-13 22:17:00 [launcher.py:99] API server: waiting for HTTP server to start
(APIServer pid=35422) INFO:     Started server process [35422]
(APIServer pid=35422) INFO:     Waiting for application startup.
(APIServer pid=35422) INFO:     Application startup complete.
(APIServer pid=35422) INFO 08-13 22:17:01 [launcher.py:105] API server: HTTP server started

Once it starts, your server will usually listen on a local endpoint like:

http://localhost:8000/v1

You can verify that the server is running and inspect the model name it exposes:

$ curl http://localhost:8000/v1/models

{"object":"list","data":[{"id":"mlx-community/Qwen2.5-0.5B-Instruct-4bit","object":"model","created":1786685135,"owned_by":"vllm","root":"mlx-community/Qwen2.5-0.5B-Instruct-4bit","parent":null,"max_model_len":32768,"permission":[{"id":"modelperm-b05a3fc5dd824296","object":"model_permission","created":1786685135,"allow_create_engine":false,"allow_sampling":true,"allow_logprobs":true,"allow_search_indices":false,"allow_view":true,"allow_fine_tuning":false,"organization":"*","group":null,"is_blocking":false}]}]}%                               

Step 3: Connect Your AI Agent to vLLM

Now connect your agent to the vLLM server. Since vLLM is OpenAI-compatible, you can use the OpenAI Python client and point it at your local server. Save the below file as vllm_agent.py:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="NA",
)

def ask_model(user_input: str) -> str:
    response = client.chat.completions.create(
        model="mlx-community/Qwen2.5-0.5B-Instruct-4bit",
        messages=[
            {"role": "system", "content": "You are a helpful assistant."},
            {"role": "user", "content": user_input},
        ],
        temperature=0,
    )

    return response.choices[0].message.content


print(ask_model("Why are automated tests useful?"))

You don't need a real OpenAI API key here because the request is going to your local vLLM server, not the OpenAI API.

Step 4: Run the Agent

Run the agent in a new terminal. Make sure that the vLLM server is running.

$ python vllm_agent.py

The agent will send a request to vLLM for inference. The vLLM will run inference using the model and generate the response.

Sample Output

The vLLM server log shows:

(APIServer pid=35422) INFO:     127.0.0.1:59866 - "POST /v1/chat/completions HTTP/1.1" 200 OK
(APIServer pid=35422) INFO 08-13 22:36:11 [loggers.py:310] Engine 000: Avg prompt throughput: 2.5 tokens/s, Avg generation throughput: 20.4 tokens/s, Running: 0 reqs, Waiting: 0 reqs, GPU KV cache usage: 0.0%, Prefix cache hit rate: 33.7%

The prefix-cache hit rate of 33.7% shows that 33.7% of eligible prompt-prefix tokens were found in vLLM’s cache and reused instead of being recomputed. This reduces redundant computation and saves processing time, demonstrating one of vLLM’s key performance advantages.

The agent outputs:

Automated tests are useful for several reasons:

1. Efficiency: Automated tests can be run quickly and efficiently, allowing developers to focus on other aspects of the codebase.

...

Overall, automated tests are a valuable tool for ensuring that code is well-written and that it is tested thoroughly. They can help ensure that the code is well-written and that it is tested thoroughly, which can help ensure that the code is well-written and that it is tested thoroughly.
The main benefit is not just that the response works. The real benefit is that the same agent can now sit on top of a serving layer built for higher concurrency and better GPU utilization.

Why KV Caching, PagedAttention, Continuous Batching, and Prefix Caching Matter

These features are easier to understand with a few simple calculations.

KV Cache

Inside a transformer model, the attention mechanism creates internal representations often called queries, keys, and values.

During generation, the model needs the key and value information from earlier tokens so it can attend to what came before. Instead of recomputing that information from scratch every time, the model stores it in memory. That stored state is called the KV cache.

The KV cache makes generation much faster, but it also uses GPU memory. The more tokens a request has, the more KV cache memory it needs. This is one reason long prompts, long conversations, and retrieved context can make inference much more expensive.

A rough estimate for KV cache memory per token is:

2 × number of layers × number of KV heads × head dimension × bytes per value

For a model with 32 layers, 8 KV heads, head dimension 128, and FP16 precision, the KV cache is roughly 128 KB per token. Different models will have different KV cache sizes, but the general trend is the same: longer contexts consume more GPU memory.

PagedAttention

PagedAttention is vLLM’s memory-management approach for KV cache. Instead of requiring each sequence's KV cache to occupy one contiguous region of GPU memory, PagedAttention stores it in smaller fixed-size blocks that can be allocated and reused independently.

Why does that help? In a naïve system, reserving large contiguous regions for sequences with unpredictable lengths can waste memory through fragmentation. PagedAttention divides the KV cache into fixed-size blocks that are allocated on demand and don't need to be physically contiguous. When requests finish, their blocks can be returned to the free pool and reused by other requests. This improves memory utilization and can allow the server to handle more active sequences concurrently.

Continuous Batching

Traditional batching usually works in fixed rounds. The server collects a group of requests, runs a decoding step for that batch, and keeps decoding for the same group until the batch cycle is finished. In other words, the active set of requests stays mostly fixed while the batch is being processed.

That works poorly for LLM serving because requests don't finish at the same time. A short request may finish early, but its slot may sit unused while longer requests continue decoding.

With continuous batching, the server can refill those open slots immediately. New requests can join the next decoding step as soon as space becomes available, instead of waiting for the whole batch to finish.

For example:

• Request A needs 100 output tokens

• Request B needs 20 output tokens

• Request C arrives while A is still running

With fixed batching, B may finish early, but C may still need to wait for the current batch cycle to end. With continuous batching, B frees a slot and C can join the very next decoding step. That keeps the GPU busier and improves throughput under load.

Prefix Caching

Agents often reuse the same long system prompt, tool instructions, or workflow prefix. Prefix caching allows vLLM to reuse the KV cache for a shared prompt prefix instead of recomputing it every time. The docs describe this as automatic prefix caching.

A simple example:

• shared system prompt = 800 tokens

• 50 requests all start with that same prefix

Without prefix caching, that 800-token prefix is processed 50 times:

800 × 50 = 40,000 prefix tokens processed

With prefix caching, that shared prefix can be computed once and reused, reducing repeated work substantially.

When Should You Use vLLM?

vLLM is a good fit when you:

• Self-host open-weight language models

• Serve multiple concurrent users

• Need higher inference throughput

• Run agents, chatbots, or RAG systems that make frequent model calls

• Want an OpenAI-compatible API over your own inference infrastructure

For a small, single-user prototype with light traffic, a simpler local model runner may be sufficient. vLLM becomes more valuable when inference throughput, concurrency, or KV cache memory becomes a bottleneck.

Conclusion

In this tutorial, we explored how vLLM can improve the serving layer behind an AI application. We started a local vLLM server and connected to it using an OpenAI-compatible Python client.

vLLM is designed to improve concurrent inference through continuous batching, PagedAttention, and prefix caching. The local example demonstrates the integration, while a concurrent load test is needed to measure the actual throughput and latency improvements on a particular machine.

From here, you can try another model, add load testing, or connect an existing LangChain or custom agent to the same vLLM endpoint. Happy tinkering!

If you enjoyed this tutorial, you can find more of my writing on my blog (recent posts include a system design paper series), my work on my personal website, and updates on LinkedIn.

It’s “strong opinions Monday” here at the Reading List. Check out some strong takes below.

[blog] A2A joins AAIF’s open agentic stack. We’ve been working on this for a bit. I’m glad to see the open agent-to-agent protocol migrate to this foundation.

[article] When AI Writes the Code, Specifications Need an Exit Strategy. Super interesting post. We haven’t reached industry-wide agreement on the role of specs in the software process.

[article] Research: The Innovation Problems AI Can’t Solve. One thing I took away from this is “don’t rush” and avoid cognitive surrender. Use the AI as a tool, not a substitute for thinking, seeing things for yourself, or taking ownership.

[blog] Antigravity: the busy PM’s best friend. And here are great problems that AI *can* solve. Especially with human spot-checking.

[blog] How Kenn is doing Agentic Engineering. Wonderful post about how this team works with AI. I liked the pushback on loops and dark software factories. Those things are working for some people, but it’s overhyped.

[blog] Skills Sprawl: When Too Much of a Good Thing Confuses Your AI Agent. You’ve gorged yourself on skills. Step one was recognizing it. Step two is to do something about it. Excellent post from Darren.

[blog] The SKILL.md Fallacy: Phase Transitions & Process Isolation in Coding Agents. What a write-up by Ali. He makes a strong case that we’re misusing skills and should be looking at subagents instead.

[blog] Fabled Too Hard? How I Stay Engaged in AI Development. Don’t lose your creativity or your agency just because you do AI-assisted development.

[article] Elevating Antigravity agent skills, Part 5: Subagent management. maybe you follow Ali’s above advice, but get good at learning how to manage your subagent teams.

[article] GitHub outage disrupts developers worldwide in latest setback for Microsoft coding platform. Oof. Rough day for GitHub on an issue that’s plagued them for a while now. Timing wasn’t great, as a legit competitor launched today.

[blog] The Shapes of Agent Memory – Files, Stores, and Experience. I’m not smart enough to extract all the learnings from this, but sounds like databases are better that text files when AI needs to process many conversations.

Want to get this update sent to you every day? Subscribe to my RSS feed or subscribe via email below:

Qwen 3.8 27B scores 52 on the Artificial Analysis Intelligence Index

That's the same score as GPT-5.6 Luna (max), and just one point behind GLM-5.2 (max) and DeepSeek V4 Pro 0813 (max) - that GLM is 753B and that DeepSeek is 1.6B parameters, and Luna is size unknown but presumably a whole lot bigger than 27B.

Qwen 3.8 27B is a truly astonishing model.

Via Hacker News

Tags: ai, generative-ai, llms, qwen, ai-in-china, artificial-analysis

Hi Windows Insiders, File Explorer is one of the most used experiences on Windows. It's where you get work done: organizing files, finding what you need, and moving content seamlessly across local storage and the cloud. Earlier this year, we shared our commitment to improving Windows quality, with a focus on performance, reliability, and craftsmanship. In File Explorer, that means investing in the foundational work needed to improve the experience end-to-end: reducing hangs and delays, improving responsiveness and reliability, addressing customer-reported issues, and removing friction from everyday tasks. But quality is also about continually evolving the experience to feel more modern, intuitive, and efficient for the millions of people who rely on File Explorer every day. Today we're sharing progress on both fronts. Alongside continued investments in File Explorer performance and reliability, we are introducing a substantially redesigned context menu experience that's faster, simpler, and more customizable than ever before. This new context menu experience is now rolling to Windows Insiders and represents one of several major improvements underway as we continue to modernize File Explorer.

Fewer bad moments

What people remember most are the worst moments. A single freeze while renaming a file, a slow right-click, or a Home view that flashes and reloads can outweigh dozens of smooth interactions. That reality has guided our approach to improving File Explorer. We focused on the everyday experiences people rely on most and set clear goals to make those interactions faster, more reliable, and less disruptive. Improving the moments that matter most We've profiled and invested in improving the performance and responsiveness of File Explorer. File Explorer now launches faster, and the overall experience feels more consistent and predictable. We’ve analyzed the issues behind many of the freezes, hangs, and delays users encounter, and eliminated dozens of potential stalls and interruptions in the experience.  As a result, you'll see fewer freezes and flashes when browsing, renaming files, navigating, or selecting multiple files. There are many more improvements to come, and these changes are designed to reduce disruptions and make File Explorer feel more responsive and reliable day to day.

Improving the details that matter every day

Our work extends beyond performance and reliability improvements. Many of the requests we hear from customers aren’t about major new features, they’re about the small interactions that happen every day.  We’ve continued refining File Explorer based on that feedback, removing friction and improving the details that help make everyday tasks feel more natural and predictable. For example, file renames no longer get interrupted by background file synchronization, and case-only filename changes now appear immediately. We’ve also improved navigation workflows.  The Address Bar now supports a wider range of inputs, including paths with quotation marks and double backslashes. Support for opening folders in a new tab with a middle-click has also been expanded to the Address Bar and Home page folders, making multitasking faster and more intuitive. Smaller usability improvements add up as well. Home now preserves whether sections are expanded or collapsed so you can pick up where you left off. File sizes are now displayed using appropriate units such as KB, MB, and GB, making them easier to understand at a glance. The Details pane has been reorganized so file properties are easier to find and review. Many of these improvements came directly from customer and Windows Insider feedback. They represent just the beginning of our ongoing effort to improve the everyday experiences people depend on most.

Putting you in control of the context menu

Right-clicking is one of the most common actions in Windows. If it doesn’t work as intended, or is difficult to navigate, it can derail your workflow. When we launched Windows 11, we introduced a new context menu with a modernized design, improved organization, and a new approach to application extensions. Over time, though, the menu became cluttered and sluggish, and we recognized the need to dramatically reduce the time between right-clicking and having a menu that’s fully ready to use. Today, we're excited to announce an updated context menu that delivers a faster, simpler, and more customizable experience. The new design reduces top-level clutter, keeps commonly used actions easy to access, and introduces a new Settings experience that gives you more control over what appears in the menu. [caption id="attachment_179130" align="aligncenter" width="1024"] The new right-click menu.[/caption] Faster to open The first thing you'll notice is that the menu opens much more quickly. For something used as often as the context menu, speed is part of good design. A lot of that comes from behind-the-scenes engineering improvements, and a good part comes from a cleaner default menu, with the full set of options just a click away in Settings. Clutter isn't only a visual problem; it slows the menu down because every app that adds its own options can make the menu do extra work each time it opens. Your menu, your control Part of the broader push we’re making across Windows 11 is making the operating system calmer by default, with more personalization and control. Each person uses the context menu in different ways, so we’re adding more customization to allow you to choose the layout that works best for you. At the bottom of the new context menu, you’ll now find “Customize menu”, as a shortcut to its Settings page, where you can shape the menu around your preferences, your habits, or the years of muscle memory you’ve built with a specific configuration. [caption id="attachment_179131" align="aligncenter" width="760"] The new Context Menu page in the Settings app, under Personalization.[/caption] The top section lets you turn built-in Windows commands like Send to or Create shortcut on or off. Some of these commands, like Print, weren't available in the Windows 11 context menu before and can now be switched on if you want them. The next section is about options for app extensibility, so you can choose which app extensions appear in the main menu or submenu, including hiding the submenu altogether. Finally, the last section is about where the most common commands live. We know many people have years of muscle memory from the Windows 10 menu, so we've added options to bring that feel back. You can list the main commands (Cut, Copy, Paste, Rename, Delete, and Share) inline directly in the menu instead of as a row of icons, and you can move Properties down to the very bottom. As we continue refining this experience with Insider feedback, our goal is to make right-click feel more responsive, predictable, and personal.

Building a healthier File Explorer for the long term

We are committed to continue doing the hard work and consistently improving File Explorer month after month. Not every update will be obvious on its own, but together they should make File Explorer feel faster, polished, and more dependable across tasks users do most. Your feedback continues to shape every step of this journey. Keep it coming through Feedback Hub, and we'll continue sharing our progress as this work evolves. The File Explorer team

Hello Windows Insiders, Today, we’re releasing new Windows 11 Insider Preview builds to the Beta and Experimental Channels. This post also includes reminders about renewed flight certificates and the current Feature Flags settings issue in the Experimental channel. Renewed Windows Insider flight certificates As a reminder, all new builds include renewed Windows Insider flight certificates, replacing certificates that expired on August 11, 2026. Flight certificates are renewed periodically to help ensure Insider devices remain on supported builds and continue receiving future Windows Insider Preview updates. Devices that are not updated to a newer build with a current certificate may encounter compatibility issues with software such as anti-cheat applications. For more information, please visit the certificate renewal FAQ. Experimental Feature Flags We’re investigating an issue that causes the Feature Flags settings page to appear empty for Windows Insiders in the Experimental channel. We expect to resolve it in the next Experimental build and will share updates on the blog. New builds this week We’re releasing new Windows 11 Insider Preview builds today. Select your channel below to view its release notes:

• Beta: Build 26220.9209
• Experimental: Build 26340.9212

For those on other specific build versions, here are today’s new builds and release notes:

• Beta (26H1): Build 28020.2731
• Experimental (26H1): Build 28120.2738
• Experimental (Future Platforms): Build 29648.1000

Notable new features:

[File Explorer]

Release channel: Experimental Introducing the new, redesigned Context Menu in File Explorer

• We’re beginning to roll out an updated context menu experience in File Explorer, designed to feel faster, cleaner, and easier to tailor to the way you work. The new design reduces top-level clutter, keeps commonly used actions easy to access, and adds a new Settings experience that gives you more control over what appears in the menu. As we continue refining this experience with Insider feedback, our goal is to make right-click feel more responsive, predictable, and personal.

[caption id="attachment_179130" align="aligncenter" width="1024"] The new right-click menu.[/caption]

[Emoji]

Release channel: Experimental

• We’re adding support for Emoji 17.0. This includes new emoji such as distorted face, fight cloud, and hairy creature. To try out the new emoji, you can press the Windows key plus Period (.) to open the emoji panel and insert them from there.

• As part of this effort, we’ve also made some slight adjustments the design of some of our current emoji to improve consistency across platforms. This includes the saluting face, face with peeking eye, goose, lotus, and kissing cat emoji.

Thanks, Stephen and the Windows Insider Program team