feat(providers): add Onlist

[onlist-io]

Summary

Adds Onlist as a provider. Onlist is an OpenAI-compatible API gateway that speaks the OpenRouter surface (/v1/models, /v1/chat/completions, OpenRouter-style reasoning object, /api/v1/key / /api/v1/credits account endpoints), so model ids are the same <author>/<slug> ids used under providers/openrouter. This batch registers the provider, its logo, and 76 open-weight models. All model files are override-only via base_model.

Changes

• providers/onlist/provider.toml — @ai-sdk/openai-compatible, api = "https://onlist.io/v1", env = ["ONLIST_API_KEY"], doc = "https://onlist.io/models".
• providers/onlist/logo.svg — monochrome, fill="currentColor", square viewBox, no fixed size.
• providers/onlist/models/**/*.toml — 76 open-weight models (DeepSeek, Qwen, Llama, Gemma, GLM, Kimi, Mistral, gpt-oss, etc.). Each file has:
  • base_model pointing at the existing models/<lab>/<id>.toml;
  • [cost] in USD per million tokens from the live catalog;
  • [limit] context only where the served context window differs from the lab default;
  • reasoning_options limited to what Onlist forwards on the wire (see Review notes);
  • [interleaved] kept where the stream carries reasoning_content.

Evidence

• Live catalog: https://onlist.io/v1/models
• Per-model page with served context length and price, cited in each file's leading comment: https://onlist.io/models/<author>/<slug>
• Catalog and pricing field semantics: https://onlist.io/docs/models
• Compatibility surface and accepted parameters: https://onlist.io/docs/migrate-from-openrouter

Validation

bun validate passes locally; the generated output contains provider onlist with 76 models.

Review notes

• First batch is open-weight models only; a closed-weight-model follow-up is out of scope for this PR.
• toggle is authored only for Alibaba/Qwen routes, using enable_thinking (Alibaba's own top-level field, verified end-to-end through the relay's Ali adaptor) — not OpenRouter's reasoning.enabled, which Onlist parses but never reads. Everywhere else, reasoning_options is effort/budget-only (or [] for always-on/no-control routes), since Onlist has no on/off switch beyond that one host-specific field.
• description overrides were dropped everywhere; they were OpenRouter's own editorial paraphrase, not Onlist-specific deltas.

[github-actions]

Action items

