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 |
| Embeddings | Turns text into a vector instead of answering — what semantic IDs are resolved with. Embedding models are their own family, with their own vector size, and never appear in an enrichment picker |
Naming a model is optional. Enrichment, schema generation and sample generation all accept auto — and treat an omitted model as auto — which is resolved on the server, per task, at the moment the job starts. The run reports which model it picked, so automatic never means opaque.
Owners can pin a preferred model per task under Settings → Organization → Defaults. If one is set for the task at hand, it wins.
Failing a pin, the pick is the model with the best blended score from your scoring-source benchmarks — your own measurements of quality, speed and cost on your own schemas. With no scoring source at all the request is refused rather than guessed at.
Turning on web search, or attaching a document that must be sent as-is, restricts the candidates to models that can actually do it — and if none qualifies, you get an explicit error instead of a silent downgrade.
A model can also be barred from one task without being deactivated: a model that enriches well but generates poor schemas can be hidden from the schema and sample generation pickers only, either for your organization or globally by an administrator. It stays fully available everywhere else — a softer instrument than the deactivation below.
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.
An official authenticated catalog for GLM model identifiers, with pricing parsed directly from Z.AI documentation and capability gaps researched there.
Replaces Z.AI entries previously imported from LiteLLM and PricePerToken.
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 and usage counters. Within a pool, the enabled key with the oldest last-used timestamp is picked next; a key leaves the rotation only when you disable it by hand, so a provider error never silently removes a key from service. 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.