Skip to content
Wavertex
Documentation menu

Providers and models

Verified with Cortex on October 2, 2026

A destination is a language model that Cortex can reach: a provider, an endpoint, a model and the rules that apply to it. Your employees only see the destinations you open to them, and every message goes through DLP filtering before reaching one. This page covers configuring destinations, models, routing, caching and web search.

What a destination is

In the administration console, "Destinations" lists your destinations: "Name", "Type", "Model", "DLP profile", "Roles" and "Status". "Type" shows "Local" for an engine you host (ollama, lm_studio, vllm, custom_local) and "External API" for an online service; it follows from the provider you chose. A destination already referenced by conversations cannot be deleted: use "Disable" instead.

Cortex screenshot: the list of LLM destinations with one local destination, Qwen 3.5 9B, its model, its full DLP profile, its roles and its action buttons
A local destination: type, model, DLP profile, allowed roles and actions.

Add a destination

  1. Open "Destinations", then "New destination".
  2. Choose the "Provider" from the catalog (openai, anthropic, azure_openai, google_gemini, mistral, groq, together_ai, openrouter, deepseek, xai, ollama, lm_studio, vllm, or custom_openai, custom_anthropic and custom_local for a compatible service).
  3. Enter an "Identifier (slug)" (lowercase letters, digits and hyphens) and a "Display name". The identifier cannot be changed after creation.
  4. Enter the "Model", or click "Discover models" to pick it from the list the endpoint reports.
  5. Fill in the "Endpoint": optional when the provider has a default address, required for azure_openai and the custom_* providers. The "API key" is required for the catalog's external providers (openai to xai).
  6. Choose the "DLP profile" ("Full DLP" by default), tick or untick "Response cache", and tick at least one of the allowed "Roles" ("Employee" by default).
  7. Click "Create". The dialog stays open and grows: the connection-test button (plug icon) next to the "Endpoint" becomes active, and the "Authorized models" and "Routing" sections and the "Web search" switch appear.

Authorize models

In "Edit", the "Authorized models" section first lists only the models already authorized (initially, the default model): click "Discover models" to show those the endpoint reports. A checkbox authorizes each model, a "default" radio button marks the one used by default, and "Filter models…" helps with long lists. For each authorized model, three checkboxes declare its capabilities: "Vision", "Tools" and "Reasoning". You declare them: Cortex does not detect them.

Routing and failover

A destination's "Routing" section sets three things.

  • "Load balancing": "Round robin", "Weighted" (by weight) or "Least loaded" (the least in-flight load in the gateway). It chooses between the destination itself and its active replicas.
  • "Replicas": other endpoints for the same model ("Add replica"), each with its "Endpoint", "API key", a "Weight" from 1 to 100 and a switch.
  • "Fallback chain": up to five other destinations, in order ("Add a fallback…", then "Save"). The chain is not transitive: a fallback's own fallbacks are not followed.

When a provider fails, Cortex retries the same destination (two attempts in total by default) with a growing wait, then moves to the next fallback. Only errors judged retryable are retried; the others go straight to the fallback. Once the reply has started, Cortex no longer switches destination. Every switch is recorded in the audit journal. The attempts are set in .env:

ROUTING_RETRY_MAX_ATTEMPTS=2   # attempts per destination, 1 to 5
ROUTING_RETRY_BASE_MS=200      # base wait before a retry, 0 to 5000

Response cache

The cache reuses an answer when the same request comes back. It takes two authorizations: the deployment turns it on (off by default), then each destination keeps its "Response cache" box ticked.

  • An answer is found again only for the same destination, model, parameters and redacted messages: the key is computed on the tokens, never on your real values, and entries are encrypted with the tenant key.
  • Its lifetime is the shorter of CACHE_TTL_SECONDS and the conversation retention.
  • A request with web search never uses the cache, and the roles in CACHE_EXCLUDED_ROLES neither read from it nor feed it.
CACHE_ENABLED=true
CACHE_BACKEND=memory     # or redis, with REDIS_URL

Change these variables in the root .env, then recreate the container with docker compose up -d gateway. The redis backend relies on the cache compose profile.

The search is run by the gateway, not by the model. It takes three things.

  1. The deployment: WEB_SEARCH_ENABLED=true and WEB_SEARCH_BASE_URL in .env, with WEB_SEARCH_ENGINE (searxng by default, or brave, which requires WEB_SEARCH_API_KEY), then recreate the gateway container (docker compose up -d gateway). While WEB_SEARCH_ENABLED is not true, the "Web search" page shows "Web search is disabled by the deployment configuration." and nothing on it can be changed; with true but a missing or invalid WEB_SEARCH_BASE_URL, the gateway refuses to start.
  2. The destination: in "Edit", the "Web search" switch.
  3. The "Web search" page of the console, described below.
  • "Search engine": the "Engine", the "Host" and the "Address resolution" ("Public", "Private" or "Unknown"). An engine that is "Not attested" is treated as external. If the engine resolves to a private address, "Attest engine…" opens a two-step confirmation (a checkbox and the word "ATTEST"); a public engine cannot be attested. "Withdraw attestation" undoes it.
  • "Allowed domains": when the list is not empty, only results from these domains and their subdomains are kept.
  • "Blocked domains": results from these domains are always dropped. Enter bare domains (example.com), with no wildcard or port.
  • "Query policies per role": they apply when the message still carries redacted items. "Block" refuses the search, "Degraded" removes the protected terms from the query, "Cleartext" sends the original text, but only toward an attested engine. The strictest role wins; a role without an explicit policy reads as "Block".