VT Code vs OpenCode: workflow, models and total cost

VT Code and OpenCode are both free terminal coding agents that charge nothing for the client and both accept your own OpenAI-compatible endpoint, so this is not a price comparison. The real differences are where each one lets you declare that endpoint, which way the permission defaults point, and whether you want a $10 per month subscription in the same box. VT Code is a single Rust binary from an independent project led by one maintainer. OpenCode is a TypeScript agent from the company Anomaly, with a desktop app, editor extensions and two first-party wallets of its own.

Two name traps have to be cleared first, because getting either wrong invalidates everything after it. "VT Code" is not Visual Studio Code, and VT Code confusingly ships its own VS Code companion extension on a separate version series. And three different things are called OpenCode — only one of them is in this comparison.

What you are actually comparing

Repository metadata, releases and dist-tags read from the GitHub API, npm and crates.io on September 21, 2026. A fourth collision: "OpenCode Go" is also the name of Anomaly's $10 per month subscription plan, which has nothing to do with the Go language or the archived Go CLI — and VT Code makes that worse by naming one of its built-in provider keys opencode-go. Note too how fast VT Code's version moves: 0.164.0, 0.164.2 and 0.165.0 all shipped inside about 27 hours across September 20–21, so read the tag rather than trusting a version printed on any page, this one included.

Who should pick which

On migration cost. The cheap half is AGENTS.md: both tools read it from the project root, so the file describing your conventions survives a move in either direction untouched. The expensive half is everything else. The two config formats are disjoint — TOML with array-of-tables against JSON naming an npm package per provider — and there is no converter, so a project-local setup gets rewritten by hand. Whether MCP definitions, skills, plugins, custom agents or session history carry across is something this page did not establish, so it makes no estimate of migration time beyond that rewrite.

The one asymmetry worth the decision: where the endpoint may live

This is the difference nobody's generic template mentions, and it flips the usual monorepo instinct. OpenCode treats a custom provider as ordinary project data: a committed opencode.json works, which is how a team standardises everyone onto one gateway in a single reviewed file. VT Code deliberately refuses that.

VT Code's configuration field reference states it on the field itself: "Non-empty values from repository-controlled workspace/project layers are rejected; define provider endpoints in trusted system/user or explicitly selected config." The same rejection is repeated on custom_providers[].base_url, on custom_providers[].auth.command, and on provider_overrides.*.base_url and .api_key_env. Its security model names the reasoning as a layer of its own — the loader records the winning origin of each merged field, treats workspace-root files, workspace .vtcode/ files and project profiles as repository-controlled, and fails closed before provider validation, which it says prevents a repository from introducing a custom provider's executable auth.command or redirecting requests through an overridden base URL.

So the practical consequence: with OpenCode, one merged pull request points the whole team at a gateway. With VT Code, the same change is a per-machine install into the user or system config, or a --config path passed at launch. That is a genuine trade — one is deployment convenience, the other is a supply-chain control — and whichever you prefer is a stronger reason to pick a client here than any feature list. Both facts read from main on September 21, 2026.

Permissions, autonomy and the surfaces each one ships

Sources: VT Code's config field reference, security model and provider guide; OpenCode's permissions, providers, server and ACP documentation. All read September 21, 2026, and all of it describes defaults — either client can be reconfigured in the other direction. Both speak ACP and both support MCP, so editor reach is close to parity rather than a differentiator.

The wallet, not the client, is where the money goes

OpenCode sells two things of its own. VT Code sells nothing, which is itself a decision input: every token it sends is billed by whoever you configured, and there is no first-party plan to fall back on.

Prices and quotas read from OpenCode's own documentation on September 21, 2026. Two things worth knowing before you compare against them. Go publishes per-model data terms that are not uniform — most rows say model training not used and zero-day retention, while a few name a 30-day retention and two contributor models are marked as used for training and not zero-retention — so check the row for the model you intend to live on. And Zen publishes dated deprecations, so a comparison anchored to one model id can go stale faster than the page it sits on. OpenCode Enterprise is a contact form with no published price, and this page quotes none.

What a session costs on your own endpoint

The figures below are illustrative token arithmetic, not measured task costs and not a bill ceiling. Assume one agent session that sends 200,000 uncached input tokens and receives 15,000 output tokens — an assumption for comparison, not a measurement of your repository. Rates are live Kunavo catalog prices per million tokens; the last column simply divides, so it inherits every assumption above it.

Set that last column against OpenCode Go's $10 per month, and then resist the urge to call it a verdict. The two are not the same unit: Go's caps are denominated in dollars of usage on its roster, not dollars you spend, and the two shelves only partly overlap — GPT 5.6 Luna is on Go's published list, while the Claude and Gemini rows in the table above are not. A subscription also buys predictability rather than a rate. What the table does settle is the shape of the question — if your work is a handful of long sessions a week on a cheap model, metered tokens get there first; if it is all-day heavy use on models Go actually carries, a flat plan stops being obviously worse. Measure your own sessions before choosing, because a model that needs a second attempt erases a rate advantage immediately.

