By default every workspace answers on BeforeQuery’s own provider keys. Point a workspace at your provider account instead and inference is billed to you, runs under your data agreements, and can target a model or endpoint we don’t offer. Configure it under Workspace → Settings → Model.
This is a self-hosting and enterprise feature. If the deployment has no encryption key configured, the endpoints return 501 — every workspace simply keeps answering on the deployment’s keys, exactly as before. It isn’t broken; the feature is unavailable.

​
Set a provider

Reading the settings back returns has_api_key — a boolean — never the key itself.

​
Test before you save

Makes one small live chat call and reports the result. Omit api_key to test the credential already stored, rather than re-sending it. It does not check embeddings.

​
Clear it

Reverts the workspace to the deployment’s model and keys.

​
Which model answers a question

Resolution runs in this order:
  1. The knowledge base’s own llm_provider / llm_model, if set
  2. The workspace’s llm_settings
  3. The deployment’s configuration
The credential lives at workspace level — one provider account per customer — while the per-knowledge-base columns choose which model runs on it. So you can bill everything to one account and still let a code-heavy knowledge base answer on a stronger model.
A question spanning several knowledge bases ignores the per-knowledge-base override, because there’s no principled way to pick between two configured models. It uses the workspace setting.

​
What routes through your account

Answering a question is four paid calls, not one, and your key pays for all of them it can. Two stages can stay with BeforeQuery, and the Model settings page names which ones apply to your workspace rather than leaving you to infer it. Passage scoring moves to your model only when the deployment has no reranking vendor configured. A hosted cross-encoder is a different vendor with a key of ours; your chat credential does not reach it. Embeddings move only for an OpenAI key against the OpenAI API. Every chunk in your index was embedded by one model, and a question’s vector is comparable only with vectors from that same model — so the key may change and the model may not. An Anthropic, Gemini or Bedrock credential has nothing that can embed here, and a proxy or self-hosted endpoint serves your chat models rather than this one.

​
Other providers

provider names the API format the server speaks, not the company billing you — and almost every hosted vendor speaks OpenAI’s. So provider: openai plus that vendor’s base_url reaches all of these, and the dashboard lists them by name rather than making you remember the endpoint: Anything else that serves POST /chat/completions works the same way, listed or not.

​
Amazon Bedrock

Bedrock is its own provider, not an OpenAI-compatible endpoint: requests are signed with AWS SigV4 and streaming replies arrive in AWS’s binary event-stream framing rather than as server-sent events. That makes its credential a bundle rather than a key, so api_key carries JSON:
The dashboard renders the two fields and packs them for you. ACCESS:SECRET[:REGION[:SESSION_TOKEN]] is accepted too, for anything set by hand; a bare string is taken as a Bedrock API key and sent as a bearer token instead of being signed. base_url carries the region, as https://bedrock-runtime.<region>.amazonaws.com. It lives there rather than in the credential because base_url is the one field read back to the browser — packed into the encrypted bundle instead, changing region would mean re-entering the secret.
model is an inference profile id, and the us. / eu. / apac. prefix is part of it: us.anthropic.claude-sonnet-4-5-20250929-v1:0. A bare anthropic.claude-… only resolves in regions that serve it on-demand. The prefix must match the region, and the model must be enabled first under Model access in the Bedrock console.
The IAM policy needs bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream, and nothing else. Self-hosting on AWS? Set bedrock.allowAmbientCredentials and the deployment signs with its EC2 instance role or EKS service account, with no key stored anywhere. That path is for the deployment’s own configuration only — a workspace that selects Bedrock without supplying a credential is refused rather than billed to the host’s AWS account.

​
Private and self-hosted endpoints

base_url accepts any OpenAI-compatible endpoint, which covers OpenRouter, vLLM, Ollama, LM Studio and LocalAI.
Azure OpenAI is not among them, despite speaking a near-identical request body. It authenticates with an api-key header rather than a bearer token and puts the deployment name in the path with an api-version query parameter, so pointing base_url at an Azure resource fails on authentication.
The URL is validated as an SSRF sink: https and public addresses only. Pointing it at a private or loopback address is refused unless the operator has set security.allowPrivateLLMEndpoints, which a self-hosted deployment running Ollama on the same network will need.

​
Models offered in the dashboard

The dashboard lists these per provider. base_url lets you name any other model your endpoint serves.

​
API

Only workspace owners and admins can change these — see Roles & Permissions.