Skip to main content

Keep your context short - Manual compaction is now available in VS Code

In my earlier posts about the GitHub Copilot CLI, I already introduced the /compact command, a slash command that summarizes your conversation history to free up context space, letting you keep working in the same session without losing momentum. Well, good news! It's no longer CLI-only.

The February 2026 release of VS Code brings /compact directly into the editor, and it's part of a much broader story about making agents actually usable for the kind of long, messy, real-world tasks developers deal with every day.


The Context Window problem

Here's what happens without context compaction: you start an agent session, ask it to dig into a complex feature, go back and forth a few times, and eventually the conversation grows so large that the model starts losing the thread, or the session simply stops. You're forced to start over, re-explain everything, and lose all the accumulated understanding the agent had built up.

Context compaction solves this by summarizing older parts of the conversation into a compact form, preserving what matters while freeing up space for what comes next. VS Code already supported automatic compaction that kicks in when the context window approaches its limit.

But the February release added support for manual compaction: you can now type /compact whenever you want to proactively clean things up — before the window fills, before switching focus, or before handing a session off to a cloud agent. Manual compaction is available for local, background, and Claude agent sessions.

You can view what is already in the context by hovering over the context window control:


Pro tip: When executing the compaction, you can give the agent hints on what to keep and what to throw away.

Agents trustworthiness

Long-running development tasks — the kind that span hours, involve multiple files, and require back-and-forth — are exactly where agents historically fall apart. Context limits, loss of state, and brittle session management all make it hard to trust an agent with anything that isn't a short, self-contained task.

Manual /compact, session memory, steering mid-flight, and persistent plans are all targeted at this exact problem. They don't make agents perfect, but they make them significantly more trustworthy for the work that actually takes time.

If you've been skeptical about agents for anything beyond quick one-shot tasks, the 1.110 release is worth revisiting. The /compact command in VS Code is a small addition, but it signals something larger: a serious effort to make agentic development practical for real codebases and real workflows.

More information

GitHub Copilot CLI Tips & Tricks — Part 2: Session management

Making agents practical for real-world development

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...

Cache stampede: when our cache turned against us

While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.