Each suggested model names and links its licence before Download.
A finished file is checked against Hugging Face's sha256; no API, no check, and the card says so.
A 429 from Hugging Face is waited out as its headers ask, counted down on the card.
Endpoint + key, normalised to the v1 base URL; key never shared with OpenAI.
Model ids are deployment names; Test probes the resource's /openai/v1/models.
The box stays at the end of the API-keys group; saving makes a card titled by the user, prefix derived from the name.
A custom card lists its server's /models on request (a missing listing is a note, not a failure).
Re-saving a custom key now rebuilds its client; strings in en + zh.
Same shape as llama.cpp/vLLM/LM Studio: address + optional key, models from the server.
Docker's /engines path is added when the user types the root; mlx-lm's help covers the port shared with llama.cpp.
Local-server checks now read LOCAL_SERVERS instead of a hand-kept tuple.
Install with Homebrew, pick a model sized to the Mac (or one Ollama has), start it.
OpenWorker runs llama-server, downloads into llama.cpp's cache, stops it on quit.
Wires Upstage into the existing compat-vendor pattern: a _compat descriptor
(prefilled https://api.upstage.ai/v1 endpoint, UPSTAGE_API_KEY env fallback),
a solar-pro3 matrix entry, the "solar" capability heuristic, suggested-model
extras, and the GUI key-help link + vendored lobe-icons logo.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Three rows from the live catalogue with the 1M windows NVIDIA lists (2026-10-25).
A non-default endpoint is probed with GET /models, so Test works on a self-hosted NIM.
Sonnet 5 (1,000,000) and DeepSeek V4 Pro (1,048,576) from the public catalogue, 2026-10-25.
Suggestions come from the matrix; the default endpoint help applies.
Registers OrcaRouter (https://www.orcarouter.ai) as a first-class
OpenAI-compatible provider, mirroring the existing OpenRouter wiring:
prefilled endpoint, ORCAROUTER_API_KEY (sk-orca- keys), server + GUI key
detection, verify support, three curated matrix models (Claude Sonnet 5,
GPT-5.5, DeepSeek V4 Pro), a GUI logo and keys link, and tests.
Co-Authored-By: Claude <noreply@anthropic.com>
Nebius Token Factory serves many labs' models behind one key over an
OpenAI-compatible API, so it joins Together/Fireworks as a reseller
descriptor plus curated matrix rows in their own namespaces.
Verified against the live API on 2026-07-26: /v1/models, a tool-call
round-trip and streaming on all four curated ids, and verify_provider_key
for both a good and a bad key.
Co-authored-by: Cursor <cursoragent@cursor.com>
Same address checks first, then the provider returns the page; a failure falls back to a local fetch with a notice.
The approval card learns which service fetches.
The web_search:default profile keeps keys per provider; the legacy api_key shape is read as keys[provider].
Routes: GET/POST /v1/web-search, PUT/DELETE /v1/web-search/keys/{name}, POST /v1/web-search/fetch-via-provider.
Both You.com hosts join PROVIDER_HOSTS (keyed vs keyless) and the Sites catalogue; the YDC_API_KEY fallback moves to key resolution.
Every provider declares key_mode none/optional/required beside display_name and key_url.
You.com is usable with no API key at all — the free agents endpoint gives
100 searches/day, rate-limited per IP — so it works on a fresh install the
way the ddgs default does, and switches to the Search API when a key is
configured.
Supporting that needed one change outside the provider class. Key handling
was a single boolean, and build_provider discarded the API key for any
provider with requires_key = False, so a provider that is keyless but
better with a key could not be expressed: a key set through the SecretStore
or POST /v1/web-search would be silently ignored. WebSearchProvider gains
an accepts_key flag, defaulting to False, and build_provider passes the key
through when it is set. DuckDuckGo, Tavily and Brave are unaffected.
Nothing else moves. SearchResult keeps its three fields, the manager, the
/v1/web-search endpoints and the agent registry all read provider_names(),
and resolve_provider() already derives YOU_API_KEY from the provider name
(YDC_API_KEY is accepted as a fallback, the name You.com's own docs use).
httpx is already a core dependency.
Requests send User-Agent: youdotcom-integration/andrewyng-openworker, to
You.com hosts only. On the keyless tier there is no key, so this is the
only way the traffic can be attributed.
Firecrawl's host joins PROVIDER_HOSTS and the Access ▸ Sites catalogue.
The class gets display_name and key_url and raises on HTTP errors like the others.
Same keyed httpx pattern as Tavily/Brave, hitting Firecrawl's v2 /search
endpoint. Key resolves from the SecretStore or FIRECRAWL_API_KEY. Also
documents web_search_provider in config.example.toml.
Implement SerperProvider - a web search provider using the Serper.dev
Google Search API. Follows the same patterns as existing third-party
providers (Tavily, SERPdive, Exa).
- New SerperProvider class with search() method
- Registered in _PROVIDERS dict and exported
- Comprehensive test with mock HTTP responses
Rohit C Prasad