Goose
Goose is Block’s open-source agent.
LowRouter plugs in as a provider of its own: one file makes
LowRouter appear in Goose’s provider list with its own key, every
auto/ model that takes tools with its context window, your aliases
when you download it with your key, and session costs shown in euros.
Verified against Goose v1.52.0. The config below is re-run against that release every week.
Install the provider
Download the provider definition into Goose’s custom providers directory. LowRouter builds it from the live catalogue on every request:
mkdir -p ~/.config/goose/custom_providers
curl -fsSL https://api.lowrouter.ai/v1/integrations/goose.json \
-o ~/.config/goose/custom_providers/lowrouter.jsonTo include your own models, download it with your key instead. The
file then also lists your aliases as
alias/<name>, and your catalogue curation
narrows the list exactly as it does on /v1/models:
curl -fsSL https://api.lowrouter.ai/v1/integrations/goose.json \
-H "Authorization: Bearer $LOWROUTER_API_KEY" \
-o ~/.config/goose/custom_providers/lowrouter.jsonOn Windows the directory is %APPDATA%\Block\goose\config\custom_providers\.
Restart Goose Desktop if it is open. LowRouter is now listed under
Configure Providers, both in Desktop’s provider settings and in
goose configure; pick it and paste your key. Goose stores the key in
the system keyring.
For scripts, containers and CI, set the provider and key in the environment instead. Environment variables take precedence over the keyring:
export GOOSE_PROVIDER=lowrouter
export GOOSE_MODEL=auto/mistralai/mistral-large-2512
export LOWROUTER_API_KEY=sk-lr-...Then start a session:
goose sessionOn a headless machine with no keyring service (a container, a CI
runner), also set GOOSE_DISABLE_KEYRING=1 so Goose falls back to
file-based secret storage instead of failing to open a keyring.
What the file gives you
- Every
auto/model that takes tools. The file lists each tool-capable chat model under itsauto/ID and under each jurisdiction-scoped form, such asauto/mistralai/mistral-large-2512/eu-sovereign. A model whose context window the catalogue does not publish is left out, because Goose rejects the whole file over one entry without a window; it still works if you type its ID. Goose reads the file once, so download it again to pick up new models, changed prices or new aliases. - The window Goose can rely on. Each model’s context limit is the smallest across the routes it can resolve to, so a long session does not overflow when a request lands on a smaller route.
- Costs in euros. Each entry carries the price of the route the
default profile resolves to at download time, in EUR. Goose shows the
exact cost LowRouter reports on every response (
usage.cost, in EUR) with a€sign; the listed prices feed Goose’s per-model tooltip. - Any other LowRouter ID still works. Set
GOOSE_MODEL(or use Enter a model not listed in Desktop) to a pinned route such asmistral/mistralai/mistral-large-2512/eu. Goose assumes a 128k context window for a model that is not in the file. - GPT-5 and GPT-6 models go through the Responses API. Goose routes
those names to
/v1/responseson its own; LowRouter serves it, with streaming and tool calls.
Without the file
Goose’s generic OpenAI provider also reaches LowRouter. The provider
then shows up as “OpenAI”, the key has to be OPENAI_API_KEY, and the
real OpenAI provider cannot be configured at the same time, because
both read the same variables. Use this only where you cannot drop a
file into the config directory.
Goose’s OpenAI provider takes the host only. It appends
v1/chat/completions itself, so OPENAI_HOST must not end in
/v1. With /v1 on the host every request goes to
/v1/v1/chat/completions and fails with a 404.
Set the provider, host and model in ~/.config/goose/config.yaml:
GOOSE_PROVIDER: openai
OPENAI_HOST: https://api.lowrouter.ai
GOOSE_MODEL: auto/mistralai/mistral-large-2512The API key does not go in that file. Goose ignores an
OPENAI_API_KEY line in config.yaml because it reads secrets from the
system keyring, and the symptom is a 401 Missing Authorization header on the first request. Either run goose configure, pick the
OpenAI provider and paste the key when prompted, or export it. With this
provider goose configure cannot enter a custom model name; set
GOOSE_MODEL in the file or the environment, as above:
export GOOSE_PROVIDER=openai
export OPENAI_HOST=https://api.lowrouter.ai
export OPENAI_API_KEY=sk-lr-...
export GOOSE_MODEL=auto/mistralai/mistral-large-2512Picking a model
Goose drives its tools through function calling, so for agentic tasks (file reading, shell tools, multi-step reasoning) pick a model with the function-calling tag. Every model in the provider file has it. The model browser filtered to them lists every one, including those not in the file.
Recommended setup
- Use a dedicated key. As with the other agents, agentic loops can run away; a key of its own lets you see the spend per agent and revoke it without touching anything else.
- Limit the toolset Goose has access to. Goose’s
extensionsconfig lets you allow only the tools the workflow needs, and fewer enabled tools means fewer surprises. - Set a step limit. Goose has a max-step setting; cap it at a small number for unattended runs.
Troubleshooting
- LowRouter is not in the provider list: the file is not in the
custom_providersdirectory Goose reads (the paths above), or Goose Desktop was not restarted after the download. - An alias is missing from the picker: the file was downloaded
without your key, or before the alias was created. Download it again
with the
Authorizationheader. 404on every request (generic OpenAI provider):OPENAI_HOSTends in/v1(or another path). Goose addsv1/chat/completionsitself; the host is the bare origin.401 Missing Authorization headerorNo api key passed in: the key is inconfig.yaml, where Goose does not read it. Move it to the environment or togoose configure.- Tool calls fail silently: verify the chosen model actually supports function calling (its page on the model browser). Some smaller models don’t.