• [high] [violation] providers/onlist/models/qwen/qwen3.6-plus.toml:5 - Check: Relay reasoning_options must match this host’s wire controls using lab + same-surface peers (AGENTS.md Reasoning options; audit skill §2/§5). Why: Onlist is authored as an OpenRouter-shaped multi-model relay, and OpenRouter peers for Qwen hybrid models use { type = "toggle" } (often with lab-side budget). These files set reasoning_options = [], which means no caller control. That understates controls peers expose on the same surface and violates the “do not write [] from uncertainty / when peers have controls” rule. Same pattern on qwen3.5-*, qwen3.6-*, qwen3.7-*, qwen3-235b-a22b, qwen3-30b-a3b, qwen3-32b, and related hybrid Qwen entries. Action: For each hybrid Qwen reasoner, set reasoning_options to the OpenRouter/lab intersection Onlist actually forwards (at minimum toggle where peers have it; add budget_tokens only if this host forwards a real reasoning budget). Add a leading wire comment for every toggle. Use [] only with affirmative proof that Onlist cannot turn thinking on/off.
• [high] [violation] providers/onlist/models/z-ai/glm-5.toml:4 - Check: Same-surface peer reasoning controls for Z.AI/GLM. Why: OpenRouter peers for glm-4.5*, glm-4.6*, glm-4.7*, glm-5, glm-5.1, glm-5-turbo, glm-5v-turbo use toggle (and glm-5.2 uses toggle + effort). Onlist sets reasoning_options = [] on those routes, so clients cannot express the on/off control the peer surface documents. Action: Align each GLM entry with the OpenRouter peer shape for that model (toggle, or toggle + effort for glm-5.2), with leading toggle wire comments—or cite host docs proving Onlist drops reasoning.enabled / equivalent.
• [high] [violation] providers/onlist/models/deepseek/deepseek-v4-pro.toml:5 - Check: DeepSeek V4 baseline on a faithful OpenRouter-style relay = toggle + graded effort (lab/peers), not effort-only. Why: First-party DeepSeek and OpenRouter use toggle plus effort (high/max or high/xhigh). Onlist keeps effort only and omits toggle on deepseek-v4-pro, deepseek-v4-flash, deepseek-v4-*-0731/0813/vision-exp. deepseek-v3.2 is worse: OpenRouter peer is toggle, Onlist is []. Action: Add toggle (leading wire comment) alongside the peer effort lists for V4 routes; set deepseek-v3.2 to [{ type = "toggle" }] unless Onlist cannot forward the control.
• [high] [violation] providers/onlist/models/anthropic/claude-opus-4.5.toml:5 - Check: Do not treat Anthropic Messages controls as interchangeable with an OpenAI/OpenRouter chat-completions relay; do not invent budget_tokens on effort/toggle-only surfaces. Why: OpenRouter peers for Claude Opus 4.1/4.5 and Sonnet 4.5 use toggle only. Onlist authors budget_tokens (Anthropic extended-thinking shape) and no toggle, while comments claim an OpenRouter-style reasoning object. That mismatches the same-surface peer set and risks a bogus budget control. Action: Match OpenRouter Claude peers (toggle, leading wire comment) unless Onlist docs/tests show a real reasoning-token budget field on this path; do not copy native Anthropic budget_tokens onto the relay by default.
• [high] [violation] providers/onlist/models/google/gemini-2.5-flash.toml:5 - Check: Gemini reasoning controls on OpenRouter-shaped relays. Why: OpenRouter peers use toggle for gemini-2.5-flash / gemini-2.5-flash-lite, and toggle + effort for several Gemini 3.x routes (e.g. gemini-3-flash-preview). Onlist uses [] or effort-only without toggle. Action: Restore peer toggle (and keep verified effort lists) for each Gemini reasoner that peers control; reserve [] only for always-on / no-control routes with evidence.
• [high] [violation] providers/onlist/models/moonshotai/kimi-k2.5.toml:6 - Check: Kimi / Xiaomi / Nemotron peer reasoning_options. Why: OpenRouter uses toggle for kimi-k2.5, kimi-k2.6, kimi-k3 (plus effort), mimo-v2.5, mimo-v2.5-pro, and toggle (+ effort/budget) for Nemotron Super/Ultra. Onlist uses [] or drops toggle while keeping effort/budget. Action: Add the missing toggle (and keep peer effort/budget only where still valid on Onlist) for these models, with leading wire comments.
• [medium] [violation] providers/onlist/models/qwen/qwen3.8-flash.toml:8 - Check: budget_tokens only with the host’s full control set; include peer toggle when present. Why: OpenRouter qwen3.8-flash is toggle + budget_tokens. Onlist authors budget alone, so on/off is missing on a hybrid reasoner. Action: Add toggle beside budget_tokens (leading comments for both wire paths), matching the peer unless Onlist cannot forward enable/disable.
• [medium] [violation] providers/onlist/models/bytedance-seed/seed-2.0-lite.toml:4 - Check: After base_model, do not restate or replace identical/non-delta lab fields; provider description overrides must be real host deltas. Why: Lab description is “Cost-efficient ByteDance Seed 2.0 model for production chat…”. Onlist replaces it with a generic “Multimodal reasoning model…” string. Similar incorrect bulk description overrides appear on e.g. deepseek-v3.2, gemini-3.5-flash-lite, gemini-3.7-flash, gemini-3.8-flash, gpt-5.6-*-pro, gpt-oss-20b, and others—changing catalog facts without a host-specific display reason. Action: Drop description (and other capability) overrides that are not intentional Onlist-specific deltas; inherit lab text, or only override when the served product name/positioning truly differs.
• [low] [possible mistake] providers/onlist/models/openai/gpt-5.6-luna-pro.toml:3 - Check: Provider display name / base_model mapping for GPT-5.6 Pro aliases. Why: Files map gpt-5.6-luna-pro → base_model = "openai/gpt-5.6-luna" with name = "GPT-5.6 Luna Pro" (same for sol/terra). Confirm these are real Onlist route IDs and not mislabeled base SKUs, and that effort none…max matches what this host accepts for those routes. Action: Verify against the live Onlist model id list and peer GPT-5.6 reasoning enums; fix id/name/base_model if the Pro suffix is wrong.

[github-actions]

Action items

