No declarative provider for OpenAI-compatible gateways that publish their own catalogue
What problem would this solve?
goose ships 47 declarative provider definitions, several of them OpenAI-compatible gateways that front many makers' models (EUrouter, AI/ML API, TrustedRouter, Vercel AI Gateway, OpenCode Zen and others). Each new gateway of that kind currently needs its own definition added by hand, and a user of a gateway that is not in the list has to configure a custom OpenAI endpoint and loses the model list, the context limits and the cost estimates.
Cheaper Inference is one such gateway: one OpenAI-compatible endpoint, one API key, 60 chat routes under their makers' own names, and an authenticated GET /v1/models that publishes per-model prices, context and output limits and capability flags.
What would a good outcome look like?
A user sets the gateway's key, sees its models in the picker with the right context limits, and the cost estimate matches the gateway's published rates - without a hand-written definition going stale behind them.
Possible approaches
No design proposed here on purpose; the problem is the general one, and the trade-off worth discussing is whether these gateways are better served by more hand-added definitions or by reading a catalogue the gateway already publishes. The data these gateways publish is exactly what a declarative definition carries, so the gap is not missing capability but missing entries - and entries go stale: between two readings of this one catalogue three days apart the model count went from 16 to 66, and four routes changed price within one 23-hour window.
Additional context
I have access to this provider's API for testing and am willing to implement whatever direction the issue settles on. One thing found while probing: the gateway's own capability flags are wrong in both directions, so any design that trusts them unverified would carry the errors through.
- I have verified this does not duplicate an existing feature request
Source: aaif-goose/goose