providers

Overview ¶

Package providers registers Alibaba Cloud Model Studio (Bailian / DashScope) through its OpenAI-compatible mode.

Facts (https://help.aliyun.com/zh/model-studio/qwen-api-via-openai-chat-completions, https://help.aliyun.com/zh/model-studio/deep-thinking and https://help.aliyun.com/zh/model-studio/base-url):

• the OpenAI-compatible Beijing base URL is https://dashscope.aliyuncs.com/compatible-mode/v1. The Base URL page still lists it and adds region twins (dashscope-intl / dashscope-us / cn-hongkong.dashscope) plus workspace-exclusive hosts ({WorkspaceId}.cn-beijing.maas.aliyuncs.com/compatible-mode/v1) that it recommends for production. The workspace hosts need an id we do not have, so the dashscope host stays the default;
• the same hosts expose an Anthropic Messages facade under /apps/anthropic and the DashScope-native API under /api/v1. This package configures OpenAI Chat Completions, which is what the model pages document first;
• output cap is `max_completion_tokens` ("模型输出的最大长度，包含思维链和 模型回答"). The parameter table marks `max_tokens` 即将废弃 and names this field its successor. `max_tokens` is still accepted today, but following a vendor that has announced a replacement is the cheaper side of the bet: the deprecated field disappears on DashScope's schedule, the successor does not;
• hybrid-thinking models (Qwen3 / Qwen3.x, qwen-plus / -max / -turbo / -flash, DeepSeek V3 / V4, Kimi K2, GLM-5) are switched with `enable_thinking` and budgeted with `thinking_budget` (max token count of the chain of thought; the default is the model's own maximum). Per-model defaults differ, and the docs require the switch to be sent explicitly whenever it deviates from that default, so those families carry thinking_always_send in models.json;
• with `enable_thinking: true` the commercial Qwen models only support streaming ("模型开启思考模式时仅支持增量流式输出"), so the hybrid families also carry thinking_disable_on_non_stream;
• always-on reasoners (仅思考模式): qwq-plus, deepseek-r1 / deepseek-r1-0528, qwen3.8-2.4t-a95b, qwen3.7-max-preview, qwen3.7-max-2026-05-17, qwen3-next-80b-a3b-thinking. Those carry "off": null;
• `reasoning_effort` IS accepted in the compatible mode, but only on some families: qwen3.8 takes low | medium | xhigh (default xhigh; "不支持 reasoning_effort 与 thinking_budget 同时设置，同时设置会报错", which those entries carry as thinking_budget_excludes_effort so the budget yields to the level), DeepSeek-V4 takes high | max (plus low on the dated -0813 / -0731 snapshots), glm-5.3 takes low | high | max. It is therefore off at the vendor level and enabled per entry;
• explicit prompt caching uses Anthropic-style `cache_control` ({"type": "ephemeral"}) and usage reports `prompt_tokens_details.cached_tokens` plus `cache_creation.ephemeral_5m_input_tokens`;
• tool_choice takes the full OpenAI set (none / auto / required / named function), and parallel_tool_calls, response_format (text | json_object | json_schema), stream_options.include_usage, seed, temperature and top_p are all documented, so the protocol defaults stand;
• embeddings are OpenAI-compatible under the same base (/compatible-mode/v1/embeddings); text-embedding-v4 and -v3 default to 1024 dimensions (https://help.aliyun.com/zh/model-studio/embedding);
• rerank is a separate DashScope-native endpoint (/api/v1/services/rerank/text-rerank/text-rerank).

qwen3-rerank is also documented on a second, flat endpoint (/compatible-api/v1/reranks: query / documents at the top level, results with no `output` object), but the native text-rerank endpoint serves it too and returns the same scores (verified against the live API in #3558), so it stays on the native protocol like gte-rerank-v2 and qwen3.7-text-rerank. A dedicated package for the flat shape is only needed if a model ever ships on that endpoint alone (https://help.aliyun.com/zh/model-studio/text-rerank-api).

unverified: no page states whether `prompt_cache_key` is accepted, so the protocol default (not sent) is kept.

unverified: the context windows, max output tokens and prices of the Qwen entries in models.json come from the Model Studio model pages, which the public docs render behind a console table we cannot quote; they are left as they were. The same holds for kimi-k3 / kimi-k2.6 / glm-5.3 hosted here and for qwq-32b's "off": null, which the 仅思考模式 list does not spell out.

Package providers registers Anthropic's native Messages API.

Facts (https://platform.claude.com/docs/en/api/messages — docs.anthropic.com now redirects there):

• authentication is the `x-api-key` header plus `anthropic-version`, still 2023-06-01 in every current example;
• `max_tokens` is mandatory (the protocol default of 4096 applies when the caller sets no budget);
• `output_config.effort` takes low | medium | high | xhigh | max and nothing else — there is no "minimal" rung, so the vendor level map folds minimal onto low (https://platform.claude.com/docs/en/build-with-claude/effort). `max` is listed for Fable 5.1 / Fable 5 / Opus 5 / Opus 4.8 / Opus 4.7 / Opus 4.6 / Sonnet 5 / Sonnet 4.6; `xhigh` for the same set minus Opus 4.6 and Sonnet 4.6, which is why those two map xhigh onto max;
• Claude 4.7 and later reject `thinking: {"type": "enabled"}` with a 400 and must use `{"type": "adaptive"}`; it is deprecated but still accepted on the 4.6 generation, and it is the only mode on 4.5 and earlier (https://platform.claude.com/docs/en/build-with-claude/thinking-troubleshooting#supported-models);
• only Fable 5.1 / Fable 5 (and the limited-availability Mythos models) are "always on" and reject `thinking: {"type": "disabled"}`, so only those entries carry "off": null. Opus 5, Opus 4.8 and Opus 4.7 accept "disabled" (Opus 5 at effort high or below, which is what a caller asking for "off" gets because effort and off are mutually exclusive here);
• Claude Opus 4.5 is the one extended-thinking-only model that also accepts `output_config.effort`, so it carries supports_effort with budget mode;
• temperature and top_p cannot be sent alongside thinking, and Claude Opus 4.7 and later (Opus 4.8, Opus 5, Fable 5 / 5.1) and Sonnet 5 reject non-default sampling values, so those entries carry supports_temperature: false and supports_top_p: false and send no sampling field at all (https://platform.claude.com/docs/en/docs/about-claude/model-deprecations); prompt caching uses `cache_control` breakpoints (including on tools), offers a 1h TTL and reports cache usage;
• interleaved thinking still uses the `interleaved-thinking-2025-05-14` beta header, and only in manual budget mode: adaptive models interleave on their own and the Claude API ignores the header there.

Unverified: Claude Mythos 5.1 / Mythos 5 / Mythos Preview are documented but limited-availability, so they are left out of the catalog.

Package providers registers Azure OpenAI (Azure AI Foundry).

Facts (https://learn.microsoft.com/azure/ai-foundry/openai/api-version-lifecycle and https://learn.microsoft.com/azure/ai-foundry/openai/how-to/reasoning):

• there are two request shapes. The v1 shape, https://{resource}.openai.azure.com/openai/v1/chat/completions with the deployment name in the body's `model` field, is the current GA data plane and takes no api-version at all: "api-version is no longer a required parameter with the v1 GA API". Every example on the reasoning how-to page (last updated 2026-09-16) uses it. The legacy shape, .../openai/deployments/{deployment}/chat/completions?api-version=..., is still served but its newest GA api-version is 2024-10-21, which predates `max_completion_tokens` (2024-09-01-preview) and `reasoning_effort` (2024-12-01-preview) — so a reasoning deployment cannot work on it. The Endpoint hook therefore emits the v1 shape by default and only falls back to the legacy shape when the operator explicitly fills the api_version extra field;
• authentication is the `api-key` header, not a bearer token (Entra AzureOpenaiID bearer tokens are the other documented option and are not modelled);
• the model name stored on the row is the deployment name, so the catalog only carries family patterns (gpt-6*, gpt-5*, o1*, o3*, o4*, ...) that mirror the OpenAI vendor: reasoning deployments use `max_completion_tokens`, `reasoning_effort`, the developer role, and reject temperature, top_p, presence_penalty, frequency_penalty, logprobs, top_logprobs, logit_bias and max_tokens;
• `reasoning_effort` accepts none | minimal | low | medium | high | xhigh | max, model-dependent; `xhigh` is limited to GPT-6, GPT-5.6, GPT-5.5, GPT-5.4 and gpt-5.1-codex-max, `max` to GPT-6 and GPT-5.6 on the Responses API only, and `minimal` to the original GPT-5 models. Because a deployment name says nothing about which model backs it, the family patterns stay on the conservative subset. The exception is a deployment named exactly gpt-5, gpt-5-mini or gpt-5-nano, which is overwhelmingly the model of that name: those three carry their own entries mirroring the openai vendor, because the original GPT-5 trio supports "Reasoning.effort ... minimal, low, medium, and high" (https://developers.openai.com/api/docs/models/gpt-5) and rejects `none`, unlike GPT-5.1 and later, which the gpt-5* pattern covers;
• `store: false`, `prompt_cache_key` and cached-token usage behave as on api.openai.com.

The one path rule ¶

A stored row picks its data plane from `extra_config.api_version` alone, and chat, VLM and embedding all apply the same rule to the same row:

api_version empty     -> {base}/openai/v1{path}, no api-version, the
                         deployment name travelling in the body's
                         `model` field;
api_version non-empty -> {base}/openai/deployments/{deployment}{path}
                         ?api-version={value}.

Chat and VLM reach this through the Endpoint hook below (VLM is built on the chat client); embedding applies it in azureEmbeddingURL in internal/models/embedding/azure_openai.go, which calls this same hook.

The v1 default is not a guess. The v1 API reference is published at "API Version: v1" with server {endpoint}/openai/v1 and covers the paths this vendor uses, embeddings included (https://learn.microsoft.com/rest/api/microsoft-foundry/azureopenai/embeddings: "POST {endpoint}/openai/v1/embeddings", with `api-version` marked "Required: No" and defaulting to v1). The lifecycle page's prerequisites for the v1 API are only a subscription, a Foundry or Azure OpenAI resource in a supported region, and at least one model deployment — there is no resource-level switch to flip, and `base_url` is documented to accept the https://{resource}.openai.azure.com/openai/v1/ form. The dated path is not a parallel modern option: 2024-10-21 is still the newest GA api-version there, so the reasoning surface this vendor advertises (`max_completion_tokens`, 2024-09-01-preview; `reasoning_effort`, 2024-12-01-preview) exists on no GA dated version at all.

Behaviour change for existing rows: before the catalog, a row with no api_version used the dated deployments path (the Go SDK's built-in Azure default for chat and VLM, a hard-coded 2024-10-21 for embedding). Those rows now use /openai/v1. This is deliberate and documented in website-docs/03-features/06-models.md; an operator whose gateway only serves the dated path (an API Management front end, a sovereign cloud) restores the exact previous shape by filling the api_version extra field.

Package providers registers Cohere's hosted text rerank API. https://docs.cohere.com/v2/reference/rerank

Package providers registers DeepSeek's first-party API.

Facts (https://api-docs.deepseek.com/api/create-chat-completion and https://api-docs.deepseek.com/guides/thinking_mode):

• output cap is `max_tokens`, "between 1 and 384K (393216)"; the default is 8K without thinking, 64K with it, 128K at `reasoning_effort: max`. `max_completion_tokens` is not part of the reference;
• thinking is switched with `thinking: {"type": "enabled"|"disabled"}` (the documented default is `enabled`) and graded with `reasoning_effort`, whose values are none | low | high | max. `none` is the effort spelling of "off"; on this OpenAI surface the protocol switches thinking off with `thinking.type = disabled` instead, which is what the reference documents;
• temperature (0..2) "has no effect in thinking mode" but is still accepted, so sampling parameters keep being sent; `top_p` only takes effect in thinking mode, where values below 0.95 are treated as 0.95; presence_penalty / frequency_penalty are "no longer supported" and are silently dropped by the vendor;
• tool_choice lists none / auto / required / a named function, but the reference adds that "required and named tool choices are not supported in thinking mode; the API returns a 400 error". Thinking is the documented default, and the compat model cannot make the restriction conditional on it, so only none / auto are ever sent;
• assistant turns must replay `reasoning_content` when the request carries `tools`; without `tools` the vendor ignores it;
• usage reports `prompt_cache_hit_tokens` / `prompt_cache_miss_tokens` next to `prompt_tokens_details.cached_tokens`;
• DeepSeek also serves an Anthropic Messages surface at https://api.deepseek.com/anthropic and a Responses surface on the same host (https://api-docs.deepseek.com/guides/anthropic_api and .../guides/responses_api). The documented default, and what this package configures, is OpenAI Chat Completions.

unverified: the current docs give the base URL as https://api.deepseek.com with no version segment; the /v1 alias this package uses (and that provider.DeepSeekBaseURL and stored model rows carry) is no longer spelled out in them, and nothing documents it being rejected, so it is kept.

Prices in models.json are the USD off-peak rates of https://api-docs.deepseek.com/quick_start/pricing (peak is exactly 2x); `cost.input` is the cache-miss rate and `cost.cache_read` the cache-hit one.

unverified: `parallel_tool_calls`, `prompt_cache_key` and `stream_options.include_usage` semantics beyond the field itself are not described in the reference; the protocol defaults are kept.

unverified: deepseek-v4-pro carries a per-model override that lifts minimal / low to `high`. The reference enumerates low / high / max for the API as a whole without restricting them per model, so the override is kept but nothing documents it.

Package providers defines vendor defaults and routing rules independently of the model catalog.

Package providers registers Google's Gemini API.

Facts (https://ai.google.dev/gemini-api/docs/thinking):

• the native protocol is generateContent under https://generativelanguage.googleapis.com/v1beta with the `x-goog-api-key` header;
• the two thinking knobs are generation-specific and mutually exclusive: Gemini 3.x takes `thinkingConfig.thinkingLevel`, Gemini 2.5 takes `thinkingConfig.thinkingBudget` and ignores/rejects thinkingLevel; sending both in one call is a 400. The per-model level sets differ too — 3.8 Flash, 3.7 Flash and 3.1 Pro accept low | medium | high, 3.6 Flash, 3.5 Flash, 3.5 Flash Lite, 3.1 Flash Lite and 3 Flash Preview add minimal, and 3 Pro Preview accepts only low | high, which is what the conservative gemini-3* family entry assumes;
• no thinkingLevel value turns thinking off, so every Gemini 3 entry is "off": null. On 2.5, Pro is the exception that cannot be switched off (its budget must be 128..32768, or -1 for dynamic) while Flash and Flash Lite accept budget 0; the vendor budget ladder starts at 128 for that reason and tops out at 32768;
• pointing base_url at https://generativelanguage.googleapis.com/v1beta/openai keeps the OpenAI-compatible Chat Completions protocol (Resolve detects the /openai suffix) and switches the credential to `Authorization: Bearer`, the only form that facade documents (https://ai.google.dev/gemini-api/docs/openai). Every row created before the native protocol became the default carries exactly that base URL, so this is the auth those rows have always used; on that facade `reasoning_effort` is translated to thinking_level or thinking_budget per model, `extra_body.google.thinking_config` carries include_thoughts, and usage reports cached tokens (the OpenAICompletions vendor compat below);
• embeddings are served natively and on the facade: gemini-embedding-001 defaults to 3072 dimensions over 2048 input tokens, gemini-embedding-2 to 3072 over 8192 and accepts multimodal input (https://ai.google.dev/gemini-api/docs/embeddings).

Unverified:

• `extra_content` on tool calls is not named anywhere in the current OpenAI-compat guide; the tool_call_extra_fields entry is kept because dropping an opaque round-trip field is the riskier direction.
• gemini-embedding-2 is listed as `gemini-embedding-2` in the embeddings guide but as `gemini-embedding-2-preview` on the models page and in the OpenAI-compat samples, so both spellings resolve to one entry.
• gemini-3.1-flash-lite is on the models page but absent from the thinking guide's level table, so its minimal rung is an assumption carried over from the other Flash Lite tiers.

Package providers registers the catch-all vendor for any OpenAI-compatible endpoint (vLLM, SGLang, Xinference, Ollama's OpenAI facade, ...).

Facts (no single upstream; the settings follow the vLLM / SGLang conventions, https://docs.vllm.ai/en/latest/features/reasoning_outputs.html and https://docs.sglang.io/basic_usage/openai_api_completions.html):

• output cap stays `max_tokens`. vLLM now marks it deprecated in favour of `max_completion_tokens` but still accepts it, while SGLang, GPUStack and Xinference document only `max_tokens`, so it remains the one field every runtime behind this vendor understands;
• thinking is switched through `chat_template_kwargs.enable_thinking`, which both servers document as the per-request override. vLLM also accepts a top-level `reasoning_effort` with exactly this project's ladder (none | minimal | low | medium | high | xhigh | max) and injects enable_thinking from it, but SGLang only says effort "follows a separate normalization path", so the chat-template switch is the portable choice and operators on vLLM can opt into effort per model;
• the gpt-5*/o1*/o3*/o4* family entries stay: a relay parked behind this vendor is the common way to front OpenAI, and those families need max_completion_tokens, reasoning_effort and no sampling parameters whatever the hop count;
• no default base URL: the operator must supply one (Validate enforces it) and a key is optional because local deployments run without one;
• no URL patterns: DetectByURL falls back to this vendor when nothing else matches.

Unverified: `enable_thinking` is not a portable key. vLLM documents `{"thinking": true}` for IBM Granite and SGLang documents the same for DeepSeek-V3, so a non-Qwen template will ignore the switch this vendor sends rather than reject it. Per-model chat-template keys are not expressible in the compat model.

Package providers registers a self-hosted GPUStack cluster (https://github.com/gpustack/gpustack).

Facts (https://docs.gpustack.ai/latest/integrations/inference-apis/):

• the OpenAI-compatible surface is mounted at /v1: "GPUStack serves OpenAI-compatible APIs using the `/v1` path." The 0.x/1.x line served them at /v1-openai and documented /v1 as an alias for everything but the models endpoint, so /v1 is the one path that works on both lines; the 2.x page no longer mentions /v1-openai at all. Rerank is served at /v1/rerank as well — "the OpenAI-compatible APIs does not provide a `rerank` API, so GPUStack serves Jina compatible Rerank API using the `/v1/rerank` path" — so chat, embeddings, transcriptions and rerank now share one base URL;
• authentication is `Authorization: Bearer <api key>`;
• output cap is `max_tokens`: every GPUStack example uses it and `max_completion_tokens` is never mentioned, so acceptance of the newer field is the backend's business, not the gateway's;
• built-in backends are vLLM, SGLang, Ascend MindIE and VoxBox (llama-box was dropped from the 2.x built-in list), so thinking is switched with `chat_template_kwargs.enable_thinking`;
• the default base URL is a placeholder the operator must replace (Validate requires it); the hostname contains "gpustack" so DetectByURL recognises catalog rows;
• the catalog ships no models: deployments name their own.

Unverified: whether GPUStack 2.x still answers on the old /v1-openai path. The 2.x docs neither document it nor announce its removal, which is why the default moved to /v1 rather than keeping a path only one line documents.

Package providers includes Hugging Face Text Embeddings Inference, which serves a model chosen at startup. Its native rerank route is POST /rerank with query/texts and a bare array response; it does not accept a model field or use the OpenAI /v1 prefix. https://huggingface.co/docs/text-embeddings-inference/quick_tour#re-rankers https://github.com/huggingface/text-embeddings-inference/blob/main/docs/openapi.json

Package providers registers Tencent Hunyuan through its OpenAI-compatible endpoint.

Facts (https://cloud.tencent.com/document/product/1729/111007):

• https://api.hunyuan.cloud.tencent.com/v1 serves both chat (/chat/completions) and embeddings (/embeddings); the only credential is a console API key sent as Authorization: Bearer, so this vendor needs no ExtraFields (the TC3-signed native API is a different host);
• the output cap is `max_tokens` (default 4096); the reference does not document `max_completion_tokens`;
• `tool_choice` 可选值包括 none、auto、custom and "仅对 hunyuan-turbos、 hunyuan-functioncall 模型生效", so `required` is never sent; "custom" is a Hunyuan-specific shape rather than OpenAI's named-function object, so the "function" mode is withheld as well;
• temperature is [0.0, 2.0] and top_p [0.0, 1.0], neither restricted;
• stream_options.include_usage is supported;
• hunyuan-embedding returns a fixed 1024-dimension vector.

Thinking (https://cloud.tencent.com/document/product/1729/105701): the native API exposes `EnableThinking`, "未传值时默认开启" and the switch "仅对 hunyuan-a13b 模型生效". The T1 series reasons unconditionally, so models.json marks it "off": null, and hunyuan-a13b additionally accepts a `/no_think` prompt prefix (https://cloud.tencent.com/document/product/1729/104753).

Second protocol: an Anthropic Messages facade at https://api.hunyuan.cloud.tencent.com/anthropic (path /anthropic/v1/messages) documents hunyuan-2.0-thinking-20251109 and hunyuan-2.0-instruct-20251111 with thinking {type, budget_tokens} (https://cloud.tencent.com/document/product/1729/127293). The OpenAI-compatible surface stays this vendor's default.

unverified: the OpenAI-compatible reference documents no thinking field at all, so the snake_case `enable_thinking` spelling used here is carried over from the native API and is unconfirmed for this endpoint; unverified: response_format, parallel_tool_calls and prompt-cache accounting are absent from the compatible-interface reference, so the protocol defaults (supported, no cache counters) stand untested; unverified: Tencent's model list (1729/104753) and pricing page (1729/97731) document limits for hunyuan-a13b (224k in / 32k out) and the vision models only. hunyuan-t1-latest, hunyuan-turbos-latest, hunyuan-lite and hunyuan-turbos-vision appear in neither table (new models are migrating to TokenHub), so their context windows, output caps and prices are carried over unconfirmed; no retirement notice was found either, so the entries stay. hunyuan-t1-latest used to claim a 64K output cap above its own 32K context window; since no doc supports either number, the cap was dropped rather than corrected, leaving the context window as the only (still unconfirmed) limit. Treat it as a placeholder that the per-model field in the UI overrides, and do not raise it without a documented source: an overstated context window stops history compaction from firing and the upstream rejects the request instead; unverified: the hunyuan-2.0-* ids are documented only on the Anthropic facade, so their availability on this OpenAI-compatible host, their context windows and their output caps are unconfirmed.

Package providers registers Jina AI's embedding and rerank APIs.

Facts (https://jina.ai/embeddings and https://jina.ai/reranker):

• both endpoints live under https://api.jina.ai/v1 and authenticate with `Authorization: Bearer`;
• /v1/embeddings matches the input and output JSON schema of OpenAI's text-embedding-3-large (it is a superset: `task`, `normalized`, `embedding_type` and `dimensions` are Jina-only additions); /v1/rerank takes the Cohere-style {model, query, documents, top_n} body;
• the v5 generation is a family of four rather than one id: omni (multimodal) and text, each in small (1024 dims, 32K tokens) and nano (768 dims, 8K tokens). jina-embeddings-v4 still defaults to 2048 dimensions over 32K tokens and v3 to 1024 over 8K; v4 supports Matryoshka truncation down to 128 through `dimensions`;
• jina-reranker-v3.5 and v3 take 131K tokens and are the current recommendations; m0 (10K) and v2-base-multilingual (1K) remain listed;
• there is no chat model, so ModelTypes lists embedding and rerank only.

Unverified: api.jina.ai does not serve a fetchable OpenAPI document, so the OpenAI-schema compatibility claim rests on the wording of the embeddings FAQ rather than a spec.

Package providers registers a self-hosted LiteLLM proxy (https://github.com/BerriAI/litellm).

Facts (https://docs.litellm.ai/docs/reasoning_content):

• the proxy speaks plain OpenAI Chat Completions and translates `reasoning_effort` for every upstream it fronts, so the OpenAI thinking format is used and graded effort is supported. The documented vocabulary is minimal | low | medium | high | xhigh | max (mapped onto Anthropic budgets of 1024/1024/2048/4096/8192/16384), plus `none` to turn thinking off — which is why the vendor level map spells "off" as "none" and keeps xhigh and max enabled;
• both `max_tokens` and `max_completion_tokens` are listed as supported input params (https://docs.litellm.ai/docs/completion/input) with no stated preference, so the protocol default max_completion_tokens stands;
• the default base URL is a placeholder the operator must replace; its hostname contains "litellm" so DetectByURL recognises catalog rows, while loopback URLs stay generic (they are SSRF-blocked unless whitelisted). The proxy's own default is port 4000, and both /v1/chat/completions and /chat/completions are documented;
• the catalog ships no models: deployments name their own routes.

Unverified: `chat_template_kwargs` is not named in the LiteLLM docs. It should reach a vLLM/SGLang upstream under the general rule that "LiteLLM treats any non-openai param as a provider-specific param, and passes it to the provider in the request body", but a proxy configured with allowed_openai_params may drop it, so operators fronting open-weight models may need thinking_control=chat_template_kwargs plus that allowlist.

Package providers registers Tencent Cloud LKEAP (Knowledge Engine Atomic Power) through its OpenAI-compatible endpoint.

Chat facts (https://cloud.tencent.com/document/product/1772/115969 and the model list at https://cloud.tencent.com/document/product/1772/115963):

• the documented endpoint is https://api.lkeap.cloud.tencent.com/v1/chat/completions, so the base URL already carries the /v1 segment;
• authentication is a plain `Authorization: Bearer sk-...` console key, unrelated to the Tencent Cloud SecretId / SecretKey pair;
• output cap is `max_tokens`; temperature (default 0.6, range [0, 2]) and top_p (default 0.6, range (0, 1]) are both accepted, as are stop, presence_penalty, frequency_penalty, Function Calling and response_format json_object (json_schema on V3.1+);
• thinking is switched with `thinking: {"type": "enabled"|"disabled"}`, documented as taking effect only on deepseek-v3.1-terminus and deepseek-v3.2; DeepSeek R1 reasons unconditionally, so the R1 entries carry "off": null and never receive a disable switch;
• `reasoning_effort` is not part of the LKEAP surface, so effort grading stays off and only the thinking switch is sent.

Rerank facts (https://cloud.tencent.com/document/product/1772/115339):

• it is not the OpenAI-compatible host but the Tencent Cloud API lkeap.tencentcloudapi.com, action RunRerank, version 2024-05-22, available in ap-beijing and ap-guangzhou only;
• it therefore needs the TC3-HMAC-SHA256 credential pair: the API key field carries the SecretId and the rerank-only extra fields carry the SecretKey and the region (default ap-guangzhou). The SecretKey is genuinely required — TC3 signing cannot be done without it;
• the optional Model parameter defaults to lke-reranker-base, which is documented as the only available rerank model.

unverified: the current model list documents deepseek-v3-0324, deepseek-r1-0528, deepseek-v3.1-terminus and deepseek-v3.2. The plain deepseek-r1 / deepseek-v3 / deepseek-v3.1 ids kept in models.json are no longer listed, but no LKEAP retirement notice covers them, so they stay with their previously recorded limits.

unverified: LKEAP documents neither tool_choice modes, stream_options.include_usage nor any prompt-cache accounting, so the protocol defaults are kept.

Package providers registers Meituan LongCat's OpenAI-compatible endpoint.

Facts (chat reference https://longcat.chat/platform/docs/zh/api/chat.html, overview https://longcat.chat/platform/docs/zh/APIDocs.html):

• the OpenAI facade is served at POST https://api.longcat.chat/openai/v1/chat/completions, so the base URL carries the /openai/v1 prefix;
• auth is `Authorization: Bearer <API Key>` and nothing else;
• output cap is `max_tokens`, which defaults to and tops out at the model's 128K (131072) output budget; `max_completion_tokens` is not part of the reference;
• thinking IS switchable, with `thinking: {"type": "enabled"}` or `{"type": "disabled"}`, and it is enabled by default. No `reasoning_effort` is documented, so the switch is sent without a grade;
• the model replies with `reasoning_content` and reports `completion_tokens_details.reasoning_tokens`, which the protocol already reads by default;
• `messages` is text only (roles system / user / assistant), which is why every entry lists the text modality alone;
• temperature is documented over 0..1 rather than the OpenAI 0..2, and top_p is accepted. The protocol has no field for a narrower range, so values are passed through unchanged;
• LongCat also serves an Anthropic Messages surface at https://api.longcat.chat/anthropic/v1/messages (https://longcat.chat/platform/docs/zh/api/messages.html) with the same model and the same thinking shape. The documented default, and what this package configures, is the OpenAI format.

unverified: the changelog credits LongCat-2.0 with "native tool calling", but neither API reference documents `tools`, `tool_choice`, `parallel_tool_calls` or a `tool` message role, so the protocol defaults (the full OpenAI tool_choice set) are kept untested.

unverified: `response_format` and `stream_options.include_usage` do not appear in the reference either; the protocol defaults are kept.

unverified: nothing documents a mandatory thinking switch or a non-stream restriction, so thinking_always_send and thinking_disable_on_non_stream stay off.

unverified: the published usage object carries no cache counters even though the price list bills cached input, so prompt_cache_accounting stays off; neither prompt_cache_key nor cache_control is documented.

Package providers registers Xiaomi MiMo's OpenAI-compatible endpoint.

Facts (https://mimo.mi.com/static/docs/api/chat/openai-api.md, https://mimo.mi.com/static/docs/quick-start/summary/model.md, https://mimo.mi.com/static/docs/api/guidance/model-hyperparameters.md):

• the OpenAI-compatible base URL is https://api.xiaomimimo.com/v1 and auth is `Authorization: Bearer sk-...`; an Anthropic Messages endpoint lives at https://api.xiaomimimo.com/anthropic and is not selected here;
• the output cap is `max_completion_tokens` (the protocol default); `max_tokens` is not a documented parameter;
• thinking is switched with `thinking: {"type": "enabled"|"disabled"}`, enabled by default on both chat models; there is no reasoning_effort and no thinking budget;
• prior assistant turns must replay `reasoning_content` whenever the turn carried tool_calls, otherwise the API answers 400 (the default);
• temperature ([0, 1.5], default 1.0) and top_p ([0.01, 1.0], default 0.95) are accepted, but while thinking is on the service silently pins them to 1.0 / 0.95 instead of erroring, so they stay enabled;
• `tool_choice` only offers `auto`: any other value is dropped server side and the request behaves as auto;
• usage reports `prompt_tokens_details.cached_tokens` (cache writes are free for now), so cache accounting is on;
• mimo-v2-flash — together with mimo-v2-pro, mimo-v2-omni and mimo-v2-tts — was retired on 2026-06-30 and is kept only as a deprecated entry (https://mimo.mi.com/static/docs/updates/deprecate.md).

Unverified: `stream_options.include_usage` is absent from the documented request schema, but the streaming chunks document a `usage` object, so the protocol default (send it) is kept rather than guessed away; parallel_tool_calls and seed are likewise absent from the documented schema without being documented as rejected; mimo-v2.5-pro-ultraspeed is a closed beta that neither the model list nor the price list carries, so its id, limits and prices are unconfirmed; the ASR (mimo-v2.5-asr) and TTS models are documented but not registered here, since this vendor only declares the chat model type.

Package providers registers MiniMax's OpenAI-compatible chat endpoint.

Facts (https://platform.minimax.io/docs/api-reference/text-openai-api):

• both `max_tokens` (legacy) and `max_completion_tokens` are accepted, and the reference recommends the latter for new integrations, so the protocol default is kept;
• thinking is `thinking: {"type": "adaptive"|"disabled"}` (hence thinking_enabled_value "adaptive"). On this OpenAI surface thinking is ON when the field is omitted, so the switch is only sent when the caller asks for one; the M2 generation accepts the field but cannot actually turn thinking off, and models.json marks it "off": null;
• prompt caching is automatic and usage reports `prompt_tokens_details.cached_tokens`, hence prompt_cache_accounting (https://platform.minimax.io/docs/api-reference/text-prompt-caching);
• the only credential is a bearer API key: the GroupId that the legacy /v1/text/chatcompletion_v2 endpoint required is not used here, so this vendor needs no ExtraFields;
• the mainland endpoint is https://api.minimax.cn/v1 and the global one https://api.minimax.io/v1; keys are region-bound (mainland keys to minimax.cn, global keys to minimax.io). Mainland endpoint reference: https://platform.minimax.cn/docs/api-reference/text-openai-api.

Second protocol: an Anthropic Messages facade lives at https://api.minimax.io/anthropic (mainland form in MinimaxAnthropicBaseURL), and the vendor presents it first for thinking and tool workflows, documented at https://platform.minimax.io/docs/api-reference/text-anthropic-api. Resolve switches protocol when the base URL ends with /anthropic; this package still defaults to the OpenAI-compatible surface, which is the one documented for both regions.

unverified: the sampling ranges are contradictory. The OpenAI-surface reference gives temperature [0, 2] and top_p [0, 1], but MiniMax rejects temperature=0 and top_p=0 in practice with error 2013 ("invalid params, param 'top_p' should be in (0,1]"), i.e. the real range is (0, 1]. The catalog can only express "no sampling" or "one fixed temperature", not an exclusive lower bound, so nothing is configured and zero values still reach the vendor; unverified: `tool_choice`, `parallel_tool_calls`, `response_format` and `prompt_cache_key` are not described on the OpenAI surface, so the protocol defaults stand untested; unverified: max output caps. The model table publishes context windows but no per-model output cap, so the max_output_tokens in models.json are carried over unconfirmed; The mainland Anthropic facade is documented at https://platform.minimax.cn/docs/api-reference/text-anthropic-api.

Package providers registers ModelScope's API-Inference service.

Facts (https://modelscope.cn/docs/model-service/API-Inference/intro, https://modelscope.cn/docs/model-service/API-Inference/limits):

• the OpenAI-compatible base URL is https://api-inference.modelscope.cn/v1 and auth is `Authorization: Bearer <ModelScope Access Token>` (the account must be bound to a verified Aliyun account);
• the same host also serves an OpenAI Responses endpoint on /v1 (Qwen3.5 family only) and a beta Anthropic Messages endpoint on the bare host (https://api-inference.modelscope.cn/anthropic/v1/messages); this vendor only selects Chat Completions;
• model ids are ModelScope repo ids ("Owner/Model-Name"); which of them API-Inference serves changes over time — the docs state outright that older models are taken offline as newer ones land, and only the model page (the API-Inference panel) is authoritative;
• API-Inference is a free, non-commercial service with dynamic rate limits and no per-token price: calls are metered in 魔粒 credits (0.5 / 1 / 2 per call by model tier), which is why the entries below carry a zero token cost rather than a real one;
• the documented scope is open LLM, multimodal (MLLM) and AIGC text-to-image models.

Unverified: the thinking switch — ModelScope documents no thinking parameter, so the top-level `enable_thinking` of the DashScope/Bailian channel behind API-Inference is kept as a guess, as is `max_tokens` for the output cap; embedding support is not documented anywhere on the API-Inference pages, so the Embedding model type and the two Qwen3-Embedding entries are unconfirmed; every model id, context window, max output and thinking flag below predates the current lineup, and as of 2026-09-20 none of them advertises a "ModelScope" provider on https://modelscope.cn/api/v1/inference/list_model_providers (models that are served, such as Qwen/Qwen3.5-35B-A3B or ZhipuAI/GLM-5.2, do) — they are kept because no official page states their retirement, but the list needs a refresh against the model pages.

Package providers registers Moonshot AI (Kimi).

Facts (https://platform.kimi.com/docs/api/overview, https://platform.kimi.com/docs/api/chat, https://platform.kimi.com/docs/api/models-overview):

• the mainland base URL is https://api.moonshot.cn/v1 and the global one https://api.moonshot.ai/v1 (the default here); both are recognised by URL pattern. The same hosts also expose an OpenAI Responses endpoint on /v1 and an Anthropic Messages endpoint on /anthropic, neither of which this vendor selects;
• auth is `Authorization: Bearer <key>`;
• the output cap is `max_completion_tokens` (the protocol default); `max_tokens` is still accepted but documented as deprecated;
• kimi-k2.6 and the kimi-k2.7-code pair switch thinking with `thinking: {"type": "enabled"|"disabled"}`; k2.7-code cannot turn it off (Preserved Thinking is always on), k2.6 can;
• kimi-k3 takes no `thinking` object at all: it always reasons and is only graded through the top-level `reasoning_effort` (low | high | max, default max), so that entry overrides the thinking format to openai;
• every current model refuses sampling parameters (temperature is pinned to 1.0 on k3 / k2.7-code and to 1.0 thinking / 0.6 non-thinking on k2.6, top_p to 0.95, n to 1, both penalties to 0), so none are sent;
• tool_choice accepts none / auto on every model and required only on kimi-k3; a named function is never sent because it answers 400 while thinking is enabled;
• response_format (text / json_object / json_schema) and `stream_options: {"include_usage": true}` are supported;
• context caching is automatic and usage reports `prompt_tokens_details.cached_tokens` / `cache_write_tokens`; Anthropic-style breakpoints (`prompt_cache_breakpoint`) are rejected;
• moonshot-v1* (incl. the vision previews), kimi-k2.5, kimi-k2-turbo-preview and kimi-k2-thinking were retired on 2026-08-31, the older kimi-k2* snapshots on 2026-05-25; they stay as deprecated entries so stored model rows still resolve (https://platform.kimi.com/docs/models).

Unverified: `prompt_cache_key` / `prompt_cache_options` are documented but left off, because the protocol layer pairs prompt_cache_key with OpenAI's `prompt_cache_retention`, which Moonshot does not document (it uses prompt_cache_options.ttl with 5m / 1h); parallel_tool_calls and seed are absent from the documented request schema yet not documented as rejected, so the protocol defaults are kept; the 262144 max output tokens of the K2.x entries is not a documented cap (the docs only give a 32768 default); the per-token costs are USD conversions of the CNY price list.

Package providers registers the Novita AI gateway.

Facts (https://docs.novita.ai — novita.ai/docs/* redirects there):

• chat, embedding, VLM and rerank share https://api.novita.ai/openai/v1; /v1/completions, /v1/batches and /v1/files sit alongside;
• rerank is the Cohere shape — {model, query, documents, top_n} answering results[].{index, relevance_score, document.text} — so it needs no vendor settings beyond the type being open (https://docs.novita.ai/api-reference/model-apis-llm-create-rerank). No ceiling on the document count is documented, and the reference lists no model ids, so none are shipped: the operator names the model;
• output cap is `max_tokens`, documented as required; `max_completion_tokens` is never mentioned;
• the thinking switch is a **top-level** `enable_thinking` boolean (default true) — "Controls the switches between thinking and non-thinking modes" — not `chat_template_kwargs.enable_thinking` and not `reasoning_effort`, neither of which appears anywhere in the docs. There is no graded effort, so supports_reasoning_effort stays off and models that cannot stop reasoning are marked "off": null.

Unverified:

• the documented enable_thinking support list still names glm-4.5 and deepseek-v3.1/v3.2-exp, so whether the current flagships (glm-5.x, deepseek-v4-*, kimi-k3, minimax-m2.7) honour it is not stated. The switch is only sent when a caller asks for one, so a model that ignores it degrades to its own default rather than failing;
• the three embedding entries are served by the API but the embeddings reference restricts `model` to a single enum value (baai/bge-m3), and they are absent from the default /v1/models listing.

Package providers registers NVIDIA NIM's hosted API (build.nvidia.com).

Facts (https://docs.api.nvidia.com/nim/ and the per-model cards on https://build.nvidia.com):

• chat, embedding and VLM share https://integrate.api.nvidia.com/v1 with `Authorization: Bearer`; rerank is a separate host, https://ai.api.nvidia.com/v1/retrieval/nvidia/reranking, whose body is {query, passages, model, truncate} with at most 512 passages. Current rerank NIMs also expose a per-model path (.../retrieval/nvidia/<slug>/reranking); the shared path stays live and is what legacy rerank models answer on;
• the output cap field is mixed per model. NVIDIA's own curl and Python samples use `max_tokens`, so that is the vendor default, but the cards for kimi-k3 and gemma-4-31b-it show `max_completion_tokens`; those entries override it. The LLM API reference defers to the vLLM OpenAI-server schema rather than pinning either field;
• thinking has no single encoding on NIM. Nemotron 3 takes `chat_template_kwargs: {"enable_thinking": bool}` (the vendor default here), DeepSeek V4 takes `chat_template_kwargs: {"thinking": bool, "reasoning_effort": ...}`, GLM-5.3 takes a top-level `reasoning_effort` defaulting to max, MiniMax M3 takes `thinking_mode`, and Gemma 4 switches thinking with a `<|think|>` token in the system prompt rather than any parameter — which is why the gemma entry sets thinking_format "none" instead of pretending a switch exists. The entries that grade with a top-level `reasoning_effort` carry thinking_format "openai"; without it the vendor default would emit a chat-template switch and drop the level, leaving the picker's rungs inert;
• most hosted endpoints are metered at zero cost; the Nemotron and DeepSeek endpoints are priced;
• nemotron-3-embed-1b is the one embedding endpoint here that build.nvidia.com does not mark deprecated: nv-embed-v1, llama-3_2-nemoretriever-300m-embed-v1 (and its v2) and baai/bge-m3 all carry "This NIM Endpoint has been deprecated", so their entries were removed. Its reference caps input at 4096 tokens; the 2048-wide vector is from the Nemotron-3-Embed-1B model card on Hugging Face.

Unverified:

• `minimaxai/minimax-m3`, `minimaxai/minimax-m2.7` and `mistralai/mistral-medium-3.5-128b` have live build.nvidia.com pages whose samples ship an empty `model=""`, so the exact org-prefixed id could not be confirmed; they are left out rather than guessed;
• `nvidia/rerank-qa-mistral-4b` (the previous entry here) has no per-model rerank route and one source reports a 2026-08-24 deprecation, so it was replaced with nv-rerankqa-mistral-4b-v3 and the current llama-nemotron-rerank-vl-1b-v2;
• DeepSeek on NIM wants `reasoning_effort` nested inside chat_template_kwargs, which this compat model cannot express: it emits either a chat-template switch or a top-level effort, never both;
• the kimi-k3 card states "Thinking is always enabled" and advertises "configurable low, high, or max reasoning effort", but none of its samples show the parameter. The entry assumes the top-level `reasoning_effort` its first-party API documents.

Package providers registers OpenAI's first-party platform.

Facts (https://developers.openai.com/api/docs — platform.openai.com/docs now redirects there):

• output cap is `max_completion_tokens` (`max_tokens` is one of the parameters reasoning models reject outright);
• thinking is graded with `reasoning_effort` only. The full vocabulary is none | minimal | low | medium | high | xhigh | max and every model takes a subset: `minimal` exists only on the original GPT-5 trio and is gone from gpt-5.1 and later, so the gpt-5* family folds minimal onto low; `none` is accepted from gpt-5.1 through gpt-5.6 but rejected by GPT-5, the o-series and GPT-6 Astra, which are therefore "off": null; `xhigh` is limited to GPT-6, GPT-5.6, GPT-5.5 and GPT-5.4, and `max` to GPT-6 and GPT-5.6 (https://developers.openai.com/api/docs/guides/reasoning, and the per-model support matrix Microsoft publishes for the same models at https://learn.microsoft.com/azure/ai-foundry/openai/how-to/reasoning);
• reasoning models take the `developer` role instead of `system`, and reject temperature, top_p, presence_penalty, frequency_penalty, logprobs, top_logprobs, logit_bias and max_tokens, so the gpt-6* / gpt-5* / o1* / o3* / o4* families set supports_temperature false;
• `store: false` is sent so completions are not retained, and `prompt_cache_key` steers cache routing; usage reports cached tokens;
• chat, embedding, VLM and ASR are served from https://api.openai.com/v1; there is no rerank API;
• requests that go to api.openai.com itself use the Responses protocol (https://developers.openai.com/api/docs/api-reference/responses), OpenAI's primary API where reasoning items and encrypted reasoning are replayable; relays and proxies that only speak Chat Completions keep that protocol because their base URL is not api.openai.com. Operators can force either with extra_config.api. Two documented Chat Completions restrictions make Responses the right default rather than a preference: `reasoning_effort: "max"` is Responses-only, and on GPT-5.6 models Chat Completions rejects `tools` together with any effort other than "none" ("Function tools with reasoning_effort are not supported ... in /v1/chat/completions. To use function tools, use /v1/responses"). A relay pinned to Chat Completions therefore cannot combine tools with graded thinking on those models; that is the relay's limit, not ours.

Unverified: `o1-mini` does not accept `reasoning_effort` at all, but the o1* family entry cannot express a single-model exception without shadowing the pattern, so the vendor-level supports_reasoning_effort still applies to it. Responses-only compat (prompt-cache retention, reasoning summaries) cannot be set per model here either: a models.json `compat` object is read against the entry's own API, and these entries are Chat Completions entries. GPT-5.6 and later replaced `prompt_cache_retention` with `prompt_cache_options.ttl`, which the protocol layer does not send yet.

Package providers registers the OpenRouter gateway.

Facts (https://openrouter.ai/docs/guides/best-practices/reasoning-tokens — the old /docs/use-cases/ path now redirects there):

• `max_tokens` is documented as deprecated ("Maximum tokens (deprecated, use max_completion_tokens)") and some upstreams enforce a minimum of 16 on it, so this vendor keeps the protocol default `max_completion_tokens`;
• thinking is expressed with the unified `reasoning` object ({"effort": ...} or {"enabled": bool}) which OpenRouter translates for every upstream. The effort enum is max | xhigh | high | medium | low | minimal | none, which is why xhigh and max are enabled vendor-wide; per-model support is gated by `supported_efforts` in /api/v1/models, and models flagged mandatory (today gemini-3.8-flash, gemini-3.1-pro-preview, glm-5.3, grok-4.6) reject an off switch entirely. Claude upstreams reject "none" and send minimal as low, so the anthropic/* family is "off": null with minimal folded onto low;
• Anthropic-routed models honour `cache_control` breakpoints, ephemeral with a 5m or 1h ttl and at most four explicit breakpoints (the anthropic/* family sets cache_control_format "anthropic");
• `prompt_cache_key` is accepted as the sticky routing key (OpenRouter's own preferred field is `session_id`) and usage reports prompt_tokens_details.cached_tokens;
• embeddings are routed through the same /api/v1 base (https://openrouter.ai/docs/api_reference/embeddings).

Unverified: GET /api/v1/models lists chat models only — embedding models live behind /api/v1/embeddings/models — so any future auto-sync of this catalog has to read both listings or it will silently lose embeddings.

Package providers registers Pinecone's standalone hosted rerank endpoint. https://docs.pinecone.io/guides/search/rerank-results

Package providers registers Baidu AI Cloud Qianfan through its OpenAI-compatible v2 endpoint.

Facts (v2 text generation reference https://cloud.baidu.com/doc/qianfan-api/s/3m7of64lb, auth https://cloud.baidu.com/doc/qianfan-api/s/ym9chdsy5):

• one host serves every model type: chat is POST /v2/chat/completions, embeddings POST /v2/embeddings (https://cloud.baidu.com/doc/qianfan-api/s/Fm7u3ropn) and rerank POST /v2/rerank, so all model types share the /v2 base URL;
• auth is `Authorization: Bearer <API Key>` and nothing else. The console-issued `appid` header is optional on v2 and is not a credential, so the vendor exposes no extra fields;
• both `max_tokens` (final answer only) and `max_completion_tokens` (answer plus thinking chain) are accepted; we send max_completion_tokens because it is the one that bounds the whole generation of a thinking model;
• tool_choice takes none / auto / required / a named function, parallel_tool_calls defaults to true, response_format takes text / json_object / json_schema, seed is accepted and stream_options.include_usage is supported, so every protocol default holds unchanged;
• usage carries prompt_tokens_details.cached_tokens, so the vendor does report prompt-cache counters (Baidu documents the counter for a subset of the ERNIE models only);
• thinking (https://cloud.baidu.com/doc/qianfan-docs/s/Wm95lyynv): the ERNIE and Qwen3 families switch it with `enable_thinking` (default false, except ernie-5.0-thinking-preview which defaults to true), while the DeepSeek / GLM / Kimi routes use `thinking: {"type": "enabled"|"disabled"}` and carry that as a per-model compat overlay in models.json. The chain length is capped by the top-level `thinking_budget` (default 16384, minimum 100). `reasoning_effort` (high | max) exists only on deepseek-v4-pro and deepseek-v4-flash, which this catalog does not list, so the vendor level never sends it.

Unverified:

• neither a mandatory thinking switch nor a non-stream restriction is documented, so thinking_always_send and thinking_disable_on_non_stream stay off;
• prompt_cache_key and Anthropic-style cache_control are not documented anywhere; only the usage counter above is;
• ernie-x1-turbo-32k no longer appears in the model list (https://cloud.baidu.com/doc/qianfan-docs/s/7m95lyy43) but no retirement notice was found, so the entry is kept unchanged, including its always-on "off": null;
• ernie-4.5-turbo-vl-32k is listed without thinking while the `-preview` variant of the same family has it, so the entry stays reasoning: false;
• the DeepSeek routes reject temperature / top_p / presence_penalty / frequency_penalty *while thinking*, but the docs give no rule for the non-thinking path, so supports_temperature is left alone;
• Qianfan also exposes a Responses API (https://cloud.baidu.com/doc/qianfan-docs/s/4mi400l1m); this vendor stays on Chat Completions, which is what the model pages document.

Package providers registers Qiniu Cloud's AI token gateway.

Facts (parameter reference https://developer.qiniu.com/aitokenapi/13390/chat-completions, endpoint https://developer.qiniu.com/aitokenapi/13379/real-time-ai-interface-api, FAQ https://developer.qiniu.com/aitokenapi/13462/aitoken-use-faq):

• the base URL is the host plus /v1; the FAQ spells it out as "domain + /v1" and the gateway serves POST /v1/chat/completions, POST /v1/messages (an Anthropic-compatible surface) and GET /v1/models. This package speaks Chat Completions, the format the parameter reference documents;
• auth is `Authorization: Bearer <API Key>`; there are no other credentials or vendor fields;
• output cap is `max_tokens`; `max_completion_tokens` is not in the reference;
• thinking is switched with `thinking: {"type": ...}`. The OpenAPI spec behind https://apidocs.qnaigc.com documents the types enabled | disabled | auto; this package only ever sends enabled / disabled, so "auto" is left to callers who set it themselves;
• `reasoning_effort` is graded, and the same spec lists its values as minimal | low | medium | high (plus `none`, which the protocol expresses as thinking.type=disabled). minimal..high therefore pass through under their own names and xhigh / max clamp down to high, which is the protocol default, so no vendor level map is needed;
• sampling is the full OpenAI set: temperature 0..2, top_p 0..1, top_k, presence_penalty / frequency_penalty -2..2, repetition_penalty 0..2;
• tools, tool_choice (none / auto / required / a named tool) and response_format are all accepted, so the protocol defaults hold;
• the gateway serves no embedding or rerank models: the FAQ states it "currently has no text vector or embedding models", which is why ModelTypes lists chat only.

unverified: `parallel_tool_calls` and `stream_options.include_usage` do not appear in the reference; the protocol defaults are kept.

unverified: no response schema is published, so nothing states whether usage carries cache counters. prompt_cache_accounting stays off, and neither prompt_cache_key nor Anthropic-style cache_control is documented.

unverified: nothing documents a mandatory thinking switch or a non-stream restriction, so thinking_always_send and thinking_disable_on_non_stream stay off.

unverified: the model catalogue is served dynamically from the model marketplace rather than published as a list, and /v1/market/models returned only a subset of the ids below. No retirement notice was found for any of them, so every entry is kept; models.dev lists no prices for this gateway, so cost is omitted.

Package providers registers the Requesty router.

Facts (https://docs.requesty.ai/features/reasoning and https://docs.requesty.ai/frameworks/openai):

• output cap is `max_tokens`; `max_completion_tokens` appears nowhere in the documentation;
• thinking is a flat `reasoning_effort` string (there is no OpenRouter-style reasoning object). Accepted values are none | min | low | medium | high | xhigh | max, plus a numeric budget passed as a string. Note the weakest rung is spelled `min`, not `minimal`, which is what the vendor level map corrects;
• `max` is not the top rung everywhere: "`xhigh` is OpenAI's highest reasoning effort. It is not the same as `max`. `max` is normalized to `high` for OpenAI models, whereas `xhigh` is a strictly higher tier." The OpenAI-routed entries therefore send `xhigh` for both xhigh and max; Anthropic-routed ones keep `max` as their top rung;
• model ids are always `provider/model`: "To specify a model, you must include the provider prefix". Every id in the live catalog carries one, and the bare `model_canonical_name` a record reports is metadata, not a usable value. The catalog entries below are prefixed accordingly;
• embeddings and VLM share the https://router.requesty.ai/v1 base; the Anthropic-style surface is a separate path (/anthropic/v1/messages) and xhigh is unreachable through it.

Unverified:

• Requesty warns "Do not hardcode model versions — model availability changes", and several routes only exist in dated form (deepseek/deepseek-v4-pro-0813). The undated deepseek-v4-flash has no first-party route at all, so it is left out rather than guessed;
• gemini-3.8-flash is routed under `vertex/` only; there is no `google/gemini-3.8-flash`, and the newest `google/` Gemini Flash is 3.6;
• GET /v1/models is chat-only; embedding models live at /v1/models/embedding, which the docs do not mention.

Package providers registers SiliconFlow (SiliconCloud), an OpenAI-compatible gateway to open-weight models.

Facts (https://docs.siliconflow.cn/cn/api-reference/chat-completions/chat-completions):

• output cap is `max_tokens`; `max_completion_tokens` is not documented;
• `enable_thinking` "在推理模式与非推理模式之间切换。该字段适用于大多数推理 模型", sent as a top-level boolean, together with `thinking_budget` (128 <= value <= 32768). Both work in streaming and non-streaming mode and neither is mandatory, so the switch is only sent when the caller asks for one;
• `reasoning_effort` accepts "high" | "max" and "该字段适用于 Pro/deepseek-ai/DeepSeek-V4、deepseek-ai/DeepSeek-V4-Flash 以及 Pro/zai-org/GLM-5.2", so every other reasoning entry disables it;
• usage reports `prompt_cache_hit_tokens` / `prompt_cache_miss_tokens`, hence prompt_cache_accounting;
• response_format accepts text (default), json_object and json_schema;
• temperature is [0, 2] (default 0.7) and top_p up to 1, unrestricted;
• one base URL serves chat, embedding, rerank, VLM and ASR, and the only credential is a bearer API key, so there are no ExtraFields.

unverified: the reference documents `tools` but not `tool_choice`, `parallel_tool_calls` or `stream_options`, so the protocol defaults for those three stand untested; unverified: `prompt_cache_key` and Anthropic-style cache_control are not documented, so neither is sent; unverified: the embedding / rerank / ASR entries (ids, dimensions) come from the SiliconCloud model pages, and the per-model context windows, output caps and prices in models.json are not restated in the API reference.

Package providers registers Volcengine Ark (Doubao) through its OpenAI-compatible chat endpoint.

Facts (https://www.volcengine.com/docs/82379/1494384 = Chat API reference, https://docs.volcengine.com/docs/ark/deep-thinking and https://docs.volcengine.com/docs/ark/base-url-and-authentication):

• the data-plane base URL is https://ark.cn-beijing.volces.com/api/v3 (chat completions at /chat/completions) with Bearer API-key auth; AK/SK signing is the alternative and is what the managed rerank service uses;
• output cap stays `max_completion_tokens` ("控制模型输出的最大长度（包括 模型回答和模型思维链内容长度）"), which is explicitly "不可与 max_tokens 字段同时设置". Its documented range is [1, 65536]; `max_tokens` defaults to 4096 and covers the answer only;
• thinking is switched with `thinking: {"type": ...}` where the type is enabled | disabled | auto — Ark does accept "auto" ("模型自行判断是否 需要进行深度思考"), although only doubao-seed-1-6-250615 lists it as supported today. Every model tagged 深度思考 defaults to enabled;
• `reasoning_effort` takes none | minimal | low | medium | high | xhigh | max and "所有支持该字段的模型均接受全部 7 档取值"; each model then maps the rungs it does not implement onto equivalents (Seed 2.x folds xhigh/max into high, glm-5-3-flash folds them into max, and on most models `minimal` switches thinking off). The vendor map therefore passes all seven through verbatim;
• doubao-seed-1-6-flash-250828 and doubao-seed-1-6-vision-250815 are absent from the reasoning_effort table, so those entries turn it off;
• glm-5-3-flash-260828 "始终启用思考，不再支持禁用思考", so it carries "off": null;
• temperature is [0, 2] but is "固定为 1，手动指定的参数值将被忽略" on doubao-seed-2-0-pro-260215 and doubao-seed-2-0-lite-260215;
• tool_choice takes none / auto / required / a named function, and parallel_tool_calls (default true, false only on doubao-seed-1.6 and later), response_format (text | json_object | json_schema, beta) and stream_options.include_usage are all documented, so the protocol defaults stand. glm-5-2-260617, deepseek-v4-pro-ga-260813 and deepseek-v4-flash-ga-260731 return streaming usage even without include_usage;
• usage reports `prompt_tokens_details.cached_tokens` (implicit cache); explicit prefix / session caching is a separate Context Cache API and is not driven from here;
• in tool-calling turns Ark also returns `encrypted_content` next to `reasoning_content` and asks for it to be replayed; omitting it is not an error but degrades multi-turn agent quality;
• embeddings post to /api/v3/embeddings/multimodal with `dimensions` defaulting to 2048, and answer one fused vector for the whole input (https://docs.volcengine.com/docs/ark/multimodal-vectorization-api). It is the only embedding API the current docs list, and the 向量化 model list names only the two doubao-embedding-vision snapshots. The text endpoint, /api/v3/embeddings in the OpenAI shape, now sits under 下线文档归档 (retired documentation), so doubao-embedding-large-text was removed from models.json; rows that still name a doubao-embedding text model are routed to that endpoint by pattern;
• rerank is the VikingDB Knowledge Base service signed with AK/SK at https://api-knowledgebase.mlp.cn-beijing.volces.com/api/knowledge/service/rerank (the API key field carries the access key; the secret key, region and instruction come from the rerank-only extra fields). Documented models are doubao-seed-rerank and base-multilingual-rerank (https://www.volcengine.com/docs/84313/1254474). datas takes at most 200 items, and the default instruction is the console's, verbatim, as the page asks for results that match the console;
• Ark additionally serves an Anthropic Messages surface at https://ark.cn-beijing.volces.com/api/compatible/v1 with x-api-key auth. This package configures OpenAI Chat Completions, which is the surface every model page documents first.

unverified: whether the retired text endpoint still answers for accounts that used it. Rows naming a text model reach it either way; before the catalog they were sent to the multimodal path.

unverified: the model list spells lengths as "256k" / "1024k" without saying whether k is 1000 or 1024, so the context windows in models.json are left at their present values.

unverified: prices in models.json come from the Ark pricing console, which the public docs do not render.

Package providers registers the WeKnora managed model service.

unverified: this is a first-party endpoint with no published API reference — https://weknora.weixin.qq.com/docs documents the WeKnora product, not the model gateway's wire protocol. Every fact below is taken from this repository's own clients rather than from vendor documentation, and is cited accordingly:

• one host serves chat, embedding, rerank and VLM. Chat completions and VLM live at /api/v1/chat/completions rather than the OpenAI default path (internal/models/vlm/weknoracloud.go), embeddings at /api/v1/embeddings (internal/models/embedding/weknoracloud.go) and rerank at /api/v1/rerank (internal/models/rerank/weknoracloud.go). Only the chat path goes through the Endpoint hook; the other three clients build their own URLs;
• requests are signed with the tenant's AppID / AppSecret through modelutils.Sign (internal/models/utils/signer.go), which sends X-APPID, X-API-Key, X-Request-ID, X-Timestamp, X-Nonce and an X-Signature that is the MD5 of the RFC3986-encoded, key-sorted parameter string including the MD5 of the body. There is no bearer key, hence the AuthSigned style and a fresh request id per call;
• credentials are provisioned through the dedicated initialization endpoint (internal/handler/weknoracloud.go), so Validate performs no key check here;
• the model names the product provisions are chat, embedding, rerank and vlm (frontend/src/utils/weknoraCloudModels.ts). models.json is left empty on purpose: no context window, output cap or price is published for them, and the embedding dimension is probed at runtime through GET /api/v1/models/weknoracloud/status.

unverified: SupportsMultiContent is kept false so chat messages are flattened to plain text, but nothing documents that restriction and the VLM client posts image_url parts to the very same /api/v1/chat/completions path, so it may only apply to the chat model. The value is left as-is because the transport test pins it.

unverified: PromptCacheAccounting is kept false; the gateway is not documented to report prompt-cache counters, and none have been observed.

Package providers registers Zhipu AI's BigModel open platform.

Facts (https://docs.bigmodel.cn/api-reference/模型-api/对话补全):

• chat completions live at POST /paas/v4/chat/completions under https://open.bigmodel.cn/api, so the base URL is https://open.bigmodel.cn/api/paas/v4;
• output cap is `max_tokens`; the reference lists no `max_completion_tokens`. GLM-5.3 / 5.2 / 5.1 / 5 / 4.7 / 4.6 cap at 128K output, the GLM-4.5 series at 96K;
• thinking is switched with `thinking: {"type": "enabled"|"disabled"}` (default enabled, GLM-4.5 and later only). The sibling `clear_thinking` defaults to true, i.e. the platform strips `reasoning_content` from previous turns unless it is set to false, so replaying it is accepted but normally a no-op;
• `reasoning_effort` takes none | minimal | low | medium | high | xhigh | max, defaults to max, and is only honoured by "GLM-5.2 及其以上模型" — GLM-5.1, GLM-5, GLM-4.7, GLM-4.6 and GLM-4.5 ignore it, so those entries turn it off. The vendor-level map spells every rung, including off -> "none";
• per-model effort ladders narrow that set: GLM-5.3 and GLM-5.3-Flash only take low / high / max, and GLM-5.2 maps none|minimal to "no thinking", low|medium to high and xhigh to max. That folding is the platform's own, so GLM-5.2 keeps sending "minimal" and "low" verbatim: rewriting minimal to "low" here would turn the weakest rung into the strongest one, because the platform then folds it to high;
• GLM-5.3 and GLM-5.3-Flash/FlashX always think: `thinking.type` "限制只 能开启", so both carry "off": null (https://docs.bigmodel.cn/cn/guide/models/text/glm-5.3, https://docs.bigmodel.cn/cn/guide/models/vlm/glm-5.3-flash);
• `tool_choice` is documented as "默认 auto 且仅支持 auto", so none / required / named-function are never sent;
• `response_format` takes text | json_object (no json_schema); temperature is [0.0, 1.0] and top_p is [0.01, 1.0], both two decimals;
• usage reports `prompt_tokens_details.cached_tokens`;
• the platform also exposes an Anthropic Messages facade at https://open.bigmodel.cn/api/anthropic (/v1/messages under it), which Resolve switches to when the base URL ends with /anthropic;
• embeddings: embedding-3 defaults to 2048 dimensions (256 / 512 / 1024 / 2048 selectable), embedding-2 is fixed at 1024;
• rerank is POST https://open.bigmodel.cn/api/paas/v4/rerank with model id "rerank".

unverified: the reference does not document `stream_options`, `parallel_tool_calls` or `seed`; the protocol defaults (include_usage sent, parallel tool calls and seed allowed) are kept because nothing states they are rejected.

unverified: glm-5v-turbo is a vision model and the "GLM-5.2 及其以上" rule does not name it, so its supports_reasoning_effort:false is kept as-is.

unverified: context windows, max output tokens and prices of individual entries beyond the GLM-5 / 5.2 / 5.3 / 4.7 model pages, and the glm-4.7-flash zero price.