Skip to main content
GoModel routes OpenAI-compatible requests to many AI providers through one gateway. For most providers, setting the API key is the whole setup. The pages in this section exist for the ones whose setup is not purely “set an API key” — auth flows from cloud credentials, deployment-based URLs, region or project requirements, dual native + OpenAI-compatible API surfaces, or other quirks.

​
Supported providers

Example model identifiers are illustrative and subject to change; consult provider catalogs for current models. Feature columns reflect gateway API support, not every individual model capability exposed by an upstream provider. ✅ Supported ❌ Unsupported

​
Provider notes

  • Z.ai GLM Coding Plan — set ZAI_BASE_URL=https://api.z.ai/api/coding/paas/v4.
  • Fireworks AI — model IDs are account-scoped paths such as accounts/fireworks/models/gpt-oss-120b; use them verbatim in requests and in FIREWORKS_MODELS.
  • Meta (Muse Spark) — the Meta Model API is OpenAI-compatible; set META_API_KEY and route to muse-spark-1.1. Muse Spark models are not in the upstream model catalog yet, so declare context_window and pricing under providers.meta.models metadata in config.yaml if you want cost tracking and context-window reporting.
  • Xiaomi MiMo — TTS (mimo-v2.5-tts*) and ASR (mimo-v2.5-asr) are served through /v1/audio/speech and /v1/audio/transcriptions (translated to MiMo’s chat-completions audio dialect) as well as directly via chat completions; for 1M context append [1m] to the model ID and list it in XIAOMI_MODELS.
  • OpenCode Go (OpenCode Zen) — routes per model: most models use OpenAI-style /chat/completions, while /messages-only models (default qwen3.7-max, override with OPENCODE_GO_MESSAGES_MODELS) are sent to the Anthropic-native endpoint. Set OPENCODE_GO_API_KEY; the base URL defaults to https://opencode.ai/zen/go/v1.
  • Kimi Code — no per-token pricing; quota refreshes weekly and is also constrained by a rolling 5-hour window. Usage-cost tracking reports zero for Kimi Code, so cost load-balancing cannot price it; prefer conservative retry strategies.
  • Configured model lists — available for every provider with <PROVIDER>_MODELS, for example OPENROUTER_MODELS=openai/gpt-oss-120b,anthropic/claude-sonnet-4 or ORACLE_MODELS=openai.gpt-oss-120b,xai.grok-3. DeepSeek defaults to https://api.deepseek.com; set DEEPSEEK_BASE_URL only when using a compatible proxy or alternate DeepSeek endpoint. By default, CONFIGURED_PROVIDER_MODELS_MODE=fallback uses those lists only when upstream /models is unavailable or empty. Set CONFIGURED_PROVIDER_MODELS_MODE=allowlist to expose only configured models for providers that define a list, skipping their upstream /models calls.
  • vLLM — set VLLM_API_KEY only if the upstream server was started with --api-key.
  • Multiple API keys for one provider — set OPENAI_API_KEY_2, OPENAI_API_KEY_3, and so on to spread requests across keys round robin and lift per-key rate limits. This costs you provider prompt caching; see API key rotation.
  • Multiple instances of one provider type — without config.yaml, use suffixed env vars such as OPENAI_EAST_API_KEY and OPENAI_EAST_BASE_URL; add OPENAI_EAST_MODELS to configure that instance’s model list. This registers provider openai-east with type openai. Vertex AI follows the same suffix pattern — VERTEX_US_PROJECT registers provider vertex-us. Vertex project and location env vars must match the instance prefix: for a suffixed instance such as VERTEX_US_PROJECT, also set VERTEX_US_LOCATION and any other suffixed settings for that instance, rather than the generic VERTEX_PROJECT / VERTEX_LOCATION. VERTEX_AUTH_TYPE defaults to Application Default Credentials (gcp_adc).

​
Why some providers have dedicated pages

These are the providers most users hit friction on:
  • Google Vertex AI — needs a GCP project, region, and either Application Default Credentials or a service-account JSON key.
  • Amazon Bedrock — no API key of its own; uses the AWS credential chain and requires explicit model access in the Bedrock console.
  • Azure OpenAI — deployment-scoped base URLs, the api-version query parameter, and the api-key header instead of Authorization: Bearer.
  • Oracle GenAI — requires an OCI IAM policy for generativeaiapikey and a region-specific OpenAI-compatible endpoint URL.
  • Google Gemini (AI Studio) — two routing modes (native generateContent vs OpenAI-compatible) with different image-input behavior.
  • Anthropic — reasoning effort maps to Claude’s adaptive thinking and effort control, which differ across model generations.
  • DeepSeek — reasoning effort mapping quirks for DeepSeek V4.
  • Ollama / vLLM — local-model hosting with optional multi-instance setup through suffixed env vars and provider-qualified model IDs.
  • Xiaomi MiMo — thinking mode on by default, a [1m] context suffix, and TTS/ASR that run through chat completions rather than native audio endpoints.
  • OpenCode Go — OpenCode Zen splits models across OpenAI-style /chat/completions and Anthropic-native /messages; GoModel routes per model (the /messages-only set is maintained manually, default qwen3.7-max).
Every provider page shows three launch forms in one CodeGroup: Docker with --env-file .env (recommended), Docker with inline -e flags, and a prebuilt binary from make build. Once you have more than a couple of variables, copy .env.template, fill in the values you need, and reuse the same file for both Docker and the native binary.
Providers without a dedicated page (OpenAI, Groq, Fireworks AI, Meta, OpenRouter, Z.ai, xAI, MiniMax) follow the same pattern: set the API key (and optional base URL where supported), start GoModel, route by model ID. The full env-var reference lives in Configuration.

​
Provider status

The admin dashboard (/admin/dashboard) shows live status for every configured provider in the Providers Overview section of the Overview page. GoModel dashboard Providers Overview with a Degraded openai card showing a failing model and a Healthy vllm card Each card’s status pill combines two signals — model discovery (can the provider’s model inventory be fetched?) and request health (are real requests through the gateway succeeding?). Real-traffic signals only ever worsen a status, never mask a discovery failure. Hover over the pill for the classification reason and the most recent error. Expand a card (the arrow strip at the bottom, or the section-wide Show Details switch) to see request health details:
  • Recent Requests — requests and errors through the gateway in the last 10 minutes.
  • Breaker State — the provider’s live circuit-breaker state (see Resilience).
  • Models (Recent Traffic) — per-model request/error counts. A model with at least 3 errors making up half or more of its windowed requests is flagged in red — this catches a single broken model on an otherwise healthy provider, which model discovery alone cannot see. Hover a row for the model’s latest error message.
Request-health tracking is passive: it observes traffic your clients already send (the gateway’s own background probes — model discovery and availability checks — are excluded), so an idle provider simply shows no recent requests. Counters are in-memory per gateway instance and reset on restart. The same data is available as JSON from GET /admin/providers/status for scripting and external monitoring.