Agent engine config

The agent_engine_config object in settings.json configures the four engine agents individually:

Every field is optional, and it merges across the same user → org-managed → project scope chain as the rest of settings.json, per field — a project can pin just the judge model while your user scope keeps everything else.

The full schema

{
  "agent_engine_config": {
    // Flat per-role models ("provider/slug", or a bare catalog slug).
    // default_model doubles as the WORKER route — the pipeline's execute
    // turns run the worker/default chain (see Model precedence below).
    "default_model": "zai/glm-5.2",
    "pipeline_judge_model": "openrouter/openai/gpt-5.5",
    "pipeline_triage_model": "deepseek/deepseek-chat",

    // The model vocabulary the TUI pickers offer and auto_mode selects from.
    "allowed_models": ["anthropic/claude-fable-5", "zai/glm-5.2",
                        "openrouter/openai/gpt-5.5"],

    // "on" = pick the judge automatically from allowed_models: prefer a
    // different model family than the worker's, then the highest catalog
    // price tier. You never worry about it.
    "auto_mode": "off",
    // "on" = per-agent effort chosen for you (judge high, worker and
    // default medium, triage low), overriding any per-agent "effort".
    "effort_auto": "off",
    // "on" = thinking mode chosen for you (on everywhere except triage).
    "reasoning_auto": "off",

    // Per-agent deep config. Set a field and it goes on the wire; leave it
    // out and the provider default applies.
    "agents": {
      "judge": {
        "provider": "openrouter",          // gateway: the slug goes to THIS
        "model": "openai/gpt-5.5",         // provider verbatim
        "prompt": "You are a strict, evidence-first code judge.",
        "effort": "high",                   // low | medium | high | xhigh | max
        "reasoning": "on",                  // thinking mode on/off
        "params": {
          "temperature": 0.2, "top_p": 0.9, "top_k": 40,
          "frequency_penalty": 0.0, "presence_penalty": 0.0,
          "repetition_penalty": 1.0, "max_tokens": 4096, "seed": 7,
          "verbosity": "low",               // low | medium | high
          "service_tier": "priority"        // auto | default | flex | priority
        }
      }
    }
  }
}

Model precedence

The chain differs by role — --model governs the worker, while an explicitly configured judge or triage keeps its own model even under a --model flag.

Worker & default agent (one model, shared by the interactive agent and the pipeline's execute turns) — first hit wins:

1. The --model CLI flag
2. agents.default.model
3. default_model
4. Auto-detection / the provider's own default

Judge and triage — first hit wins:

1. agents.judge.model / agents.triage.model
2. pipeline_judge_model / pipeline_triage_model
3. default_model
4. No configuration — the role rides the worker's model

auto_mode: "on" replaces the judge spec with the cross-family pick from allowed_models (below). A --model flag does not override an explicitly configured judge or triage — stella --model anthropic/claude-fable-5 goal "…" with pipeline_judge_model: openrouter/openai/gpt-5.5 runs a Fable worker under a GPT judge, which is usually exactly what you want from a cross-family setup.

One gateway per agent (BYOK per agent)

An agent's provider field routes its model slug through that provider verbatim — no prefix splitting. That is how you mix billing relationships in one pipeline:

{
  "agent_engine_config": {
    "default_model": "anthropic/claude-fable-5",             // worker — your Anthropic key
    "agents": {
      "judge":  { "provider": "openrouter", "model": "openai/gpt-5.5" }, // your OpenRouter key
      "triage": { "provider": "zai", "model": "glm-5.2" }               // your Z.ai key
    }
  }
}

Without a provider field, model strings use --model semantics: provider/slug splits on the first / when the prefix names a known provider (so openrouter/openai/gpt-5.5 routes openai/gpt-5.5 through OpenRouter), and a bare slug resolves through the model catalog.

Auto modes

Set any of the three autos to "on" and stop thinking about it:

• auto_mode — the judge model is picked automatically from allowed_models: prefer a candidate from a different model family than the worker (an independent second opinion), then the highest catalog price tier as a capability proxy, then list order. Candidates whose provider has no resolvable credential are skipped.
• effort_auto — reasoning effort per agent: judge high, worker and default medium, triage low.
• reasoning_auto — thinking mode on for judge/worker/default, off for triage (a latency-bound, one-token classification).

When an auto is "on" it overrides the corresponding per-agent setting — that is its contract.

Generation parameters

Every entry under params follows include-when-set semantics: an absent field leaves the provider's own default untouched (the request body is byte-identical to having no config at all — which keeps prompt caching intact), and a set field goes on the wire.

Each provider adapter forwards only the parameters its wire supports, and maps reasoning to the provider's native mechanism:

Parameters a provider cannot express are silently dropped — an unsupported knob never fails a request.

Custom prompts

An agent's prompt replaces the built-in base instructions for that agent. Workspace memories and rules still append to it — they are workspace context, not part of the base persona. The pipeline's triage and judge keep their built-in output contracts (the classification token, the PASS/FAIL verdict line); a custom prompt for those agents is prepended as an extra system message rather than replacing the task prompt.

The engine panel in the Command Deck

Everything above is editable interactively. The editor lives permanently in the AGENT ENGINE tab's right column (a 60/40 split beside the executions dashboard — the former /engine popup, now always in view):

• e on the AGENT ENGINE tab focuses the panel — a tab per agent plus a GLOBAL tab (auto modes, allowed_models). Navigate with ↑/↓, press ⏎ to edit a row (enum rows cycle; numeric and text rows take inline input), x clears a field back to "provider default", Esc returns focus to the executions list.
• /model-default, /model-worker, /model-judge, /model-triage jump straight into a type-to-filter model picker for that agent, listing your allowed_models (or the full catalog when the list is empty).
• s saves to your user settings (~/.config/stella/settings.json); S saves to the project (<workspace>/.stella/settings.json). Saves preserve every other key in the file, and apply to runs started from then on.

Degradation is always soft

Configuration can never turn a runnable pipeline into an error. A judge or triage model whose provider has no resolvable credential — or whose adapter fails to build — is skipped with a visible notice, and that role rides the worker's model exactly as it would with no config at all.