Providers & model compatibility

Every LLM provider visvoai-cli supports out of the box — Gemini, Claude, GPT, and any OpenAI-compatible endpoint — as a terminal AI coding agent and MCP client

visvoai-cli is a terminal AI coding agent — a Claude Code alternative and open source coding agent that runs in your shell, not a hosted product tied to one model vendor. It's also an MCP client: any Model Context Protocol server's tools show up in the same /model-picked model's tool list, regardless of which LLM you're running. This page is the ground truth for what's wired in.

Bespoke-SDK providers

Two providers get a dedicated client rather than going through a generic OpenAI-shaped adapter, because their APIs aren't OpenAI-shaped:

Provider	Env var	Notes
Google Gemini	`GEMINI_API_KEY`	`langchain-google-genai` for chat; the native `google-genai` SDK directly for grounded search and URL fetch
Anthropic Claude	`ANTHROPIC_API_KEY`	`langchain-anthropic`, with extended-thinking budgets wired through

OpenAI-compatible providers

Everything else — including OpenAI itself — goes through one adapter (OpenAICompatProvider) built on ChatOpenAI + a base_url. Three ship with a built-in default endpoint and OpenAI needs none; any other OpenAI-compatible host works by passing its base_url explicitly:

Provider	Env var	Default `base_url`
OpenAI	`OPENAI_API_KEY`	library default
Together AI	`TOGETHER_API_KEY`	`https://api.together.xyz/v1`
Groq	`GROQ_API_KEY`	`https://api.groq.com/openai/v1`
OpenRouter	`OPENROUTER_API_KEY`	`https://openrouter.ai/api/v1`
any custom endpoint	(your choice)	pass `base_url=` — a self-hosted vLLM server, a local inference proxy, or any other OpenAI-API-shaped host

Because the adapter is generic, adding a new named provider is a config entry, not new code — the reason the live catalog (below) already spans far more providers than this table lists explicitly.

API keys are layered, not global-env-only

Keys resolve per provider, highest precedence first:

an explicit key passed for that call
<project>/.visvoai/secrets.toml — [api_keys], gitignored, per-project
~/.visvoai/config.toml — [api_keys], your global default

Set a project's .visvoai/secrets.toml to keep a client's key out of your shell profile, or just export GEMINI_API_KEY / ANTHROPIC_API_KEY / OPENAI_API_KEY and go — see Installation.

`/model` — a live catalog, filtered to what you can use

The picker isn't a static list shipped with a release; it's backed by a three-tier catalog (baked floor → cached models.dev fetch → offline fallback) that resolves to thousands of models across 100+ providers. It only shows you providers you have a key configured for, so the abundance doesn't drown the picker in models you can't call. Full mechanics: Model picker.

Why this matters if you're evaluating agent CLIs

Most "Claude Code alternative" or "AI pair programmer CLI" tools pick one model vendor and bake it in. This one separates the agent loop (visvoai-core) from the model layer (visvoai-ai) — so switching from Gemini to Claude to a self-hosted vLLM box mid-project is a /model pick, not a rewrite, and neither package needs to know anything about the terminal, MCP, or permission model living on top of them in this CLI.