Kunavo's catalog amount is a billing floor rather than a cap: when the upstream reports its charge, the bill is the greater of catalog cost and upstream cost times the applicable markup. Cache charges and external tools sit outside this example. The minimum top-up is $10 in prepaid credit — a funding minimum, not a task fee or a subscription. See billing details.

Pointing either one at your own endpoint

VT Code's side is a [[custom_providers]] block, and the placement rule from the section above is the part people get wrong:

# This block is rejected if it arrives from a repository-controlled
# layer. Put it in your user config, in the Unix system layer
# (/etc/vtcode/vtcode.toml), or pass it with --config / VTCODE_CONFIG_PATH.
[[custom_providers]]
name = "kunavo"
display_name = "Kunavo"
base_url = "https://api.kunavo.com/v1"
api_key_env = "KUNAVO_API_KEY"
api_format = "openai-chat"
model = "claude-sonnet-5"
models = ["claude-sonnet-5", "claude-haiku-4-5"]
context_window = 1000000   # omit this and VT Code assumes 128000

Four notes on that block, all from the provider guide and field reference. The key is read from the environment variable named in api_key_env, and the config documentation carries an explicit caution never to put API keys in vtcode.toml. api_format accepts auto, openai-chat, openai-responses or anthropic-messages — an explicit value is honoured rather than silently falling back — and the Anthropic route is worth a separate look because the two base-URL conventions differ, which the base URL reference covers. Setting context_window matters: omit it and the provider is assumed to be 128,000 tokens, which quietly caps compaction and preflight checks on a much larger context. And VT Code applies name-based OpenAI sampling gates to custom endpoints too — a model id matching gpt-6-astra, for instance, never receives temperature or top_p — with the guide's own advice being to "prefer neutral model IDs on gateways if you need pinned values on such names."

OpenCode's equivalent is a data file, and the npm field is what picks the wire format — @ai-sdk/openai-compatible for an endpoint serving /v1/chat/completions, @ai-sdk/openai for /v1/responses:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "kunavo": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Kunavo",
      "options": {
        "baseURL": "https://api.kunavo.com/v1",
        "apiKey": "{env:KUNAVO_API_KEY}"
      },
      "models": {
        "claude-sonnet-5": {
          "name": "Claude Sonnet 5",
          "limit": { "context": 1000000, "output": 128000 }
        }
      }
    }
  }
}

OpenCode can also override the baseURL of a built-in provider rather than declaring a custom one, its docs describe model metadata for known providers coming from Models.dev — so a hand-declared provider has to supply its own limit — and keys added through the /connect command land in ~/.local/share/opencode/auth.json. Kunavo publishes a setup page for this client: the OpenCode integration guide. There is no VT Code integration page here, and the TOML block above is a configuration reference assembled from VT Code's documented field definitions — neither client has been runtime-tested against Kunavo, and no compatibility is claimed for either. Keep a working route available, run one bounded task, and read the charge your account recorded before you switch a daily driver. Create a Kunavo account when you are ready to fund a key.

One installation warning that costs real time. The public npm package named vtcode is not the current VT Code: its dist-tag latest was 0.52.8, published December 24, 2025, while crates.io was on 0.165.0 on September 21, 2026. VT Code's installation documentation names a different npm path — npm install -g @vinhnx/vtcode --registry=https://npm.pkg.github.com — alongside cargo install vtcode and a Homebrew tap that needs brew trust vinhnx/tap before brew install vinhnx/tap/vtcode. The same doc warns that Windows artefacts are best-effort and may not appear in every release, while OpenCode's own install page recommends WSL on Windows — so neither is a first-class Windows tool on the strength of its own documentation.

Comparing further afield? Crush vs OpenCode takes the same OpenCode against Charm's agent, OpenCode pricing goes deeper on Zen and Go, and the OpenAI-compatible API reference covers the endpoint convention both clients rely on.

FAQ

Checked September 21, 2026: the GitHub API for all three repositories plus VT Code's release list; npm dist-tags for opencode-ai, @opencode/cli and vtcode; the crates.io record for vtcode; VT Code's README, security model, provider guide, configuration field reference, installation doc and VS Code extension manifest on main; and OpenCode's permissions, providers, server, Zen, Go and download pages. Kunavo token rates come from the live catalog. Neither client was installed, run, or pointed at a Kunavo endpoint for this page, no benchmark or performance comparison was made, and none is claimed; every dollar figure here is illustrative token arithmetic rather than a measured task cost.