The live schema is published at
https://schema.vikat.ai. Add "$schema": "https://schema.vikat.ai" to your config.json for IDE autocomplete and inline validation.config.json. Click the Guide links for full field-by-field documentation.
Top-Level Keys
version
Controls how empty arrays in allow-list fields (models, allowed_models, key_ids, tools_to_execute) are interpreted:
Omitting
version uses v2 semantics. Set "version": 1 only if you are migrating from v1.4.x and need the old behaviour temporarily.
source_of_truth
Controls how config.json is reconciled with the config store at startup.
Missing and empty sections behave differently when
source_of_truth is "config.json". A missing section leaves DB rows untouched; a present empty section is authoritative and can prune matching DB rows.
plugins section present and empty, so stored plugins are removed on startup. See Source of Truth & Reconciliation for section-by-section behavior.
client
Controls the worker pool, logging pipeline, security, and SDK shims. All fields are optional.
Full documentation: Client Configuration.
providers
Keyed by provider name. Each entry contains a keys array and optional network_config, concurrency_and_buffer_size, proxy_config.
Supported provider keys: openai, anthropic, azure, bedrock, vertex, gemini, mistral, groq, cohere, perplexity, xai, cerebras, deepseek, openrouter, nebius, fireworks, parasail, huggingface, replicate, ollama, vllm, sgl, elevenlabs, runway.
Full documentation: Provider Setup.
governance
Seeds governance resources at startup. All sub-keys are optional arrays.
Full documentation: Governance.
guardrails_config
Enterprise-only. Two sub-keys: guardrail_providers (array) and guardrail_rules (array).
Full documentation: Guardrails.
access_profiles
Enterprise-only. Defines access profile templates that can later be attached to roles/users.
cluster_config
Enterprise-only clustering settings for multi-node deployments.
Full documentation: Cluster.
config_store, logs_store, vector_store
Storage backends. Each has enabled (boolean), type (string), and config (object).
Full documentation: Storage.
framework
Controls model pricing catalog sync and the live model-list refresh:
Two intervals, two catalogs
The gateway keeps two separate views of “which models exist”:- Pricing datasheet (
pricing_sync_interval): the static price/capability table fetched frompricing_url. A sync that cannot reach the URL serves the cached database rows or the datasheet bundled in the binary instead; that is logged as such and retried about 15 minutes later rather than after a full interval, so a node whose egress comes back picks up the real datasheet quickly. - Live model lists (
model_list_refresh_interval): a snapshot of each configured provider’s ownGET /v1/models, taken per key at boot and whenever a provider or key is created or updated. This is what the dashboard, bare-model provider resolution and virtual-key “all models” gating read. It is re-fetched in the background everymodel_list_refresh_intervalseconds, so a model a provider starts listing becomes routable within one interval instead of after the next key edit or restart. A provider whose list endpoint fails keeps its previous snapshot (it is never emptied), and each cycle logs one line naming the providers refreshed, failed and skipped and any model ids that appeared. Values below300are clamped to300and values above2592000(30 days) to2592000, each with a warning;0or absent means3600.
PUT /api/config); a change takes effect without a restart.
To refresh on demand:
POST /api/models/refreshre-fetches every provider’s live model list now and returns per-provider counts plus the ids that were new ({"refreshed": 3, "failed": 0, "skipped": 1, "new_models": ["anthropic/claude-opus-5"], "providers": [...]}).POST /api/pricing/force-sync(the Force Sync Now button) syncs the pricing datasheet and then runs the same live model-list refresh.

