What problem would this solve?
A goose user who has to keep prompts inside the EU currently has four declarative providers to choose from: mistral, ovhcloud, scaleway and opper. Of those, Mistral serves only its own models, and Opper is a gateway that routes onward. For open-weight models such as Qwen or Llama served directly from EU hardware, there is no entry.
This affects teams in regulated work — public sector, healthcare, legal, finance — where the constraint is not a preference but a contract. They can run goose today only by pointing it at a generic OpenAI-compatible base URL, which means no catalogue entry, no model list, and no way to discover the option in goose configure.
What would a good outcome look like?
Someone who needs EU-resident inference for an open-weight model finds it in the provider list, the same way they find Scaleway or OVHcloud today, and gets a working model list without hand-editing config.
Possible approaches
The obvious one is a declarative provider definition, since the endpoint is OpenAI compatible and needs no engine work. That is the shape used by PR #11589 (Opper), which was two files: one line in crates/goose-providers/src/declarative.rs and a JSON definition in crates/goose-providers/src/declarative/definitions/.
I operate one such endpoint and am happy to write it, but I am opening this as an issue first rather than a PR, per the contribution guide.
Constraints worth settling in the design discussion:
- Whether the catalogue should carry any region or data-residency signal at all, or whether that belongs purely in the provider description string. Today
ovhcloud and scaleway say nothing structured about region, and a user comparing providers cannot filter on it.
- Whether single-model providers are wanted in the declarative list, or whether there is a minimum catalogue size.
Additional context
The provider I would add is LLM Tech: Qwen3.8-27B in NVFP4 on a dedicated RTX PRO 6000 in Helsinki, 262,144 context, tool calling, image input, prompt caching, no prompt retention. It is already present in models.dev, so provider_metadata.json in this repo carries it, but the declarative definitions are a separate list and it is not there.
What problem would this solve?
A goose user who has to keep prompts inside the EU currently has four declarative providers to choose from: mistral, ovhcloud, scaleway and opper. Of those, Mistral serves only its own models, and Opper is a gateway that routes onward. For open-weight models such as Qwen or Llama served directly from EU hardware, there is no entry.
This affects teams in regulated work — public sector, healthcare, legal, finance — where the constraint is not a preference but a contract. They can run goose today only by pointing it at a generic OpenAI-compatible base URL, which means no catalogue entry, no model list, and no way to discover the option in
goose configure.What would a good outcome look like?
Someone who needs EU-resident inference for an open-weight model finds it in the provider list, the same way they find Scaleway or OVHcloud today, and gets a working model list without hand-editing config.
Possible approaches
The obvious one is a declarative provider definition, since the endpoint is OpenAI compatible and needs no engine work. That is the shape used by PR #11589 (Opper), which was two files: one line in
crates/goose-providers/src/declarative.rsand a JSON definition incrates/goose-providers/src/declarative/definitions/.I operate one such endpoint and am happy to write it, but I am opening this as an issue first rather than a PR, per the contribution guide.
Constraints worth settling in the design discussion:
ovhcloudandscalewaysay nothing structured about region, and a user comparing providers cannot filter on it.Additional context
The provider I would add is LLM Tech: Qwen3.8-27B in NVFP4 on a dedicated RTX PRO 6000 in Helsinki, 262,144 context, tool calling, image input, prompt caching, no prompt retention. It is already present in models.dev, so
provider_metadata.jsonin this repo carries it, but the declarative definitions are a separate list and it is not there.