models-config.json tells the proxy-router how to translate on-chain modelId values into actual backend HTTP calls. The schema is enforced by proxy-router/internal/config/models-config-schema.json.

Per-model fields

FieldRequiredNotes
modelIdyesThe on-chain model id (32-byte hex)
modelNameyesHuman-readable name
apiTypeyesOne of openai, claudeai, prodia-sd, prodia-sdxl, prodia-v2, hyperbolic-sd, etc.
apiUrlyesFull backend URL including the endpoint path
apiKeyoptionalBackend API key (resale providers usually need this)
concurrentSlotsoptionalDistinct concurrent chats your backend can handle for this model
capacityPolicyoptionalidle_timeout or simple
concurrentSlots is per-model, not global. The proxy-router will accept up to sum(concurrentSlots) across all configured models concurrently. There is no built-in global cap. If your hardware can serve only one of N models at a time, configure all N in models-config.json but only post a bid for the one currently active, and rotate the bid when you want to switch. Prefer bidding on existing marketplace modelIds rather than minting duplicates — see Register on chain. See also Pausing or temporarily disabling a model offering.
| parameters | optional | Per-apiType extra parameters (e.g. SD cfg_scale, steps) | For the canonical per-apiType schema, see the JSON schema file linked above.

Examples

Inline content (for TEE / Akash)

For deployments where mounting a JSON file is impractical, set MODELS_CONFIG_CONTENT to a single-line JSON string with the exact same shape as above. The proxy-router reads it instead of MODELS_CONFIG_PATH. This is the standard approach in TEE and Akash deployments.