AINOX PLATFORM

Model providers & language models

Connect the workspace to an OpenAI-compatible endpoint, choose which of its models people can chat with, and pick the workspace default.

A model provider is the connection between your workspace and the service that actually runs the language models — a hosted API, a self-hosted inference server, or anything else that speaks the OpenAI API. Until a workspace has at least one provider with an enabled model, the chat composer shows a Configure a model warning and nothing can be asked.

Registering a provider does two things: it stores the endpoint and its credentials, and it asks the endpoint which models it offers. You then decide which of those models the workspace is allowed to use, and which one is the default.

Prerequisites

  • Workspace admin or owner. Managing providers needs the ai_provider:write permission — without it the page is read-only and the Add Model Provider, refresh and edit controls are hidden.
  • An endpoint that answers GET {base URL}/models with an OpenAI-style model list, plus its API key if the endpoint requires one.

Open the Model Provider page

  1. In the sidebar, open Admin. Model Provider is the first entry and the page Admin opens on by default. Each registered provider is a card showing its base URL, an API-key hint, when it was added, and how many of its models are enabled.

    Model Provider admin page listing one provider card with an Active status pill

Add a provider

  1. Click Add Model Provider and pick a provider type. Today there is one: OpenAI-Compatible, which covers OpenAI itself and any server that implements the same API.

    Add Model Provider button expanded showing the OpenAI-Compatible option

  2. The dialog asks for three things. Name is just a label for this list, so use something recognisable. Base URL is the API root — the part before /models, usually ending in /v1. API key is optional and can be left blank for endpoints that do not authenticate.

    Empty Add Model Provider dialog with Name, Base URL and API key fields

  3. Fill the fields in. The API key is masked as you type; use the eye icon at the end of the field to check it before saving.

    Add Model Provider dialog filled in with a name, a base URL and a masked API key

  4. Click Add provider. The workspace calls the endpoint straight away to fetch its model list, and the provider is only saved if that call succeeds. A wrong key, an unreachable host or an endpoint that does not return a model list all stop the save and explain themselves in the dialog, with your input preserved so you can correct it.

    Add dialog showing the error "Provider rejected the API key. Double-check the key and try again."

  5. Once the endpoint answers, the provider appears in the list. It starts with an amber No models enabled pill: the connection works and the models were discovered, but nobody can use them yet.

    Provider list with a newly added provider showing a "No models enabled" status and 0 of 2 models

Choose which models people can use

  1. Click the chevron on the right of a provider card to expand its discovered models. Every model has a switch, and all of them start off.

    Expanded provider card listing two discovered models, both switched off

  2. Switch on the models you want available. The change saves immediately, the counter updates, and once at least one model is on the pill turns green and reads Active.

    Same card with one model switched on, the status pill now reading Active and 1 of 2 models

    Only enabled models appear in the chat model picker, so this is the list people in the workspace actually get to choose from. Use the refresh icon next to the chevron whenever the endpoint gains or loses models — it re-reads the model list without touching anything else.

Set the workspace default model

  1. Click System model setting at the top of the page. The picker lists every enabled model across all providers, written as provider · model, with a search box for long lists. Choosing one makes it the model new chats start with; it is marked with a tick here and with a Default badge next to the model in its provider card.

    System model setting popover listing enabled models from both providers with a search box

    If no model is enabled anywhere, the button is disabled — enable one first.

Edit or remove a provider

  1. Open the menu on a provider card.

    Provider card menu open showing Edit settings and Remove

  2. Edit settings reopens the same three fields. The API key box is blank on purpose: leave it that way to keep the current key, or type a new one to replace it. The stored key is never shown back to you — only a short hint of its last characters appears on the card.

    Edit Model Provider dialog with the name and base URL filled and the API key field showing "Leave blank to keep current key"

  3. Remove — or the Delete button inside the edit dialog — asks for confirmation first. Existing chat threads keep their full history, but new chats lose access to that provider's models.

    Delete Model Provider confirmation dialog

Check the default before removing

Removing the provider that owns the workspace default model leaves new chats without one. Point System model setting at a model on another provider first.

Notes

  • The three statuses. Green Active means reachable with at least one model enabled. Amber No models enabled means reachable but unusable — switch a model on. Red Not connected means no models were discovered; refresh the provider to retry, then check the base URL and key.
  • Embedding, reranking and OCR models are hidden. The list only shows models that can hold a conversation, so an endpoint that also serves an embedding model will show fewer models here than it reports.
  • The base URL must be the API root. The workspace appends /models to it during discovery, so give it the root (for example ending in /v1), not a full model-list URL.
  • API keys are stored encrypted and never returned to the browser, which is why the card and the edit dialog only ever show a hint.
  • Providers are workspace-scoped: adding one here does not affect any other workspace.