• [high] [violation] providers/onlist/models/deepseek/deepseek-v4-pro.toml:366 - Check: Relay reasoning_options must follow lab + same-surface peer controls (AGENTS.md Reasoning options; audit skill §2/§5). Why: Onlist is a multi-model OpenRouter-shaped gateway, but these files drop the peer/lab toggle (OpenRouter and first-party DeepSeek use toggle + effort; Moonshot K3 / GLM-5.2 / Qwen3.8-27b / Nemotron Super|Ultra peers also include toggle). Leading comments assert “no on/off toggle” while the PR claims an OpenRouter-style reasoning object—so either the surface is incomplete/wrong or the catalog under-reports caller control. Action: For every reasoner that OpenRouter/lab peers expose as toggleable, either add { type = "toggle" } with a top-of-file wire comment (e.g. reasoning.enabled / equivalent), or cite host docs/tests proving toggle is rejected and keep effort-only only where effort is still real. Apply across at least: deepseek-v4-{pro,flash,pro-0813,flash-0731}, moonshotai/kimi-k3, z-ai/glm-5.2, qwen/qwen3.8-27b, nvidia/nemotron-3-{super-120b-a12b,ultra-550b-a55b}.
• [high] [violation] providers/onlist/models/qwen/qwen3.5-27b.toml:1085 - Check: On relays, reasoning_options = [] means affirmative no caller control, not a stripped peer set. Why: Dozens of Onlist reasoners are authored as [] while the same OpenRouter ids (and often first-party labs) expose toggle (Qwen3/3.5/3.6 family, Gemma 4 IT, Kimi K2.5/K2.6, Xiaomi MiMo V2.5/Pro, GLM 4.5–5.1/5, DeepSeek V3.2, Nemotron Nano, Poolside Laguna, etc.). Empty options hide controls consumers need if Onlist truly shares that surface. Action: Replace [] with the peer-accurate control set (usually toggle, plus effort/budget only when peers/lab have them and Onlist forwards them). Use [] only for always-on/no-control models that peers also mark that way (e.g. R1, Kimi K2 Thinking, Qwen3-Next Thinking, MiniMax M2.x where peers are already []).
• [low] [possible mistake] .pr-review/pull-request.json:4 - Check: PR summary accuracy for catalog size. Why: Body claims “162 models”; the diff adds 76 model TOMLs (plus provider.toml and logo.svg). Action: Correct the count (or add the missing model files if 162 was intended).

[github-actions]

Action items

