Skip to content
JarvisJarvis Docs

Configure providers

Jarvis separates chat model configuration from coding runtime configuration. That split is the most important thing to understand before you change any settings:

  • The main chat session uses the model pool UI inside Jarvis.
  • Claude Code, Codex, and OpenCode use their own local CLI configuration by default.
  • The .env file is for Jarvis infrastructure settings and optional built-in provider credentials, not for day-to-day model selection.

Goal

Section titled “Goal”

Finish a public, portable setup that lets Jarvis answer chat requests and start coding sessions without hard-coding private paths or provider secrets into the repository.

Prerequisites

Section titled “Prerequisites”
  • Jarvis is installed locally.
  • You can open the Jarvis web UI.
  • At least one model provider account or local model endpoint is available.
  • The runtime CLIs you want to use are already installed on your machine.

Step 1: Understand where configuration lives

Section titled “Step 1: Understand where configuration lives”

Jarvis has three configuration layers:

  1. Jarvis environment variables Control the server itself, including the port, database path, and optional built-in provider credentials.
  2. Model pool Stores the models used by the main Jarvis chat session. Use the model pool UI to add, select, and switch models.
  3. Runtime CLI configuration Claude Code, Codex, and OpenCode keep their own authentication and runtime defaults in their official local CLI configuration. Jarvis uses those local settings unless you explicitly launch a session with a model override.

Step 2: Add provider credentials when you need built-in providers

Section titled “Step 2: Add provider credentials when you need built-in providers”

The .env file exposes optional credential slots for Jarvis built-in providers. These are intended for provider entries that Jarvis can route through the model pool without storing credentials in page content or source control.

Common public examples from .env.example include:

  • JARVIS_YUNWU_API_KEY
  • JARVIS_DEEPSEEK_API_KEY
  • JARVIS_GLM51_API_KEY

If you use one of those built-in providers:

  1. Copy .env.example to .env.
  2. Fill only the credential fields you actually need.
  3. Restart Jarvis after editing .env.

If you use a custom provider, add it in the model pool UI instead of editing .env. Custom providers can carry their own base URL and API key in the Jarvis model configuration flow.

Step 3: Configure the main chat model in the model pool UI

Section titled “Step 3: Configure the main chat model in the model pool UI”

Jarvis treats the model pool as the source of truth for the main chat session. That means:

  • You do not need to set a chat model in .env for normal usage.
  • The selected model in the model pool is what the main session uses.
  • JARVIS_DEFAULT_MODEL is only a fallback when no model pool selection is available.

Use the model pool UI to:

  • add provider-backed models,
  • select the default chat model,
  • keep multiple models ready for switching,
  • import or update user-facing model definitions.

Step 4: Keep runtime CLIs configured separately

Section titled “Step 4: Keep runtime CLIs configured separately”

Coding runtimes are intentionally separate from the main chat model.

By default:

  • Claude Code uses its own official CLI configuration.
  • Codex uses its own official CLI configuration.
  • OpenCode uses its own global CLI configuration.

Jarvis does not replace those local runtime credentials. It launches and manages sessions around them.

Use a model override only when you intentionally want Jarvis to inject a model choice from the model pool at session launch time.

Step 5: Set core server variables

Section titled “Step 5: Set core server variables”

Most users only need a small set of Jarvis variables:

Variable What it does
JARVIS_API_KEY API authentication key for Jarvis. Generate it with scripts/generate_api_key.py.
JARVIS_PORT HTTP port for the Jarvis server. Default: 8888.
JARVIS_DATABASE_PATH SQLite database path. Default: data/jarvis.db.

These values are part of infrastructure setup, not model selection.

Step 6: Verify the setup

Section titled “Step 6: Verify the setup”

After updating .env and confirming your runtime CLIs are authenticated:

  1. Start or restart Jarvis.
  2. Open the Jarvis UI.
  3. Select a model in the model pool.
  4. Send a test chat message.
  5. Launch one coding session with the runtime you care about.

You should see:

  • a successful chat response from the selected model,
  • a coding session that launches without an authentication error,
  • progress updates in Jarvis as the runtime works.

Troubleshooting

Section titled “Troubleshooting”

Chat works, but a coding runtime fails

Section titled “Chat works, but a coding runtime fails”

The main chat model and runtime CLIs are configured separately. A successful chat response does not prove that Claude Code, Codex, or OpenCode is authenticated. Check the local CLI login state for the failing runtime.

A built-in provider does not appear to work

Section titled “A built-in provider does not appear to work”

Confirm that:

  • the correct JARVIS_*_API_KEY field is set,
  • the key was added to .env rather than committed to docs or source files,
  • Jarvis was restarted after the change.

I set a model in .env, but the UI still uses another one

Section titled “I set a model in .env, but the UI still uses another one”

That is expected when the model pool already has an active selection. The model pool UI takes precedence for the main chat experience.

A runtime launches with the wrong model

Section titled “A runtime launches with the wrong model”

Jarvis normally defers to the runtime CLI’s own local configuration. If you need deterministic behavior, launch the session with an explicit model override.

Section titled “Related pages”