Visual Studio Code’s most notable change is not a new editor feature. It is the move from a place where one developer asks an assistant for help to a workspace where multiple agent sessions can be started, continued, compared, and reviewed. ToolVitals pairs that product shift with 2,200 GitHub commits in 30 days, a 98 health score, and a 99 shipping score. The result is a project that looks less like an editor adding AI and more like an editor being reorganized around agent work.
The product positioning now centers on agents
The official VS Code site now calls the product an open-source AI code editor and presents it as a home for multi-agent development. Its current description is broader than autocomplete. It talks about agents that plan, code, and debug, with workflows that span Linux, macOS, Windows, the web, and the Insiders edition.
The homepage also describes handing tasks to agents that autonomously plan work, change code, run commands, and iterate until the task is complete. That language places orchestration inside the editor itself. The editor is no longer only the surface where a developer writes and reviews code. It is becoming the place where different agent sessions are assigned, monitored, and brought back into the normal development loop.
The GitHub repository supplies the other half of the picture. It describes Visual Studio Code as combining a simple code editor with the tools needed for the edit-build-debug cycle. The repository lists code editing, navigation, code understanding, lightweight debugging, an extensibility model, and integration with existing tools as core capabilities. The agent work is being added to that base rather than replacing it.
That distinction matters for engineering teams. The recent releases do not describe an editor that has abandoned files, diffs, terminals, extensions, or debugging. They describe an editor that is adding session management, agent hosts, browser interaction, subagents, and portable agent packages around those existing activities.
The licensing boundary needs precise language. ToolVitals classifies Visual Studio Code as OSI-approved OSS and reports an MIT license label. The GitHub repository says the source project, Code - OSS, is developed by Microsoft with the community and is available under the MIT license. The same repository says that Visual Studio Code is a distribution of Code - OSS with Microsoft-specific customizations released under a traditional Microsoft product license.
That means the repository supports calling Code - OSS open source under the MIT license, and ToolVitals supports describing the tool as an OSI-approved open-source tool. It does not support treating every component or distribution detail as identical to the repository. Teams evaluating the product should keep the source repository and the branded distribution as separate licensing objects.
The repository also says that Microsoft publishes a roadmap, monthly iteration plans, and endgame plans in the project. It documents how to build and run from source, how to debug and test, and how to use development containers and Codespaces. Those are useful signals for a team that wants to inspect the project or contribute, but they are not proof that every part of the product is equally open or equally easy to operate.
The metrics show scale and maintenance, not product quality
ToolVitals reports 193,669 GitHub stars, 2,200 GitHub commits in the last 30 days, 18 GitHub releases in the last 90 days, and 44 active contributors. It assigns Visual Studio Code a hot score of 209.3, a health score of 98, a shipping score of 99, and an overall ToolVitals score of 98. The payload gives the measurement a data confidence score of 90.
Each number describes a different signal. Stars indicate broad public attention. Commits indicate repository activity, but they do not distinguish between a major feature, a test change, a documentation correction, or a maintenance task. The active contributor count shows participation during the measured period, not the total number of people who have contributed to the project or the number of engineers working on the full product.
The 18 GitHub releases in 90 days show a project with frequent release activity, but release count alone says little about the importance or stability of those releases. A project can publish many small updates without improving the workflows that matter to a particular team. ToolVitals’ 99 shipping score is a strong activity signal in this dataset, not a substitute for testing the product.
There is a field-level mismatch that readers should not ignore. ToolVitals reports zero release events in the last 30 days, while the supplied event feed contains a Visual Studio Code 1.135 Insiders changelog entry dated August 25, 1.134 release and changelog entries dated August 19, 1.133 entries dated August 12, and 1.132.0 and 1.132.1 release records dated August 5 and August 11. The payload does not explain how the release-events metric reconciles RSS changelog records with GitHub release records or how its window is aligned.
The conservative reading is that release_events_30d is a separate measured field, not proof that Visual Studio Code stopped shipping. The broader data still shows 2,200 commits in 30 days and 18 GitHub releases in 90 days. ToolVitals provides the measurements, but it does not expose enough methodology to turn the zero into a stronger claim.
The related-tools comparison adds useful context. Visual Studio Code’s 209.3 hot score is below Unsloth at 232.8, Hermes Agent at 232.0, and Kilo Code at 226.5. Yet Visual Studio Code’s 193,669 stars exceed Unsloth’s 77,944 and Kilo Code’s 27,586. Hermes Agent has 253,359 stars. The comparison shows why hot score and star count should not be treated as interchangeable rankings. They capture different aspects of attention and activity, and the related tools are not direct substitutes for an editor with Visual Studio Code’s scope.
The releases show a move toward agent coordination
The Visual Studio Code 1.135 release notes make the product direction explicit. They describe continuing recent Copilot or Claude agent sessions created in other applications from inside VS Code. They introduce an experimental Rubber Duck feature for getting a second opinion from another model, and they describe a more focused Agents window with simpler session controls.
The same release gives users a per-model breakdown of input, cached input, and output tokens for each chat turn. That is not a code-generation feature by itself. It is an observability feature for agent work. Developers can see more of what a session is doing instead of treating the agent as an opaque panel attached to the editor.
Version 1.135 also makes the single-pane side layout the default for the Agents window on desktop. Diffs can use a side-by-side view when there is room and switch to an inline view when the pane is narrow. The release notes describe an agent host that lets the same session connect to multiple VS Code windows through a dedicated process based on the Agent Host Protocol.
Taken together, those changes point to a coordination layer. Sessions can persist across applications and windows. Work can be inspected through diffs. The interface exposes session details, token activity, and agent status. The editor is being shaped around the problem of supervising work that may span several agents and several files.
The 1.134 release notes push the same direction from another angle. They add side-by-side chats, including subagent chats, so related conversations can be compared in groups. They add a prompt timeline that helps users move through long sessions and identify prompts that changed files. The timeline can show added and removed line counts and open the related changes directly.
Version 1.134 also adds search across the complete conversation and previews for local HTML files through the integrated browser. These details matter because long agent sessions create a navigation problem. Generating a patch is only one part of the workflow. Finding the prompt that produced it, reviewing the diff, checking a preview, and returning to an earlier decision are part of the work as well.
The 1.133 release notes show that Microsoft is addressing portability at the package level. The notes describe Agent Plugins 1.0, an open standard that packages a plugin manifest, skills, and MCP server configuration in a common layout. VS Code can read portable components and Copilot-specific components from the same package through the com.github.copilot namespace.
That design gives maintainers a way to publish one package for more than one agent client, at least where the clients implement the relevant pieces. The release notes also describe switching model providers between turns in Claude sessions and opening the Agents window without GitHub sign-in when Claude is configured with an API key. The latter behavior is experimental, and the notes say support for other configurations is planned, so it should not be treated as a completed universal interface.
The 1.132 release notes fill in the interaction model. They describe comments on specific elements in the integrated browser, multilingual dictation using an on-device model, side chats through /btw, and experimental Markdown diffs in the hybrid Markdown editor. The Agents window exposes live status for changes, previews, subagents, and browsers while an agent works across those surfaces.
The 1.132 notes also describe agent-host harnesses such as Copilot, Claude, and Codex running in a dedicated process. Across these four release notes, the direction is consistent. VS Code is investing in session continuity, portable agent components, context management, browser feedback, and review surfaces. That is a structural shift beyond adding another completion model to the editor.
What an engineering team should test
A skeptical engineering lead should read the metrics as a reason to run a controlled pilot, not as proof that the product will work well for every team. The evidence supports evaluating the agent workflow because the first-party release notes describe concrete features for continuing external sessions, grouping subagent chats, reviewing file changes, interacting with browser previews, and packaging portable plugins.
A useful pilot would use representative repositories and existing extensions. Test external session continuation, side-by-side conversations, prompt history, integrated browser feedback, plugin loading, diff review, and recovery after an interrupted agent turn. Measure the things ToolVitals cannot measure: whether generated changes pass the team’s tests, how much review work they create, how often agents lose context, how predictable their edits are, and whether the workflow fits existing security controls.
The license distinction should be part of that evaluation. The Code - OSS repository is described as MIT licensed, while the GitHub page describes the branded Visual Studio Code distribution as containing Microsoft-specific customizations under a traditional Microsoft product license. A team should review the exact distribution and extensions it intends to deploy instead of assuming that the repository license answers every operational question.
What ToolVitals cannot tell you
ToolVitals sees repository activity, stars, release records, contributor activity, license signals, and public project evidence. It does not see code quality, user satisfaction, revenue, support quality, installation counts, or whether the agent features actually produce correct code in a particular organization.
A 98 health score cannot prove that a regression is absent. A 99 shipping score cannot prove that a release is stable. The 193,669-star count cannot prove how many developers use the product today, and 2,200 commits cannot prove that the resulting changes improved the editor. The first-party release notes establish what the project says it shipped or is developing, but they are not independent benchmarks.
ToolVitals reports data confidence of 90, but the payload does not define that value as a measure of code quality or feature reliability. It should be read as confidence in the supplied project evidence, not as an assurance that the product will meet a team’s requirements without testing.
The data also cannot settle whether the move toward multi-agent development is the right product direction. It shows that the direction is being developed and that the repository is active. It does not show whether developers prefer longer agent sessions, whether portable plugins work across clients in practice, or whether the added coordination surfaces reduce or increase review effort.
Recommendation
If your team needs an extensible editor that can host and review multiple AI-agent workflows, evaluate Visual Studio Code because its recent releases provide concrete support for external sessions, subagent conversations, portable agent plugins, browser interaction, and reviewable file changes. Use a controlled pilot with the 1.135-era Agents features, and judge the result by test outcomes, review burden, context recovery, and governance requirements.
If your team only needs a conventional edit-build-debug environment, do not choose Visual Studio Code because it has a 209.3 hot score or 193,669 stars. Those numbers show attention and activity, not fit. The strongest case is narrower and more useful: Visual Studio Code is an actively maintained OSI-approved open-source project whose current product direction is turning the editor into a coordination surface for agent-assisted development.
For maintainers, the next challenge is making that coordination model predictable. The project should keep the Agent Host Protocol, Agent Plugins layout, session import behavior, provider boundaries, and diff workflows clearly documented and tested. The public repository already exposes roadmap and iteration planning. Keeping those plans aligned with the growing agent surface would help contributors understand which interfaces are stable, which are experimental, and where the project wants outside participation.