Skip to main content
VG Code — in Vibgrate CLI and Vibgrate for VS Code

A coding agent that starts
from your code, not a search.

Most coding agents open your repository like a stranger: they grep, guess whichsend() you meant, and hand you a diff you have to audit line by line. VG Code starts from your code map — the real symbols, call sites, and source ranges in your project — and asks before it touches anything.

The same agent, under the same approval gate, in your terminal and in your editor.

# Run without installing anything
npx @vibgrate/cli scan

# Pin a version or see every command
npx @vibgrate/cli@latest --help

no install·Nothing is installed globally — ideal for CI or a one-off scan.

Then describe the change
$ vg build
$ vg code "add a --timeout flag to the scan command"
Dry-run by default — it prints the diff and writes nothing.

Three ways in, one agent

The editor does not re-implement the agent — it runs the one shipped with the CLI and relays your decisions to it. That is why the terminal, the editor, and CI behave the same way instead of drifting apart.

Your terminal

vg code

Dry-run by default: it prints the proposed diff and writes nothing. Writing is opt-in and always consented. Scriptable for CI with a JSON result file.

The VS Code panel

Vibgrate for VS Code

The full surface: a conversation that stays warm between tasks, chat history, inline Approve / Reject cards with diffs, checkpoints, @-mentions, and attachments.

VS Code Chat

@vgcode

Sits as a tab beside your other agents. One task per turn — no conversation continuity, history, checkpoints, or attachments. Use the panel for those.

The panel keeps its session warm between tasks, so a follow-up does not pay the start-up cost or make you re-explain the job. Stop cancels the current task, not the conversation, and edits already approved stay applied.

Nothing changes without your say-so

An agent you cannot stop is an agent you cannot use on real work. VG Code is built the other way round: the gate comes first, and the speed is what is left after it.

You approve every change

Every edit, file creation, deletion, and shell command is a decision you make. The agent stops and waits. Read-only actions run freely; nothing that changes state does. There is no quick-apply path around the gate on any surface.

Review it as a real diff

In the panel, an Approve / Reject card shows the unified diff inline, and “Review in editor” opens it in VS Code’s own diff view. A multi-file change is one decision for the whole transaction, not a click per file.

Plan first, with writes blocked

A selector next to Send switches between Agent, Plan, and Auto accept. In Plan mode the agent is read-only and mutations are refused outright. You can pin a stronger model for planning and a faster one for the work.

Undo an approved change

Each approval writes a checkpoint before the change lands, so you can put the files back the way they were. The restore is scoped to the files that change touched, and your branch, index, and history are never touched. It needs the session that made the change to still be open.

Secrets stay out of the model

Environment files, key material, and cloud credentials are refused before they reach a model, and tokens found in any file that is read are masked. Commands are checked before they can send a secret anywhere.

Sandboxed shell, network denied by default

Shell commands can run inside an OS-level sandbox, and in autonomous mode outbound network access is denied unless you allow it. A command denylist applies to autonomous runs and is yours to extend.

Every run leaves a record

Each run appends what was asked, which model answered, how many steps it took, why it stopped, and which files changed with what outcome — plus a content fingerprint for every change and every verification step, so an identical run produces an identical record. File contents and keys are never written to it. It is a record of what happened, not a compliance determination.

Grounded in the code you actually have

Retrieval by similarity finds code that looks related. A code map knows what calls what. VG Code uses the map.

It starts from your code map

Before the first inference, VG Code compiles a Task Capsule: the symbols that matter for your task, the exact source ranges behind them, how they relate, and a plan for verifying the work. The first attempt can solve the problem instead of spending its turns navigating.

Your uncommitted work counts

Files you have changed but not committed are re-read, so the map reflects your working tree, not the last commit. During a task the agent also reads its own pending edits — search and impact answers include changes it has not written to disk yet.

Your project’s rules are read, not obeyed

AGENTS.md, CLAUDE.md, and .vibgrate/rules are read the way a new contributor would read them — bounded, redacted, and advisory. They cannot grant permissions or stand in for your approval, so text in a rules file can never act as policy.

