Providers

Providers tell Nexus where a model lives and how to reach it. A provider can be an online API, a custom compatible endpoint, or a local runtime surfaced behind the gateway.

Open Providers to connect, test, sync, enable, disable, or remove providers.

Provider kinds

Nexus supports these provider kinds:

• OpenAI: OpenAI API models, chat, embeddings, Responses, images, audio, and related OpenAI-style routes where available.
• Anthropic: Anthropic Messages and token counting.
• OpenRouter: OpenAI-style and Anthropic-style routes through OpenRouter.
• OpenAI-compatible local API: user-owned local endpoint that Nexus can route to but does not manage as a process.
• Ollama: Nexus-managed or discovered Ollama runtime.
• llama.cpp: Nexus-managed or discovered llama.cpp runtime.
• MLX: Nexus-managed MLX runtime on macOS hosts.
• CLI Proxy: subscription-backed local API models where available.

The available provider kinds and actions are also exposed by GET /v1/capabilities.

Add a cloud provider

Recommended flow:

1. Click Add Provider.
2. Choose OpenAI, Anthropic, OpenRouter, or a compatible template.
3. Set the display name and base URL if needed.
4. Paste the provider key once.
5. Save.
6. Run Test.
7. Sync models or enable automatic provider models.

Credentials are write-only. Provider responses show credentialConfigured, not the key or vault reference.

Add a compatible endpoint

Use a compatible endpoint when another service already exposes an OpenAI-compatible or Anthropic-compatible API.

Guidance:

• Use a clear provider ID so model IDs remain predictable.
• Set the base URL to the provider's API root.
• Enable only endpoint families the provider actually supports.
• Test before assigning the provider to presets or route packs.

If the endpoint is on the same machine, prefer loopback URLs unless another device must reach it.

Find local runtimes

Use Find Local Runtimes when compatible local apps or servers are already running. Nexus can detect and register compatible local runtime endpoints so their models become available through the gateway.

Discovery candidates report whether they are ready, already registered, offline, or returning an invalid response. A discovered runtime is still subject to the normal provider/model contract after registration.

Automatic provider models

autoProxyModels lets Nexus expose provider-prefixed models returned by the provider without first creating explicit catalog records.

Use it when:

• You trust the provider's model list.
• You want newly available provider models to appear quickly.
• You do not need custom metadata or aliases for every model.

Use manual catalog records when:

• You need stable display names or aliases.
• You want to restrict endpoint families.
• You need to hide or curate the model list.

Explicit catalog records win when they share an ID with an auto-proxied model.

Provider model sync

Provider sync imports model records from supported online providers through the saved credential. It stores safe catalog metadata and prunes stale Nexus-managed imported rows for that provider.

Sync is a background job. Follow progress in the activity strip or the jobs API. Provider keys never appear in job metadata.

Provider diagnostics

The Test action is read-only. It checks configuration, credential presence, provider reachability, and model-list response shape where supported.

Results include stable status values such as:

• ready
• disabled
• missing_credential
• invalid_configuration
• rejected
• unreachable
• invalid_response
• unsupported

Diagnostics do not return raw upstream bodies, credential values, vault references, or raw network error text.

Enable, disable, or delete

Disabling a provider hides its models from the gateway without deleting its configuration. Delete a provider only after models, presets, and route packs no longer depend on it.

If deletion fails with RESOURCE_IN_USE, update or remove dependent models, presets, or route packs first.