Profiles

Jarvis uses the word “profile” in a practical sense: a repeatable set of model or runtime choices that defines how work should run.

Two profile layers

There are two profile layers that matter in public usage:

Model pool profiles The set of providers and models available to the main Jarvis chat experience.
Runtime-local profiles Whatever Claude Code, Codex, or OpenCode has already configured in its own local CLI environment.

Jarvis brings these together at launch time, but it does not flatten them into a single global profile system.

Model pool profiles

For the main chat experience, think of the model pool as the active profile surface.

Use the model pool UI to:

add built-in or custom providers,
keep multiple models available,
switch the default chat model,
maintain a clean separation between infrastructure settings and user-facing model choices.

The important boundary is that the model pool is a Jarvis-managed surface, while provider secrets stay in .env or in the provider entry you add through the UI.

Runtime-local profiles

Runtime CLIs keep their own defaults, credentials, and sometimes their own model selection rules.

Jarvis expects that:

Claude Code is already configured locally,
Codex is already configured locally,
OpenCode is already configured locally.

Jarvis then launches or discovers sessions against those local runtimes. Public docs should describe this as “runtime CLIs use their own local configuration,” because that is the stable behavior users rely on.

Overrides

Sometimes you want a runtime to use a specific model for a specific session. That is an override, not a replacement for the runtime’s local profile.

A launch-time override is useful when:

you want a task to use a stronger coding model than your runtime default,
you want several sessions to compare different models,
you want Jarvis to route a launch through a provider already available in the model pool.

What this page does not assume

This documentation does not assume a dedicated “profiles” admin screen beyond the existing model pool UI. If a future release expands profile management, the public docs should describe the implemented surface directly instead of inventing workflow steps ahead of time.

Operational advice

Put shared infrastructure in .env.
Put main-chat model choices in the model pool UI.
Let runtime CLIs keep their own local configuration.
Use overrides only when a session needs behavior different from the runtime default.