Long tasks keep their thread

Past the context budget, recent turns are kept as-is and the middle is condensed into a structured checkpoint — objective, decisions, files, state, next steps. A follow-up question keeps the topic of the one before it.

Fewer wrong-place edits

The failure that costs you an afternoon is not a bad idea — it is a good idea applied to the wrong function, or a call to something that does not exist. Both are caught structurally, before a file is written.

The edit lands where you meant

Matching escalates from exact, to whitespace-tolerant, to scoped by the symbol the model actually named — so an ambiguous match resolves to the right function rather than the first textual hit. Applying an edit needs no model at all.

Invented symbols are blocked before the write

A change that calls something your codebase does not contain is rejected before it touches a file, checked against the symbols in the map. Stale or impossible edits are refused the same way.

It checks its own work

After a change, VG Code runs a verification ladder built from the task and your project’s test command. Syntax checks need no model.

A failure it can act on

When a step fails, it gets the failed step, the first causal error, the affected symbols and source, and ranked correction hints — not a log dump — and a bounded number of repair rounds to fix it.

Your model, your machine, your policy

Privacy, cost, hardware, and procurement rules differ per team, so the model is a choice, not a default you have to live with. No model is bundled and nothing is installed behind your back.

Vibgrate Relay — no API keys

Sign in once and run hosted models on prepaid credit. The panel shows the catalog with per-model prices and your balance. The same sign-in works in your terminal.

Code Modes — Spark, Flow, Forge

First-party model packs that run on your machine. Before anything downloads, each pack is rated against your real memory, VRAM, and free disk — so you never pull a model your machine cannot run.

Your own local models

Ollama, LM Studio, and on-device gguf models are discovered without a network call. In the CLI, --local restricts VG Code to on-device backends and fails with an actionable message rather than reaching the network.

OpenRouter and other hosted backends

Browse the live OpenRouter catalog from the panel; the key is held in VS Code’s secret storage, never in settings or your workspace. LiteLLM, OpenAI, Together, and Foundry Local are routable too.

Where your code goes, plainly

With a local model, the task and its context stay on your machine. With a hosted model — Vibgrate Relay, OpenRouter, or any other backend you configure — the context for that turn is sent to that provider, the same as any other tool that calls a hosted model. VG Code never dials an endpoint you have not configured. We would rather state the boundary than claim “nothing leaves your machine” and be wrong about it.

The tools it works with

Alongside reading, editing, and running commands, VG Code has the whole Vibgrate AI Context tool surface available in-process — code map queries, impact analysis, drift, and library docs — with no second server to run.

Find code by structure

Search runs over the code map and the text, so “where is this called” is answered from real relationships rather than a keyword guess.

Version-correct library docs

Docs for the version of the dependency you actually have installed, served by Vibgrate AI Context — so the agent stops writing code against an API you upgraded past.

The MCP servers you already wired

Servers configured for Claude Code, Cursor, or VS Code are picked up with no extra setup. Read-only tools run freely; everything else goes through the same approval gate as a built-in change.

What it does not do yet

You will find this out in the first ten minutes anyway. Better here.

  • No built-in web search, web fetch, or browser use — only via an MCP server you configure.
  • No subagents or task delegation, and no todo list.
  • Shell commands are blocking: no streaming output, no background or persistent shell.
  • No notebook editing, and no use of Copilot-provided models.
  • Approval is per file or per patch, not per hunk — and there is no edit-before-apply.
  • VG Code is not wired to the Vulnerabilities panel: it does not fix findings from a scan.

Free and paid, plainly

VG Code itself is free in both the Vibgrate CLI and Vibgrate for VS Code, with no account. Running it on a local model costs nothing but your hardware. Hosted models cost what the model costs: on Vibgrate Relay that is prepaid credit with per-model prices shown before you pick, and on any other backend you bring your own key and pay that provider directly. Automated dependency remediation (vg fix) is a separate paid capability.

Describe the change. Read the diff. Decide.

Build the map once, then put VG Code on the change you have been putting off. It writes nothing until you say so.

More from Vibgrate