Providers & models
The full list of providers, how to pick a model, how stella finds your API key, and how to point it at a local OpenAI-compatible server.
stella works with any model provider. It speaks each provider's own protocol, and figures out which one to use from the API keys you have set.
For setup walkthroughs, provider-specific configuration, and model names, see API Providers. For help choosing between models, including pricing, release dates, and what each one is best at, see the model guide.
Supported providers
Each card shows what you need: the provider id you put before the / in
--model, the environment variable stella reads, the model you get by
default, and the protocol it speaks. Click through for setup and
provider-specific configuration.
List every provider at any time, along with live key status and the base URL each one resolves to:
stella modelsThat listing is the source of truth on your machine. It's the only view that knows which keys you actually have. The cards above come from the same data as the API Providers index, so the two pages always agree.
Pick a model
Set the model for one run with --model provider/model_id. Or set the
STELLA_MODEL environment variable to use it for the whole shell session:
stella --model zai/glm-5.2 run "fix the failing test"
export STELLA_MODEL=anthropic/claude-fable-5With no --model set, stella picks a provider automatically. It uses the
first one with a working credential, in this order: zai, anthropic,
openai, xai, deepseek, gemini, openrouter, then vertex and
bedrock last.
Vertex and Bedrock come last on purpose. They rely on general cloud
credentials (VERTEX_ACCESS_TOKEN, AWS_ACCESS_KEY_ID) that are often set
for unrelated reasons. Auto-detection never picks them over a provider you
configured on purpose. Use --model vertex/… or --model bedrock/… when
you want them.
Credential chain
For the provider you're using, stella looks for an API key in this order. The first one it finds wins:
--api-keyflag (needs an explicit--model provider/...)- The provider's environment variable, and its aliases — for example,
GOOGLE_API_KEYfor Gemini settings.jsonproviders.<id>.api_key~/.stella/credentials.toml- An interactive prompt, if you're in a terminal. The key you enter is
saved to
credentials.toml, so you're only asked once.
Before step 2 (the environment variable) runs, stella first loads project
dotenv files into the environment, most specific first: .env.<mode>.local
→ .env.local → .env. The nearest scope wins, and this search never goes
past the enclosing git repository — never the home directory or above. It
never loads .env.example or a committed .env.<mode> file. A value you
export in your shell always wins over a file value, and
STELLA_NO_ENV_FILE=1 turns this off entirely.
See Credentials for the file format and precedence details.
For anything long-lived, use an environment variable, settings.json, or
credentials.toml instead of --api-key. A flag value shows up in your
shell history and in ps output.
Cloud provider setup
Vertex AI also needs a project. Set VERTEX_PROJECT_ID (or
GOOGLE_CLOUD_PROJECT), and optionally VERTEX_LOCATION (defaults to
global). Get the access token with
export VERTEX_ACCESS_TOKEN=$(gcloud auth print-access-token).
export VERTEX_ACCESS_TOKEN=$(gcloud auth print-access-token)
export VERTEX_PROJECT_ID="my-gcp-project"
stella --model vertex/gemini-3-pro run "audit the IAM bindings module"Amazon Bedrock needs AWS_SECRET_ACCESS_KEY along with
AWS_ACCESS_KEY_ID. It also accepts an optional AWS_SESSION_TOKEN and
AWS_REGION (or AWS_DEFAULT_REGION), which defaults to us-east-1.
export AWS_ACCESS_KEY_ID="AKIA..."
export AWS_SECRET_ACCESS_KEY="..."
export AWS_REGION="us-east-1"
stella --model bedrock/us.anthropic.claude-sonnet-4-5-20250929-v1:0 run "harden the S3 policy module"Only AWS_ACCESS_KEY_ID, Bedrock's main credential, follows the credential
chain above. The other variables (AWS_SECRET_ACCESS_KEY,
AWS_SESSION_TOKEN, AWS_REGION) are read only from the environment.
There's no credentials.toml entry, no settings.json field, and no
prompt for them. See Amazon Bedrock
for the full details.
Local servers
The local provider points at any OpenAI-compatible endpoint: Ollama,
vLLM, LM Studio, or a llama.cpp server. It's never chosen automatically, and
it needs no API key:
stella --model local/llama3.3 --base-url http://localhost:11434/v1 chatThe id local is reserved. You cannot redefine it in settings.json,
and --base-url (or the environment variable STELLA_BASE_URL) is always
required with --model local/<model>. To avoid typing the endpoint every
time, either export STELLA_BASE_URL, or define your own provider under a
different id in settings.json — for
example providers.myollama with a base_url set (its dialect defaults
to openai-compatible) — and use it with --model myollama/<model>.
Override provider defaults
You can override any built-in provider's base URL, key, display name, or
default model in settings.json. For
example, you could route Z.ai through its coding-plan endpoint without a
provider-specific environment variable. For personal routing, like a
subscription endpoint, put the override in user scope
(~/.stella/settings.json) instead. Project-scope base_url and api_key
overrides are held back by the
trust boundary
until you set STELLA_TRUST_PROJECT=1. Ready-to-paste setups, organized by
use case, live in Examples & recipes, including the
Z.ai coding-plan recipe.