Model metadata

​

The sources

1. Pricing overrides — set per model in the dashboard’s Models page. The top layer for pricing fields only; unset price types keep inheriting. See Cost tracking.
2. config.yaml metadata — providers.<name>.models entries can attach metadata (pricing, context_window, modes, capabilities, …). Declared fields win field-by-field over everything below; omitted fields inherit. This is the escape hatch for local models: declaring modes: [embedding] also derives the model’s category.
3. Provider discovery — most providers describe their models in their own listings, and what a provider says about its own deployment wins over the catalog field by field: Anthropic’s display name, token limits and capability flags; Gemini’s display name, description, token limits and thinking support (also on Vertex); Groq’s context window, output limit, modalities, features and prices; xAI’s context window, prices (with the long-context tier) and reasoning support; Fireworks’ model kind, context window and feature flags; OpenRouter’s name, description, modalities, supported parameters and prices; Cohere’s endpoints, context length and features; Bedrock’s display name, modalities and streaming support; Chutes’ context length, max output, features and prices; Ollama’s /api/show capabilities, family and context length; vLLM, SGLang and llm-d’s max_model_len; and llama.cpp’s context window and modalities (see llama.cpp). Capability names are mapped onto the catalog’s vocabulary (function_calling, vision, reasoning, …) so both layers describe one feature under one key. This matters most for self-hosted servers, where the running process is the only source that can know the real context window. Models declared via configured model lists skip this step.
4. The model catalog — the ai-model-list registry, fetched from MODEL_LIST_URL (default: the registry’s models.min.json on GitHub) at startup and on every catalog refresh. It supplies the rich defaults — pricing, context windows, capabilities, modes — for most hosted models, matching IDs directly, through aliases, and with release-date suffixes stripped, and it fills in every field the provider above did not report. Wrong or missing data is best fixed by contributing to the registry; use an override for an immediate fix.
5. ID heuristic — a last-resort name check for models that end up with no modes at all (typical for llama.cpp and LM Studio): IDs containing embed or matching well-known embedding families (bge, e5, gte, minilm) become embedding models, IDs containing rerank become reranking models. Namespaced IDs are matched by their final path segment. When unsure, it claims nothing.

​

Checking where a value came from

​

What metadata affects

• Pricing drives cost tracking, budgets, and cost load-balancing. Each priced field remembers its source, so the dashboard can show where a rate came from.
• Modes and categories drive dashboard grouping only — routing never blocks on them, so /v1/embeddings reaches any model the provider serves.
• Context window and capabilities are advertised on GET /v1/models (and on GET /v1/models/{model} for a single model) for clients that pick models dynamically. The vision capability also drives vision routing; a catalog entry that lists image among its input modalities reports it.

​

Offline behavior

MODEL_LIST_URL=/etc/gomodel/models.json          # bare path
MODEL_LIST_URL=file:///etc/gomodel/models.json   # file URL