• [high] [violation] providers/onlist/models/deepseek/deepseek-v4-pro.toml:365 - Check: Relay reasoning_options must match lab + same-surface peers when the host exposes those controls (AGENTS.md / audit skill). Why: Onlist is authored as an OpenRouter-shaped multi-model relay, but DeepSeek V4 entries omit toggle while OpenRouter peers use toggle + effort (high/xhigh or low/high/max), and first-party DeepSeek uses toggle + high/max. Comments asserting “no on/off toggle on Onlist” conflict with the PR’s OpenRouter-surface claim and strip a documented caller control. Action: For deepseek-v4-pro, deepseek-v4-flash, deepseek-v4-pro-0813, and deepseek-v4-flash-0731, add toggle (with a leading wire comment for the exact path) plus the peer-matching effort set; only keep toggle-less shapes if you document host-specific evidence that Onlist does not forward on/off.
• [high] [violation] providers/onlist/models/z-ai/glm-5.toml:1620 - Check: Do not author reasoning_options = [] on a relay of a controlled reasoner from uncertainty/denial of toggle. Why: OpenRouter peers for GLM 4.5–5.x use toggle (and glm-5.2 uses toggle + effort high/xhigh). Onlist sets [] for glm-4.5, glm-4.5-air, glm-4.5v, glm-4.6, glm-4.6v, glm-4.7, glm-4.7-flash, glm-5, glm-5.1, and only effort (no toggle) for glm-5.2, while claiming no on/off control. That misrepresents caller capability on an OpenRouter-compatible gateway. Action: Align these Z.AI models with OpenRouter peer shapes (toggle, and for glm-5.2 also effort high/xhigh); keep [] only with affirmative proof this route has no on/off control.
• [high] [violation] providers/onlist/models/moonshotai/kimi-k2.5.toml:665 - Check: Relay baseline = lab + same-surface peer option set. Why: OpenRouter peers use toggle for kimi-k2.5 and kimi-k2.6, and toggle + effort low/high/max for kimi-k3. Onlist uses [] for k2.5/k2.6 and effort-only for k3, again under “no on/off toggle.” Action: Restore peer-matching toggle (and k3 effort) with a correct leading wire comment, or provide host-specific evidence that Onlist does not forward Moonshot reasoning enablement.
• [high] [violation] providers/onlist/models/google/gemma-4-26b-a4b-it.toml:388 - Check: Empty reasoning_options means no caller control, not untested. Why: OpenRouter peers for both Gemma 4 IT models use toggle; Onlist sets [] with the same “no toggle” comment. Action: Set reasoning_options to peer-matching toggle for gemma-4-26b-a4b-it and gemma-4-31b-it, or prove Onlist cannot turn thinking on/off for these IDs.
• [high] [violation] providers/onlist/models/nvidia/nemotron-3-nano-30b-a3b.toml:748 - Check: Copy intersection of native/peer controls this host can expose. Why: OpenRouter peers use toggle for nano/lightning/content-safety, and toggle + effort + budget_tokens for super/ultra. Onlist uses [] for nano/lightning/content-safety and effort+budget_tokens without toggle for super/ultra. Action: Add the missing toggle (and keep super/ultra effort + budget_tokens only if reasoning.max_tokens is real on Onlist); do not leave [] while claiming an OpenRouter-compatible reasoning object.
• [high] [violation] providers/onlist/models/xiaomi/mimo-v2.5.toml:1408 - Check: Same-surface peer controls for reasoners. Why: OpenRouter peers use toggle for both MiMo V2.5 models; Onlist uses []. Action: Match peer toggle (with wire comment) for mimo-v2.5 and mimo-v2.5-pro, or cite host proof of no control.
• [high] [violation] providers/onlist/models/minimax/minimax-m3.toml:553 - Check: Peer relay option set for MiniMax-M3. Why: OpenRouter minimax-m3 has toggle; Onlist uses []. (M2 family [] matching OpenRouter is fine.) Action: Set M3 to toggle like the OpenRouter peer, or prove Onlist lacks that control.
• [high] [violation] providers/onlist/models/poolside/laguna-xs-2.1.toml:893 - Check: Peer relay option set. Why: OpenRouter peer uses toggle; Onlist uses []. Action: Match peer toggle or provide Onlist-specific evidence of no control.
• [high] [violation] providers/onlist/models/deepseek/deepseek-v3.2.toml:278 - Check: Peer relay option set for DeepSeek V3.2. Why: OpenRouter peer uses toggle; Onlist uses [] under “no on/off toggle.” Action: Align with peer toggle or document that this Onlist route cannot disable thinking.
• [medium] [possible mistake] providers/onlist/models/qwen/qwen3-235b-a22b.toml:906 - Check: Toggle wire path must match this host’s API, not a different lab surface. Why: Files claim top-level Alibaba enable_thinking while the PR describes an OpenRouter-compatible surface (OpenRouter peers document reasoning.enabled). If Onlist truly speaks OpenRouter’s reasoning object, these wire comments (and possibly the control mapping) are wrong; if it only special-cases DashScope fields for Qwen, that exception needs evidence and should not contradict the “no toggle” story used elsewhere. Action: Verify and document the actual Onlist request field for Qwen thinking on/off; make wire comments and reasoning_options consistent across the provider (OpenRouter-style vs lab-specific), including whether budget_tokens belongs for 3.5/3.8 paths that lab/peers sometimes expose.

[onlist-io]

Addressed the internal-consistency point: enable_thinking was Qwen-specific info, not a general Onlist policy. Checked the source of truth instead of guessing per-family.

Onlist's request struct carries a small set of named pass-through fields, one per lab wire convention, each verified to survive to the upstream unmodified:

• enable_thinking (top-level bool) — Alibaba/Qwen only, confirmed in the dedicated Ali adaptor.
• thinking ({type: "enabled"|"disabled"}) — Z.AI/GLM v4+, confirmed via the generic OpenAI-compatible adaptor (tagged for doubao,zhipu_v4 in the request struct).

Both are now authored as toggle with a wire comment naming the actual field (not reasoning.enabled, which Onlist parses but never acts on for any model).

