Four consecutive Visual Studio Code updates point to a specific product shift. The editor is being organized around multi-agent work, not just augmented with another coding assistant. Versions 1.132 through 1.135 add session continuity, subagent visibility, browser feedback, provider switching, portable agent plugins, chat timelines, and per-model usage details. ToolVitals recorded 1,883 commits in 30 days, a 99 health score, and a 99 shipping score during the same broad period. The result is a project moving quickly toward an agent workbench while maintaining the operating discipline of a mature editor.
The product is moving from editing code to coordinating work
The official Visual Studio Code site now positions the product as an open-source AI code editor and a home for multi-agent development. Its description focuses on agents that plan, code, and debug, along with workflows that span Linux, macOS, Windows, and the web. The site also describes handing tasks to agents that can make code changes, run commands, and iterate on the result.
The GitHub repository gives a broader description. It frames Visual Studio Code around the edit-build-debug cycle, code navigation and understanding, lightweight debugging, integration with existing tools, and a rich extensibility model. That description still matters because it explains the foundation beneath the newer agent features. VS Code is not starting as an agent shell. It is adding agent coordination to an editor that already treats extensions, language support, debugging, and tool integration as core product surfaces.
The release notes show the coordination problem Microsoft is choosing to solve. Agents work across files, chats, terminals, previews, browsers, model providers, and sometimes other applications. A useful editor therefore needs more than a prompt box. It needs a way to find a past session, inspect changes, compare parallel work, offer feedback in context, and resume work without losing state.
That is the central inference from the first-party material. VS Code is turning the editor window into a control surface for software work performed by both people and agents. The evidence supports that direction, but it does not prove that every agent workflow is reliable or that every harness behaves the same way.
The Agent Host is part of this architecture. The 1.134 and 1.135 notes describe agent harnesses running in a dedicated process based on the Agent Host Protocol. The 1.135 notes say the host can connect the same agent session to multiple VS Code windows, while the 1.132 notes name Copilot, Claude, and Codex as harnesses used with the host. This gives the agent work a process boundary and a session model instead of treating every interaction as an isolated editor command.
The repository also says that many core components and extensions live in separate repositories. Built-in extensions cover grammars, snippets, and language features, while the main project provides the editor platform. That split helps explain why extensibility remains central to the product direction. Agents can be added without discarding the extension and tool integrations that developers already depend on.
Open source, with a licensing boundary teams should read carefully
ToolVitals classifies Visual Studio Code as OSI-approved OSS and gives it an MIT license label. Under that classification, calling the tool open source is accurate. The project itself also uses open-source language on its homepage.
The repository adds an important qualification. Microsoft develops Code-OSS in the microsoft/vscode repository with the community, and the repository source is available under the standard MIT license. The repository then says that the Visual Studio Code distribution is built from Code-OSS with Microsoft-specific customizations released under a traditional Microsoft product license.
That distinction is material for engineering teams that plan to fork, redistribute, or audit the exact artifact they deploy. The ToolVitals openness field is the source of truth for the editorial classification, while the repository’s own description is the source for the Code-OSS and distribution boundary. A procurement or platform team should review those two layers directly instead of treating the MIT label as a description of every shipped component.
The repository also publishes roadmap, monthly iteration, and endgame material, according to its project description. That is a useful sign for contributors because the project presents more than a source tree. It exposes planning and contribution paths, including issue reports, documentation changes, and direct code work.
ToolVitals measures an unusually active mature project
ToolVitals reports a 245.5 hot score for Visual Studio Code. Its health score is 99, its shipping score is 99, and its overall ToolVitals score is 99. The project has 191,516 GitHub stars, 1,883 GitHub commits in the last 30 days, 18 GitHub releases in the last 90 days, 47 active contributors, and 6 release events in the last 30 days. ToolVitals assigns the dataset a confidence score of 90.
The surprising signal is the combination of scale and motion. A project with 191,516 stars can coast on reputation for a long time. These measurements do not show that happening. The commit count and release activity show an actively maintained codebase, while the health and shipping scores indicate that ToolVitals sees both maintenance quality and delivery activity as strong.
The numbers still need careful interpretation. A commit is not automatically a user-visible feature. The 1,883 commits can include tests, documentation, refactoring, merges, fixes, and internal changes. Six release events in 30 days do not mean six major product launches. The 18 releases in 90 days also describe repository shipping activity, not the number of changes that materially improve a developer’s daily work.
The 47 active contributors provide a second useful signal, but not a complete community analysis. ToolVitals does not expose the distribution of work among those contributors, the number of outside maintainers, or the health of individual extensions. The star count signals public attention, not active installations, retention, or successful adoption inside a company.
The 90 confidence score is also not a product-quality score. It indicates confidence in the ToolVitals data, not confidence that an agent will produce correct code or that the editor will fit a particular organization’s policies. A 99 score is a strong activity and health signal. It is not a substitute for an engineering evaluation.
The related-tools comparison changes the story
Visual Studio Code is not the highest-hot-score developer tool in the supplied related set. ToolVitals lists Hermes Agent at 257.4, Orca at 256.7, Kilo Code at 256.4, and LiteLLM at 256.1, all above VS Code’s 245.5. Those entries are related tools, not proven like-for-like competitors, so the comparison should not be read as a feature benchmark.
The attention and shipping figures also point in different directions. Hermes Agent has 243,644 GitHub stars, a 100 shipping score, and 5 release events in 30 days. Orca has 64,981 stars, a 99 shipping score, and 15 release events in 30 days. Visual Studio Code has fewer stars than Hermes Agent in this payload, but more recent release events than Hermes Agent and the same shipping score as Orca.
The safe inference is that the hot score is not a simple ranking by stars or release events. ToolVitals does not provide the scoring formula here. Visual Studio Code’s case therefore rests less on leading every activity metric and more on the sustained combination of repository scale, recent releases, and a 99 overall score.
The release sequence is a roadmap in miniature
The Visual Studio Code 1.132 notes describe features that make agent interaction more precise. Users can comment on individual elements in the integrated browser, use multilingual dictation with an on-device model, open side chats with /btw, and review Markdown diffs in the hybrid Markdown editor. The browser commenting feature is especially revealing because it turns visual feedback into structured input for an agent. Instead of describing a page problem in general terms, a user can attach feedback to a specific element.
The same release introduced live status pills for changes, previews, subagents, and browsers in the Agents window. That is an observability feature for an interactive workflow. The user can see where an agent is working and return to related artifacts without abandoning the main session. The 1.132.1 patch was listed as addressing security issues, but the supplied excerpt does not identify those issues or describe their severity. ToolVitals records the 1.132.0 and 1.132.1 GitHub release events, but those events do not provide enough evidence for a security assessment.
The 1.133 notes move toward provider and package interoperability. Claude sessions can change model providers between turns, and an experimental setting allows the Agents window to open without GitHub sign-in when Claude is already configured with an API key. The release also adds support for the Agent Plugins 1.0 standard.
The plugin format is designed to keep portable components in one package. The notes describe a plugin.json manifest, skills/, and mcp.json for portable components, plus a com.github.copilot namespace for Copilot-specific agents, commands, rules, and hooks. That arrangement lets other clients ignore the client-specific namespace while still using the portable pieces. The broader direction is clear: agent customizations should be installable across clients rather than rewritten for every tool.
The 1.134 notes focus on long-session navigation and review. Users can arrange related chats and subagent chats side by side, use a prompt timeline to jump through a conversation, find text across the complete chat, and preview local HTML files in the integrated browser. The prompt timeline also identifies prompts that changed files and exposes the associated changes for review.
That is a meaningful shift in emphasis. An agent can generate a large amount of context, but a development tool becomes useful only when a person can inspect that context without losing their place. Side-by-side chats, searchable transcripts, and change-aware timelines address that review cost directly.
The 1.135 notes, listed in the ToolVitals event data as an Insiders changelog entry on August 25, extend the same line of work. External Copilot or Claude sessions created in other applications can appear in the Sessions list and continue in VS Code. The experimental Rubber Duck feature asks a complementary model for a second opinion, while the Agents window receives a streamlined side layout and simpler session controls.
Version 1.135 also adds detailed chat usage with a per-model breakdown of input, cached input, and output tokens. That is not a pricing claim. It is a visibility feature that helps teams understand how a multi-turn workflow consumes model context. The notes say the release is rolling out gradually and point users who want earlier updates to the nightly Insiders build.
Read chronologically, the releases form a coherent roadmap. Version 1.132 improves feedback and live status. Version 1.133 expands providers and portable plugins. Version 1.134 improves navigation and review. Version 1.135 connects sessions across applications and adds a second-opinion path. The project is investing in context continuity, interoperability, and oversight around agent actions.
What the data does not tell you
ToolVitals can measure repository activity, active contributors, releases, license signals, public project evidence, and its own health and shipping indicators. It cannot see whether the code is easy to maintain, whether the integrated browser behaves correctly under real workloads, or whether an agent’s changes are safe without close review.
The official site and release notes describe intended capabilities. They do not establish task-level success rates, latency, extension compatibility, model quality, or failure recovery. The presence of a feature called Rubber Duck does not show that the second opinion catches important defects. An external-session feature does not show that context is preserved correctly in every case.
The metrics also cannot show user satisfaction, revenue, or product economics. Stars are not usage. Commits are not quality. Release events are not proof that a feature shipped without regressions. The payload contains enough evidence to call Visual Studio Code highly active and well maintained by ToolVitals’ measures, but not enough to claim that it works well for every team.
A security-sensitive organization should be equally careful with the 1.132.1 note. The official page confirms that the patch addressed security issues, but the excerpt does not include the affected components, exploitability, or remediation details. That is evidence of a security maintenance event, not a complete security finding.
A practical test for skeptical engineering leads
A skeptical buyer should evaluate Visual Studio Code as both an editor and an agent session system. Use a representative repository with the team’s real extensions, build commands, browser previews, and review practices, then test session continuation, provider switching, subagent visibility, generated diff inspection, and recovery after an interrupted task. Measure task completion, manual correction time, review time, extension failures, and whether engineers can reconstruct what the agent changed. Keep experimental features in a controlled pilot until the organization’s authentication, source handling, and review policies are satisfied.
That test separates the product evidence from the adoption decision. The 99 health and shipping scores justify putting VS Code on the shortlist. They do not justify skipping a workflow trial.
What maintainers should measure next
For maintainers, the immediate challenge is not demonstrating that VS Code can ship. The 1,883 commits, 6 release events in 30 days, 18 releases in 90 days, and 99 shipping score already make that case. The harder task is keeping the growing agent surface understandable as sessions, providers, plugins, browsers, subagents, and external applications meet in one product.
The project should make the boundaries between stable and experimental features easy to find, especially for the Agent Host, Rubber Duck, Markdown diffs, and signed-out Claude workflows. Documentation around the Agent Host Protocol, plugin namespaces, provider authentication, session portability, and failure recovery will matter as much as the next feature. With 47 active contributors recorded by ToolVitals, clear ownership and compatibility guidance can help ensure that high repository motion does not turn into a confusing user experience.
Recommendation
If your team needs an extensible editor and wants agents to work across sessions, windows, browsers, and provider boundaries, evaluate Visual Studio Code. Use the 1.134 feature set as a baseline and test the 1.135 rollout separately, because the latest notes describe gradual availability and several features remain experimental. Choose it when session continuity and reviewability are central requirements, but do not use its 191,516 stars or 99 ToolVitals score as evidence of autonomous code correctness. Run task-level tests on your own repositories before making it the team’s default agent workbench.