VT Code

The deciding trait is that it follows you. The same agent runs in your terminal and can be driven from inside Zed through a bridge, which means one configuration, one set of habits, and no awkward moment where the editor version behaves differently from the one you trained yourself on.

You are the wrong buyer if your editor is not that one and never will be, because half the appeal goes away and what is left is a competent terminal agent among many. Pick it if you use both surfaces. Pick an editor extension if you use one.

There is no containment. The tool executes commands and operates on your repository, and the row records no sandbox, no container option and no confinement to a directory, which means the limit on a mistake is the limit on your own account. The tagline says secure. The specification does not say what that word is doing.

What it does right is keep git in scope. Because it performs the operations itself, a session leaves a history rather than a pile of unexplained modifications.

1. The capability model is additive rather than subtractive. Web access is not present until a bridge is enabled, so the default configuration has a smaller surface than the documented one, which is the correct order and the opposite of what most products in this category do.

2. The wider architectural bet is that capability should arrive through published protocols rather than bespoke integrations, which means the tool ages with the ecosystem instead of against it.

3. No evaluation is published and none is claimed.

832 stars, a personal namespace and no commercial surface. The uncomfortable truth about this category is that quality is abundant: a dozen competent terminal agents exist, they are all free, and none of them has found anything a user would pay for that the model vendor does not already sell.

Moat: none. Likely acquirer: none, and there is nothing to buy. Likely path: maintained while it remains its author's daily tool. Position: adopt freely, contribute if you rely on it, and treat continuity as a favour rather than a commitment.

The platform list decides it before anything else does. Two desktop platforms are supported, which means a share of my engineers cannot use the thing I would be standardising on, and a standard that covers most of a team is not a standard.

Beyond that: nothing per seat, provider spend uncapped, no SSO, no audit log, no retention policy and nothing that runs in a pipeline to measure. Onboarding is quick for the people who can install it. Not yet, and the blocker is coverage rather than security.

Three local runtimes are named, not one, which tells me the author actually uses this offline rather than listing a provider to satisfy people like me. Whichever server I already have running is supported, and any endpoint speaking the common format works besides.

Apache-2.0, installed from the crate registry so the source and the binary match, and the tool layer is the protocol everyone else already speaks, so my servers work here on day one. This is the configuration I would have built myself.