Single provider, single key

The three cost profiles mix providers for cross-family judging — which means two or three API keys. If you have one key, everything here works with it. This is the setup most people should run first; graduate to a cross-family judge later if the data says so.

The zero-config baseline

One env var is a working setup — auto-detection does the rest:

export ANTHROPIC_API_KEY="..."   # or OPENAI_API_KEY, ZAI_API_KEY, …
stella run "fix the flaky retry test"

Every pipeline role rides the same model. That is already safe: with no configured judge, the verification ladder's deterministic checks (the test-flip oracle, the diff budget) still gate the result, and the judge role simply rides the worker.

Two habits make one-key runs materially better, no config required:

# 1. Arm the flip oracle — deterministic verification, judge often skipped entirely
stella run --test-command "cargo test -p api" "add cursor pagination to /orders"

# 2. Cap the spend — enforced between steps, aborts cleanly
stella --budget 2.00 goal "the linter passes and the snapshot tests are green"

A tuned one-key profile

When every role is the same family, make the judge behave differently: strict prompt, high effort. Same shape for any provider — swap the model line:

{
  "agent_engine_config": {
    "default_model": "anthropic/claude-fable-5",
    "pipeline_judge_model": "anthropic/claude-fable-5",
    "agents": {
      "judge": {
        "prompt": "You are a strict, evidence-first code judge. Demand proof over plausibility.",
        "effort": "high"
      }
    },
    "reasoning_auto": "on"
  }
}

Why not just always do this?

Cross-family judging exists because an independent model family catches what the worker's family rationalizes — Stella even prefers cross-family automatically when auto_mode is on and the credentials exist. One key is the right starting point, not a ceiling: watch $/resolved in the Observatory for a week, and let the number tell you whether a second key pays for itself.