Skip to content

Provider quickstart

Pick a provider, set a key, and run your first chat across the top providers, with env-var overrides.

Revka talks to your model provider through a single unified interface, so picking a provider is mostly a matter of two settings — default_provider and an API key — plus the right model ID. This page gets you from zero to a working chat with the three providers most people start on: OpenRouter (the default), Anthropic, and OpenAI. It also covers exactly how Revka resolves your credentials and how to override the provider per-run with environment variables.

If you have not installed Revka yet, start with Installation and the Quickstart. For the full list of supported back-ends, see the Provider catalog.

Three top-level keys in ~/.revka/config.toml control which model you talk to:

KeyTypeDefaultMeaning
default_providerString"openrouter"Provider ID (alias model_provider). Env: REVKA_PROVIDER or PROVIDER (legacy).
default_modelString"anthropic/claude-sonnet-4.6"Model ID (alias model). Env: REVKA_MODEL.
api_keyString?noneProvider API key. Env: REVKA_API_KEY or API_KEY.

The fastest way to set all three is revka onboard, which writes config.toml for you. You can run it interactively or pass everything as flags for a non-interactive setup:

Terminal window
revka onboard # interactive wizard
revka onboard --api-key sk-or-... --provider openrouter # non-interactive

You can also edit ~/.revka/config.toml directly, or supply credentials entirely through environment variables — see Credential resolution order below.

Once a provider and key are configured, send a one-shot message with revka agent:

Terminal window
revka agent -m "Say hello in one sentence."

Drop the -m flag to open an interactive session instead. Key flags for revka agent:

FlagMeaning
-m, --message <TEXT>Send a single message (no interactive loop).
-p, --provider <ID>Override the configured default_provider for this run.
--model <MODEL_ID>Override the configured default_model for this run.
-t, --temperature <0.0-2.0>Override the configured temperature.

This lets you try a provider without editing config at all:

Terminal window
revka agent -p openrouter --model openai/gpt-4o -m "Hello"
revka agent -p anthropic --model claude-sonnet-4-5-20250929 -m "Hello"

OpenRouter is Revka’s out-of-the-box default. One key gives you access to 200+ models across vendors, and model IDs use the provider/model-name format (for example anthropic/claude-sonnet-4-6).

  1. Get an OpenRouter API key — it starts with sk-or-.

  2. Configure it:

    ~/.revka/config.toml
    default_provider = "openrouter"
    default_model = "anthropic/claude-sonnet-4-6"
    api_key = "sk-or-..."

    Or set it through the environment:

    Terminal window
    export OPENROUTER_API_KEY="sk-or-..."
  3. Run a chat:

    Terminal window
    revka agent -m "Hello from OpenRouter"

When Revka builds a provider, it resolves the API key in a fixed three-step priority. The first non-empty value wins:

  1. Explicit config value — the api_key key in config.toml.

  2. Provider-specific environment variable — for example OPENROUTER_API_KEY, ANTHROPIC_API_KEY, or OPENAI_API_KEY.

  3. Generic fallbackREVKA_API_KEY, then API_KEY.

So a provider-specific variable always overrides the generic REVKA_API_KEY/API_KEY fallback. Note that for the anthropic, openai, and groq providers, the provider-specific env var (e.g. ANTHROPIC_API_KEY, OPENAI_API_KEY, GROQ_API_KEY) takes precedence over a config.toml api_key value — this supports multi-provider and custom-gateway setups where the env var should win. For all other providers, a key set in config.toml takes priority over environment variables.

Each provider has its own optional key variable. The most common ones:

ProviderKey env varKey prefix
openrouterOPENROUTER_API_KEYsk-or-
anthropicANTHROPIC_API_KEY (or ANTHROPIC_OAUTH_TOKEN)sk-ant-
openaiOPENAI_API_KEYsk-
groqGROQ_API_KEYgsk_
perplexityPERPLEXITY_API_KEYpplx-
xaiXAI_API_KEYxai-

See the Provider catalog for the complete list of providers and their key variables.

Before constructing a provider, Revka checks the resolved key’s prefix against the selected provider and raises a readable error if they clearly do not match — for example an sk-ant- key used with the openai provider. This is a debugging aid for the common copy-paste mistake of mixing keys. The check is skipped for custom: providers and any provider configured with a custom api_url.

You can switch providers per-run without touching config.toml using environment variables. There are two, with different precedence:

VariableBehavior
REVKA_PROVIDERAlways wins over config when non-empty.
PROVIDERLegacy fallback — only applied when config default_provider is unset or still openrouter.

Use REVKA_PROVIDER to force a provider regardless of what is in config:

Terminal window
REVKA_PROVIDER=anthropic revka agent -m "Hello"
REVKA_PROVIDER=ollama revka agent --model llama3.2 -m "Hello"

Beyond the provider itself, the core runtime settings can all be set through the environment. These override the matching config.toml keys at startup:

VariableMaps to config key
REVKA_PROVIDER / PROVIDER (legacy)default_provider
REVKA_MODELdefault_model
REVKA_API_KEY / API_KEYapi_key
REVKA_TEMPERATUREdefault_temperature
REVKA_EXTRA_HEADERSextra_headers (format Key:Value,Key2:Value2)
REVKA_REASONING_ENABLED / REASONING_ENABLEDextended thinking mode

A fully env-driven run looks like this:

Terminal window
export REVKA_PROVIDER="anthropic"
export REVKA_MODEL="claude-sonnet-4-5-20250929"
export ANTHROPIC_API_KEY="sk-ant-..."
revka agent -m "Configured entirely from the environment"

Confirm the provider and key are working before you build on them:

Terminal window
revka doctor models # probe every configured provider
revka doctor models --provider anthropic # probe a single provider
revka models list # list cached models for the current provider
revka models refresh # refresh the model catalog from the provider
revka models status # show the current provider and model

revka doctor models reports a connectivity matrix with ok / auth-error / error status per provider — the quickest way to catch a bad key or an unreachable endpoint. The broader revka doctor run also validates that your provider, model, and key are set. See Diagnostics for the full report.