Providers & models.

Choosing a route

squeezy works with 27 providers, and the tables below list every one. The quickest start is an aggregator: one key reaches many hosted models. A vendor's own API, a subscription you already pay for, your cloud account, a dedicated model host, and a server on your own machine all work the same way. Pick one, then give it a credential. Each row names what that provider reads.

The first launch walks you through it: a theme, then a provider, then a model, then how hard that model should think. When the provider needs a credential, one more step takes the key or starts the sign-in. What it saves is a named model config in your own settings, with your everyday work pointed at that name.

Later, squeezy auth set <provider> stores a key in your protected User credential store. Add --local to keep it in this checkout's protected store instead. It reads the key from standard input, so nothing lands in your shell history. The two subscription sign-ins have commands of their own: squeezy auth openai-codex login, and squeezy auth github-copilot login.

Two commands tell you whether it worked. squeezy auth status reports which providers have a credential and where each one resolved from. squeezy providers list prints every provider with the address it calls, the environment variable it reads, and whether it is configured. If a matching variable is exported for this launch it beats a key in protected storage, and squeezy auth set reports that shadowing rather than implying the stored key took effect.

Setting it in a file

Every provider above has a short id. In a settings file you write that id into a model config: a provider, a model, and any knobs you want, kept together under a name you choose. You then point your everyday work at the name. It is the same shape the first launch writes for you, so the first edit you make by hand is a variation on something rather than a cold start.

[models.work]
provider = "openrouter"              # a provider id from the tables above
model = "anthropic/claude-sonnet-5"  # an exact id that provider serves

[roles]
build = "work"                       # the config your everyday work runs on

[providers.openrouter]
api_key_env = "OPENROUTER_API_KEY"   # credential identity only; use `squeezy auth set openrouter`

Model configs belong to you, not to a repository. A provider config can name a credential identity, but never carries the secret itself; shared squeezy-settings.toml files cannot own credentials. squeezy config init --user writes a commented starter file in the right place. Store the secret with squeezy auth set <provider>; the api_key_env line is only the profile's credential identifier. A provider's ambient variable remains useful for one launch or CI. For one run, --provider <id> on its own is enough, and the model falls back to that provider's default -- except on Azure OpenAI, PortKey, and a server on your own machine, which have no default to fall back on and ask for an exact id.

On top of the built-in defaults, a setting can come from six places: your personal settings, the project's squeezy-settings.toml, per-machine settings for that project, the environment, the flags you launched with, and the session itself. Each one overrides the one before it. When a value is not what you expected, squeezy config show model.provider names which place it came from, and squeezy config dump prints the whole merged result with secrets redacted. The configuration page covers the layers in full.

A cheaper model of your choosing

Turn routing is on by default. Left to itself, every turn starts on the model you chose. When the work looks self-contained and mechanical, the rest of that turn can run on the model you pointed routing at; when it turns out to be harder than that -- tool calls piling up, errors, a refusal -- the same turn steps back up without starting over. That model is one you name, and it runs on whichever provider profile you gave it: point it at the exact profile your main model uses and your traffic and bill stay there, or point it anywhere else -- another vendor, or a second profile of your own on the same vendor -- and that turn bills to the key that profile names. Same vendor is not the same account: a sibling profile with its own credential is billed as its own. Naming a cheaper one is the whole point, but nothing here checks a price list -- the turn goes where you pointed it. Nothing routes at all until you point it somewhere, so a session with neither a cheaper nor a more capable model configured simply stays on yours.

You can decide it by hand for one turn. /router cheap runs the next turn on the model you pointed routing at, or on your own model when nothing is pointed there -- an unset pointer, one resolving to the very Model profile you are already on, or one whose provider will not build -- so the turn runs rather than being refused. A second profile of your own naming that same model is a rung in its own right, and /router cheap runs on it. /router main runs it on the active role's Model profile; either takes the prompt on the same line. /model switches which saved config the session runs, and that switch applies at once without touching a file, with a separate key on the same screen to write it down. See how it works for the full picture, or run squeezy help providers for the same reference offline.