Add Requesty provider (OpenAI-compatible)

[Thibaultjaigu]

This adds a dedicated requesty provider, mirroring the existing OpenRouter provider as closely as possible.

It uses the official Requesty Vercel AI SDK package, @requesty/ai-sdk, whose createRequesty factory is the env aware mirror of createOpenRouter from @openrouter/ai-sdk-provider.

Changes (src/utils/values.ts):

• Import createRequesty from @requesty/ai-sdk.
• Add requesty: "https://router.requesty.ai/v1" to OfficialBaseURLs.
• Add a requesty entry to the provider types array with constructor: createRequesty, mirroring the OpenRouter entry (same commonSettings, same getModelList via openaiGetModelList).
• Add public/svg/requesty.svg for the provider avatar (a simple placeholder mark, easy to swap for an official asset).
• Add @requesty/ai-sdk to package.json dependencies.

Requesty is an OpenAI-compatible LLM gateway, and its model list is served from /v1/models exactly like OpenRouter, so getModelList reuses the same openaiGetModelList helper. Model naming is provider/model, same convention as OpenRouter.

Verification: I tested the endpoint live before opening this. GET https://router.requesty.ai/v1/models returned 200 (572 models), and a chat completion with openai/gpt-4o-mini against https://router.requesty.ai/v1/chat/completions returned 200. I did not run the full Quasar build locally, so the lockfile is not included; it can be regenerated with a normal install.

Docs: https://requesty.ai , https://app.requesty.ai/api-keys

I work at Requesty. This mirrors the existing OpenRouter provider as closely as possible. Happy to adjust wording/placement or close it if it's not a fit.

[NitroRCr]

Since Requesty is OpenAI compatible, are there any features that openai-compatible provider cannot achieve and require the addition of a separate Requesty provider?
For example, OpenRouter was previously added as a separate service provider because openai-compatible did not support reasoning_content (now it does).
I also use Requesty, and it is indeed a good alternative to OpenRouter. But our design is that each service provider option is a different type, rather than adding an option for each OpenAI compatible service provider. Hope you can understand.

[Thibaultjaigu]

That's a fair question, and honestly the answer is no — Requesty is cleanly OpenAI-compatible and doesn't need anything the openai-compatible provider can't already do. reasoning_content, tool calls, and streaming all come through the standard OpenAI shape, so there's no capability gap that would justify a separate provider type the way OpenRouter's older reasoning_content situation did.

Given your design (one type per genuinely-distinct provider, not one per OpenAI-compatible endpoint), I completely understand not wanting to add a dedicated Requesty type. Happy to close this. If it'd be useful I could instead contribute a short docs note showing users how to point the existing openai-compatible option at https://router.requesty.ai/v1 — but only if that fits; otherwise feel free to close it.

I work at Requesty. This mirrored the existing OpenRouter provider as closely as possible. Happy to adjust or close it if it's not a fit.