feat(providers): add QuickSilver Pro

[raullenchai]

Summary

Adds QuickSilver Pro as a provider.

QuickSilver Pro is an inference API with an OpenAI-compatible chat-completions
surface: one API key, one balance, pay-as-you-go, no subscription.

Site	https://quicksilverpro.io
Base URL	https://api.quicksilverpro.io/v1
Docs	https://quicksilverpro.io/docs
Live model list	GET https://api.quicksilverpro.io/v1/models
Auth	Authorization: Bearer <key>, env QSP_API_KEY
SDK	@ai-sdk/openai-compatible

The endpoint works unchanged with the official openai clients. Streaming and
tool calling work on every model in this PR; structured output works on most,
and the per-model files record the exceptions.

Files

• providers/quicksilver-pro/provider.toml
• providers/quicksilver-pro/logo.svg
• providers/quicksilver-pro/models/*.toml — 32 models

Every model file uses base_model against an existing entry in models/ and is
override-only. No new lab metadata was needed — all 32 underlying models already
exist in this repo. bun validate passes.

Data provenance

The files are generated from our published catalogue by script, not hand-typed.
cost values are the retail per-million-token rates charged to the caller.

Verification (2026-08-05)

1. Model list. Our catalogue and the live GET /v1/models agree exactly —
same 33 ids, no drift in either direction. 32 are in this PR (see Notes).

2. Prices match the live API. GET /v1/models returns per-token prices.
Every cost.input / cost.output in this PR equals that value × 10⁶ to within
1e-9, checked programmatically for all 32 models.

3. Prices match what is actually billed. For 7 models spanning 7 different
model families we made real calls and compared usage × the price published
here against the recorded spend for that same call:

model	prompt / completion tokens	expected	billed	ratio
deepseek-v4-flash	12 / 40	0.00001030400	0.00001030400	1.0000000
qwen3.7-max	20 / 3	0.00003625000	0.00003625000	1.0000000
claude-haiku-4-5	489 / 9	0.00042720000	0.00042720000	1.0000000
gemini-3.5-flash-lite	8 / 5	0.00001266500	0.00001266500	1.0000000
kimi-k2.6	16 / 40	0.00011787520	0.00011787520	1.0000000
glm-5.2	14 / 5	0.00003328000	0.00003328000	1.0000000
gpt-5.6-luna	14 / 9	0.00000544000	0.00000544000	1.0000000

A second round with cache hits reproduced the published cost.cache_read rates
exactly (e.g. deepseek-v4-flash 0.00224, glm-5.2 0.208 per 1M), so the
cache_read figures here are also reproducible from a caller's own usage
numbers.

4. Capability flags were probed, not assumed. Rather than inherit
capabilities on trust, we tested them against the live endpoint and recorded the
differences:

• Tool calling: all 32 models returned a well-formed tool_calls response.
• Structured output: 24 of 32 accept response_format: json_schema and
  return schema-conforming JSON. qwen3.7-flash and qwen3.6-plus reject it
  with HTTP 400 (json_object works); the six Claude models accept it but do
  not enforce it. Those eight carry structured_output = false.
• Vision: verified with a solid-colour image plus a differently-coloured
  control, so a correct answer cannot be a lucky guess. This surfaced one
  correction — minimax-m3 accepts an image payload with HTTP 200 but the model
  does not receive it, so its modalities.input is published as text-only here
  rather than inheriting image/video.
• Reasoning: swept all seven reasoning_effort values per model, with a
  deliberately invalid value as a control. The Gemini lines validate the enum
  (xhigh/max are rejected) and several show a clear response to the level,
  so they carry the accepted effort values. deepseek-v4-pro reproducibly
  drops to zero reasoning tokens on none, so it carries a toggle. On the
  remaining models the parameter is accepted but had no observable effect, so
  they carry reasoning_options = [] per the "no caller control" convention.

Notes for reviewers

• 33 models are served; 32 are listed. flux.2-pro is billed per generated
  image, not per token, and is only exposed on images.generations. The cost
  schema has no per-image field and limit.context/limit.output are required,
  so it is omitted rather than misrepresented as a token price. Happy to add it
  if there is a preferred way to express per-image pricing.
• Two models carry status = "deprecated" (gemini-3-flash-preview,
  gemini-3.1-flash-lite). They are still served and billable today, but are on
  our sunset path and we would rather not have tooling default to them. If you
  read deprecated strictly as "already removed", say so and we will drop them
  from this PR instead.
• Context windows are inherited from the lab entries, not from our own
  catalogue. Our catalogue rounds several context windows up to 1,048,576;
  where that exceeds the lab figure in this repo we deliberately kept the lower,
  correct number rather than publish an inflated limit. We override limit only
  where we genuinely serve less (kimi-k2.6 and kimi-k2.7-code at 256,000;
  the three gpt-5.6-* lines at 1,048,576). We are fixing the rounding on our
  side separately.
• gemini-3-pro-image returned a valid tool call in our probe even though the
  lab entry has tool_call = false. We left the lab value alone rather than
  claim the capability off a single observation.

[github-actions]

Action items

• [high] [violation] providers/quicksilver-pro/models/minimax-m3.toml:585 - Check: Provider overrides must keep modalities and attachment consistent after base_model merge. Why: The file forces modalities.input = ["text"] because image input is not served, but it does not set attachment = false. The lab entry has attachment = true and image/video input, so the resolved model still advertises attachments while rejecting/ignoring them. Peers that text-only MiniMax (e.g. novita/opencode) always pair text-only modalities with attachment = false. Action: Add attachment = false alongside the modalities override.
• [high] [possible mistake] providers/quicksilver-pro/models/gpt-5.6-luna.toml:403 - Check: On multi-model relays, reasoning_options = [] means affirmative no caller control, not uncertainty; baseline is lab + same-surface peers. Why: OpenAI first-party and OpenRouter expose reasoning_effort as none|low|medium|high|xhigh|max for GPT-5.6 Luna/Sol/Terra. This PR sets [] on all three while the same host publishes working reasoning_effort for Gemini and a DeepSeek Pro toggle (reasoning_effort = none). That is a strong internal contradiction for models whose native control is reasoning_effort. Action: Re-measure GPT-5.6 Luna/Sol/Terra with reasoning-token/latency differentials across none|low|medium|high|xhigh|max; if any level changes behavior, copy the lab/peer effort set. Keep [] only with hard evidence every level is a no-op.
• [medium] [possible mistake] providers/quicksilver-pro/models/gemini-3.1-pro-preview.toml:317 - Check: Relay effort lists must follow lab/peer baseline; extra levels need live meaningful effect, not mere HTTP acceptance. Why: Every Gemini file uses the same none|minimal|low|medium|high set. That diverges from established baselines: Gemini 3.1 Pro lab/OpenRouter are low|medium|high (no none/minimal); flash family lab/OpenRouter are minimal|low|medium|high (no none); Gemini 3 Pro Image is low|high on Google and [] on OpenRouter. Comments only say values are “accepted,” which is below the audit bar for inventing levels. Action: Per model, match lab/same-surface peers unless you can show separable effect for each extra value; in particular drop or justify none/minimal on 3.1 Pro and the broad enum on gemini-3-pro-image.
• [medium] [possible mistake] providers/quicksilver-pro/models/grok-4.5.toml:469 - Check: Relay [] on effort-controlled reasoners needs affirmative no-control evidence on this host’s wire surface. Why: xAI first-party exposes reasoning_effort low|medium|high for Grok 4.5. Comments only say the parameter is accepted with “no observable effect,” while this host’s Gemini entries prove reasoning_effort is a live control path. Action: Re-verify Grok with measurable reasoning metrics; if levels differ, publish ["low","medium","high"] (plus none only if off is real).