The provider flag
vg code "<instruction>" --provider <id>
Known values: vibgrate-relay, ollama, lmstudio, foundry-local, openrouter, litellm, openai, together, llama-cpp.
Automatic selection order
You rarely need --provider at all. When it's omitted, VG Code resolves a backend in this order:
- Vibgrate Relay, if
VIBGRATE_RELAY_TOKENis set — the first-party hosted router, paired automatically with local models as a fallback path if Relay itself is unreachable. - OpenRouter, if
OPENROUTER_API_KEYis set. - Other configured hosted providers (LiteLLM, OpenAI, Together), if their respective keys are set.
- A locally discovered model (Ollama, LM Studio, Foundry Local, llama.cpp), auto-detected on your machine.
- A local model you install directly via
vg models install spark.
If none of these resolve, VG Code fails with an actionable message rather than silently picking something you didn't intend.
Environment variables
| Variable | Purpose |
|---|---|
VIBGRATE_RELAY_TOKEN | <dsn-key>:<dsn-secret> credential that activates Relay as the preferred backend |
VIBGRATE_RELAY_URL | Override the Relay endpoint (defaults to https://api.vibgrate.com/relay/v1) — for staging/self-hosted testing only |
VG_CODE_MODEL | Default model when --model isn't passed |
Relay and local Code Modes together
Relay never replaces local Code Modes — it's an additional hosted option alongside them. A common pattern is Relay for anything that benefits from a frontier hosted model, with local Code Modes as the fully offline path for sensitive repositories or air-gapped environments where no code should leave the machine at all.
Checking what VG Code will pick
vg doctor
Reports the resolved provider, model, and the human-readable reason string (e.g. "VIBGRATE_RELAY_TOKEN is set → Vibgrate Relay (with local fallback)") — useful for confirming a CI environment is wired the way you expect before a real run.