--- title: "List Admin Llm Provider Models" method: GET path: "/api/admin/config/llm/providers/{provider}/models" tags: ["admin"] --- # List Admin Llm Provider Models `GET /api/admin/config/llm/providers/{provider}/models` Return models for ``provider`` plus structured failure context. Enumerates ``settings.llm_api_base``, matching what the agent loop passes to ``amessages`` on every call. Previously this called any-llm with no ``api_base`` at all, so the listing went straight to the provider's own API while the agent talked to a gateway. On a gateway deployment that failed outright, because the gateway's virtual key got presented to the real provider ("401 invalid x-api-key"), and an admin could never see the models they were actually able to call. Deliberately takes no caller-supplied ``api_base``. The OSS sibling (``/api/user/providers/{provider}/models``) accepts one because its settings form passes it, but the admin UI does not, so the parameter would be a curl-only surface whose only real effect is to let an admin make the server deliver a provider API key from its environment to an arbitrary host. If the admin form ever needs to preview a candidate endpoint before saving it, add the parameter together with URL validation, not before. Never raises 4xx/5xx for "this provider cannot list models" or "the provider's API call failed". Those are normal admin states; the UI needs to render them, not see a generic 502. We only let through framework-level errors (e.g. validation), which FastAPI handles. ## Path parameters - `provider` string, required ## Response `200` Successful Response - AdminLLMModelsResponse — Structured result of an ``alist_models`` call, with failure context. The admin UI uses this to decide between: - rendering a real ``