Use Xantly with Gemini CLI

Google's Gemini CLI doesn't yet support custom base URLs. Until it does, the best pattern is OpenCode routing to Gemini via Xantly, here's how.

Gemini CLI is Google's official command-line tool for Gemini, built for agent workflows with tool calling, MCP support, and grounding. As shipped, it's locked to Google's generativelanguage.googleapis.com endpoint. Xantly does route to Gemini models natively (via Google's API), but Gemini CLI doesn't yet accept a custom base URL. This page covers both the current best-fit patterns and the future Xantly-direct option if/when that flag lands.

Current state (April 2026)

What worksWhat doesn't
Use Gemini CLI with a direct Google API keySet a custom base URL
Access Gemini models through Xantly via OpenCode / any other toolPoint Gemini CLI itself at Xantly
BYOK your Google API key into Xantly and route other tools through itNative Xantly gateway in Gemini CLI

Track the upstream issue: github.com/google-gemini/gemini-cli, base URL override.

If you want a Gemini-heavy CLI workflow with Xantly's benefits, OpenCode natively routes to Gemini via Xantly:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "xantly": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "https://api.xantly.com/v1",
        "apiKey": "xantly_sk_..."
      },
      "models": {
        "google/gemini-2.5-pro":   { "name": "Gemini 2.5 Pro (via Xantly)" },
        "google/gemini-2.5-flash": { "name": "Gemini 2.5 Flash (via Xantly)" }
      }
    }
  },
  "model": "google/gemini-2.5-pro"
}

You get Gemini + smart routing + cache + waterfall fallback. See the OpenCode integration for full details.

Option 2, Use Gemini CLI directly, BYOK your Google key to Xantly for other tools

If you like Gemini CLI specifically and want to keep using it:

  1. Use Gemini CLI with your direct Google API key (unchanged).
  2. For all other tools (Cline, Continue.dev, Aider, OpenCode), point them at Xantly.
  3. Register your Google API key as a BYOK key in your Xantly dashboard, Xantly will use it for Gemini routing in other tools, so you don't double-pay.
# Gemini CLI, direct to Google
export GEMINI_API_KEY=ya29...   # direct Google key

# Everything else, through Xantly
export OPENAI_API_BASE=https://api.xantly.com/v1
export OPENAI_API_KEY=xantly_sk_...

Option 3, When Gemini CLI adds custom-endpoint support

If/when Gemini CLI ships a --base-url flag or a GEMINI_BASE_URL env var, the setup will be:

export GEMINI_BASE_URL=https://api.xantly.com        # bare, Xantly's /v1beta/models/... is Gemini-shape compatible
export GEMINI_API_KEY=xantly_sk_...

Xantly's Gemini-native endpoint at https://api.xantly.com/v1beta/models/... already speaks the Gemini wire protocol (see Provider Ecosystem). Gemini CLI would just need to honor a custom base.

Current workaround for CLI-only users

Aider + Gemini is the closest single-CLI equivalent:

aider \
  --openai-api-base https://api.xantly.com/v1 \
  --openai-api-key xantly_sk_... \
  --model google/gemini-2.5-pro

See Aider integration for details.

Model choice (via Xantly)

Model IDWhen
google/gemini-2.5-proPrimary Gemini workflow, large context.
google/gemini-2.5-flashFast + cheap Gemini.
xantly/auto-qualityIf you'd rather let BaRP pick, often picks Claude/GPT over Gemini for coding.

Verify (via OpenCode)

cd some-project
opencode  # with the Gemini config above
> list files here

Check the Xantly dashboard, call logs as google/gemini-2.5-pro with routing metadata.

What you get

Gotchas

Gemini CLI ≠ Gemini API ≠ Vertex AI. Three different Google surfaces. Xantly currently routes to the public Gemini API (generativelanguage.googleapis.com). Vertex AI support is on the roadmap.

Gemini 2.5 Pro context is 2M tokens: absurdly long. Xantly's waterfall treats Gemini 2.5 Pro as the long-context fallback when other models hit their window. Your Gemini CLI experience benefits from this when routed via Xantly-aware tools.

Gemini function-calling JSON shape. Gemini's tool format differs from OpenAI's. Xantly's normalizer translates it both ways, for your tool-heavy workflows, this means you can switch model=google/... to model=openai/... without rewriting tool schemas.

Next steps