feat: add Requesty as a remote model provider

[Thibaultjaigu]

Summary

Adds Requesty as a remote model provider in Jan. Requesty is an OpenAI-compatible LLM gateway (base URL https://router.requesty.ai/v1) that exposes models from multiple providers using the provider/model naming convention — the same shape Jan already uses for OpenRouter.

This change mirrors the existing OpenRouter provider registration. No new code paths were introduced; Requesty reuses the generic OpenAI-compatible request flow.

Changes

• web-app/src/constants/providers.ts — add the requesty provider entry (base_url, explore_models_url, api-key setting), mirroring the OpenRouter object.
• web-app/src/constants/models.ts — add the requesty capability flags entry.
• web-app/src/lib/providerCaps.ts — add REQUESTY sampling caps and register it.
• web-app/src/lib/ai-model.ts — send the same HTTP-Referer / X-Title identification headers used for OpenRouter.
• web-app/src/lib/utils.ts — add provider logo path and display title (Requesty).
• web-app/public/images/model-provider/requesty.svg — placeholder logo. This is a generic "R" mark, not the official brand asset; maintainers are welcome to drop in the official Requesty logo.
• docs/src/pages/docs/desktop/remote-models/requesty.mdx — provider docs page mirroring openrouter.mdx.
• docs/src/pages/docs/desktop/remote-models/_meta.json, docs/src/pages/docs/desktop/manage-models.mdx, docs/_redirects — docs nav entry, cloud-provider card, and redirect.

Testing

Verified a live request against the Requesty endpoint with POST https://router.requesty.ai/v1/chat/completions, model openai/gpt-4o-mini — returned HTTP 200 with a valid completion. This confirms the base URL, auth scheme, and provider/model naming used in the provider entry are correct.

A full monorepo install was not run locally, so I have not produced a UI screenshot. The edits are data/constant additions that match the existing OpenRouter entry's shape exactly; happy to add a screenshot if a maintainer can point me at the lightest way to build the web-app, or if you'd prefer I adjust anything.

Disclosure: I work at Requesty. This mirrors the existing OpenRouter provider entry; happy to adjust wording/placement or close if it's not a fit.

[tokamak-pm]

Code Review: PR #8326 -- feat: add Requesty as a remote model provider

Overview

This PR adds Requesty (an OpenAI-compatible LLM gateway) as a new remote model provider, closely mirroring the existing OpenRouter provider pattern. The changes span 10 files across the web-app source and docs.

---

Correctness

Provider entry (providers.ts) -- Correctly structured and mirrors the existing OpenRouter entry. Base URL https://router.requesty.ai/v1 is reasonable for an OpenAI-compatible endpoint. No models pre-seeded (empty array), which is fine since the models.ts entry sets models: true to fetch dynamically.

Capability flags (models.ts) -- Setting all capabilities to true is the same approach used for OpenRouter and is appropriate for a multi-provider gateway that can proxy any model.

Sampling caps (providerCaps.ts) -- The REQUESTY caps object mirrors OPENROUTER exactly (penalties, top_k, min_p, repetition supported; typical_p maybe). This is a reasonable default for a gateway. Correctly registered in BUILTIN_CAPS.

Identification headers (ai-model.ts) -- Sends HTTP-Referer and X-Title headers, same as OpenRouter. This is correct but introduces a second near-identical conditional block. See style notes below.

Logo and display (utils.ts) -- Correctly adds switch cases for both getProviderLogo and getProviderTitle. The SVG placeholder is honest (a generic "R" letter).

Docs -- The requesty.mdx page closely mirrors openrouter.mdx. The _meta.json, manage-models.mdx, and _redirects entries are all correctly wired.

---

Issues & Suggestions

1. Duplicated header logic in ai-model.ts (style / maintainability)

The PR adds a second spread conditional for Requesty headers that is identical to the OpenRouter one:

// OpenRouter identification headers
...(provider.provider === 'openrouter'
  ? { 'HTTP-Referer': 'https://jan.ai', 'X-Title': 'Jan' }
  : {}),
// Requesty identification headers
...(provider.provider === 'requesty'
  ? { 'HTTP-Referer': 'https://jan.ai', 'X-Title': 'Jan' }
  : {}),

This should be consolidated into a single conditional:

...(['openrouter', 'requesty'].includes(provider.provider)
  ? { 'HTTP-Referer': 'https://jan.ai', 'X-Title': 'Jan' }
  : {}),

This prevents the pattern from growing with each new gateway provider. Minor -- not a blocker.

2. Docs: Duplicate heading

The requesty.mdx file has the heading ## Integrate Requesty with Jan appearing twice (lines 26 and 37 of the new file -- same issue exists in openrouter.mdx which it was copied from). While this mirrors the existing OpenRouter doc, the second heading is redundant and should ideally be removed. Cosmetic -- not a blocker.

3. No pre-seeded models

OpenRouter's provider entry pre-seeds two free models (deepseek/deepseek-r1:free and qwen/qwen3-30b-a3b:free). Requesty's entry has models: []. This is fine if Requesty's /v1/models endpoint dynamically returns the full model list; users will see models once they provide an API key. If Requesty has notable free-tier models, consider pre-seeding a couple for discoverability. Not a blocker.

4. requesty.mdx does not include a setup screenshot

The OpenRouter doc has ![OpenRouter](../_assets/provider-openrouter.png). The Requesty doc omits this entirely (author notes they did not run the UI). This is acceptable for now but a screenshot would improve the doc. Not a blocker.

5. Redirect entry may be premature

The _redirects entry maps /docs/remote-models/requesty to the new page. Since Requesty was never a provider before, no one is linking to the old path. This redirect is harmless but technically unnecessary. No action needed.

---

Risks & Regressions

• Low risk. All changes are purely additive -- new constant entries, new switch cases, new doc page. No existing code paths are modified.
• The models: true + REQUESTY caps combination means the app will attempt to call GET /v1/models on Requesty's endpoint when a user enters a key. If Requesty's models endpoint is non-standard, this could fail. The PR author confirmed a live test with POST /chat/completions returning 200, but did not explicitly confirm the /v1/models list endpoint works. Worth confirming.

Missing Tests

No tests are added. This matches the pattern for other provider additions in this repo -- the provider registrations are data-driven constants, and there do not appear to be unit tests for individual provider entries. Acceptable given the codebase norms.

---

Summary

Clean, well-structured addition that follows established patterns. The only substantive code suggestion is consolidating the duplicated header logic in ai-model.ts. All other items are cosmetic or minor.

Recommendation: improve needed