No equivalent field exists in the request struct for DeepSeek, Moonshot/Kimi, MiniMax, Nvidia/Nemotron, Xiaomi/MiMo, Poolside, or Gemma. For those, reasoning_options stays effort/budget-only (or [] where OpenRouter's own peer entry is also []), since I don't have a verified on/off path to claim for them. Happy to add toggle for any of these if there's a confirmed request field I'm missing — genuinely open to correction here, not declining on principle.

.pr-review/pull-request.json's stale "162 models" was from the PR review harness's own snapshot at the time of the first review; the PR body itself was corrected to 76 in the same push.

[github-actions]

Action items

• [high] [violation] providers/onlist/models/deepseek/deepseek-v4-flash.toml:321 - Check: Relay reasoning_options must match lab + same-surface peers when the host exposes those controls. Why: Onlist is a multi-model OpenRouter-style relay. Lab DeepSeek V4 and OpenRouter peers use toggle + effort (high/xhigh or low/high/max). These files only author effort and comment “no on/off toggle,” so clients cannot turn thinking off/on on models that support it on lab and OpenRouter. Action: Add { type = "toggle" } (and a leading wire comment for the exact path, e.g. reasoning.enabled or the field Onlist actually forwards) on deepseek-v4-flash, deepseek-v4-pro, deepseek-v4-flash-0731, and deepseek-v4-pro-0813.
• [high] [violation] providers/onlist/models/deepseek/deepseek-v3.2.toml:278 - Check: Relays must not use reasoning_options = [] when lab/peers expose caller controls. Why: OpenRouter’s same-ID entry is toggle only; [] means no control and understates the surface. Action: Set reasoning_options to [{ type = "toggle" }] with a leading wire comment, or document a host-specific reason this path has no on/off control.
• [high] [violation] providers/onlist/models/moonshotai/kimi-k2.5.toml:665 - Check: Relay reasoning controls vs lab/OpenRouter peers. Why: Lab Moonshot and OpenRouter use toggle for K2.5/K2.6; K3 is toggle + ["low","high","max"]. Onlist uses [] for K2.5/K2.6 and effort-only for K3. Action: Add toggle on kimi-k2.5, kimi-k2.6, and kimi-k3 (keep K3 effort); drop false [].
• [high] [violation] providers/onlist/models/google/gemma-4-31b-it.toml:406 - Check: Gemma reasoning toggle on relays. Why: First-party Google and OpenRouter both use toggle; Onlist uses [] for both Gemma 4 IT models. Action: Set reasoning_options = [{ type = "toggle" }] on gemma-4-31b-it and gemma-4-26b-a4b-it.
• [high] [violation] providers/onlist/models/minimax/minimax-m3.toml:553 - Check: MiniMax-M3 reasoning toggle. Why: First-party MiniMax and OpenRouter author toggle; Onlist uses []. Action: Replace [] with [{ type = "toggle" }] and a wire comment.
• [high] [violation] providers/onlist/models/nvidia/nemotron-3-super-120b-a12b.toml:768 - Check: Nemotron relay options vs OpenRouter peers. Why: OpenRouter peers use toggle (+ effort/budget where present). Onlist omits toggle on super/ultra and uses [] on nano, 3.5-lightning, and 3.5-content-safety. Action: Add toggle to super/ultra (keep effort/budget if still valid on this host); replace [] with toggle on nano, lightning, and content-safety.
• [high] [violation] providers/onlist/models/xiaomi/mimo-v2.5.toml:1408 - Check: MiMo reasoning toggle on relays. Why: OpenRouter peers use toggle for both MiMo v2.5 models; Onlist uses []. Action: Set toggle on mimo-v2.5 and mimo-v2.5-pro.
• [high] [violation] providers/onlist/models/poolside/laguna-xs-2.1.toml:893 - Check: Laguna reasoning toggle on relays. Why: OpenRouter peer is toggle; Onlist uses []. Action: Set reasoning_options = [{ type = "toggle" }] with a leading wire comment.
• [medium] [possible mistake] providers/onlist/models/deepseek/deepseek-v3.2.toml:276 - Check: Claimed OpenRouter-compatible reasoning surface vs “no on/off toggle” comments. Why: The PR describes an OpenRouter-style reasoning object, but many reasoners are marked as having no toggle. That is inconsistent with OpenRouter peers and with AGENTS.md (empty means no control, not uncertainty). Action: Align all reasoner reasoning_options with what Onlist actually forwards; if some models truly lack toggle, cite host docs/tests per model instead of a blanket “no toggle” comment on controlled models.