Manage LLM providers and models, Sync models from external registries, run health checks, and configure per-organization API keys for independent billing.
Entity Enricher supports a wide range of LLM providers. Each provider can have multiple models with individual pricing, capabilities, and configuration.
Many teams route LLM traffic through a corporate AI gateway, a regional endpoint, or a provider that isn't built in — for example an enterprise LiteLLM proxy, Cloudflare AI Gateway, or Alibaba DashScope (for Qwen models). You add these as their own Standard (OpenAI-compatible)provider with a custom base URL.
acme-openai-gw). Built-in names like openai or anthropic are reserved. https://gateway.example.com/v1. This field is required for any provider Entity Enricher has no built-in client for. https:// URLs. Loopback and private ranges (localhost, 10.x, 192.168.x) are rejected to prevent SSRF — a self-hosted server must be reachable over the internet. For a local Ollama, use the dedicated Ollama tunnel instead./v1 protocol (chat completions, /models). {endpoint}/models to verify the key and base URL before you run an enrichment.Each provider has a Max concurrent calls per key setting (its rate-limit override). It caps how many LLM calls a single API key runs in parallel — covering every flow that uses the key: the multi-expertise enrichment fan-out, classification, arbitration, and schema / sample generation.
This is separate from your plan's max concurrent jobs limit, which caps how many enrichment jobs your whole organization runs at once across all providers.
Each model tracks its capabilities, which are displayed as icons in the model selector:
| Capability | Description |
|---|---|
| Vision | Can process image and visual inputs |
| Tool Calls | Supports function calling / tool use |
| Audio Input | Can process audio inputs |
| PDF Input | Can process PDF documents |
| Prompt Caching | Supports prompt caching for cost reduction |
| Reasoning | Extended thinking / chain-of-thought capabilities |
Keep model pricing up to date by syncing from external registries. The sync process detects new models, price changes, and removed models automatically.
The default pricing source. Fetches from LiteLLM's community-maintained registry on GitHub with real API model names, pricing, context lengths, and capabilities.
Covers ~30 providers. Does not include display names, benchmarks, or generation speed.
An alternative source from pricepertoken.com. Includes display names, benchmarks (coding and math scores), and generation speed (tokens per second).
Covers ~20 providers. Provides richer metadata than LiteLLM.
Proactively validate whether models are reachable by running a minimal health check prompt. This catches broken models before users encounter errors during enrichment.
Health checks can be run on all models, a specific provider's models, or a single model. Results stream in real time via SSE with a progress bar showing pass/fail counts.
When an enrichment call fails with a “model not found” error, the model is automatically deactivated to prevent repeated failures. This happens in real time during normal enrichment operations.
| Deactivation Reason | Set By | Auto-Reactivated? |
|---|---|---|
| Model Not Found | Enrichment errors or health checks | Yes (by pricing sync or validation) |
| Sync Removed | Pricing sync (model disappeared) | Yes (if model reappears in registry) |
| Manual | Admin toggle in UI | No (manual reactivation only) |
Organizations can configure their own LLM provider API keys for independent billing and usage tracking. The system uses a two-tier key resolution with LRU selection:
Per-organization keys configured in the API Keys page. Supports multiple keys per provider with LRU rotation. Encrypted with Fernet.
System-wide keys managed by administrators. Shared across all organizations. Also supports multiple keys per provider with LRU rotation.
Each enrichment records which key was used, so you can track costs per key. Keys include health check support, usage counters, and are automatically disabled on permanent failures (invalid key, payment required). Rate-limited keys are temporarily backed off while other keys in the pool are used. Learn how to manage keys in the API Keys guide.
Export your entire provider and model configuration as JSON for backup or transfer to another instance. Importing is always an upsert: existing providers and models are matched by name and updated in place, while new ones are added — nothing is deleted.
The export includes provider settings, model configurations, pricing, capabilities, and the canonical model specs — but never API keys, which are stored separately. After importing, configure API keys separately. System admins back up the full global catalog; organization owners export and import only their own organization’s providers and models — the shared global catalog can’t be created or edited through import.