feat: add Requesty as an opt-in AI provider

[Thibaultjaigu]

Summary

Adds Requesty, an OpenAI compatible LLM gateway, as an optional provider next to OpenRouter. Requesty is not added to the ranked fallback order. It is only used once the user adds a Requesty key. After that, text and vision requests go to REQUESTY_MODEL (default openai/gpt-4o-mini) first, and if that call fails the existing Groq / Gemini / OpenRouter / Ollama chain runs exactly as before. /router-status and the rankings are unchanged.

Changes

• backend/core/model_router.py: REQUESTY_API_KEY / REQUESTY_MODEL loading, requesty in get_available_providers, set/delete key support, _requesty_text / _requesty_vision (same payload as the OpenRouter calls, minus the OpenRouter only route field), plus startup status. REQUESTY_BASE_URL can point at the EU endpoint (https://router.eu.requesty.ai/v1).
• backend/api.py: Requesty entry in GET /settings/ai-providers, accepted by POST/DELETE. The key is checked with GET https://router.requesty.ai/v1/models (a bad key returns 403).
• backend/start.py: optional Requesty key and model prompts in the setup wizard, with the same inline key check.
• config_settings.py, .env.example, config/.api_keys.example, docker-compose.yml, start-docker-prod.sh, reset.py: new env vars and messages.
• superbrain-app: Requesty in the AI Providers screen (label, icon, color, selector, key link) and in the Settings subtitle.
• README, docs/QUICKSTART.md, docs/TECHNICAL_REFERENCE.md: setup notes.
• backend/tests/test_requesty_router.py: checks that Requesty never shows up in the ranked order, is skipped without a key, sends the chosen model when a key is set, and falls back to the normal chain on error.

How to test

REQUESTY_API_KEY=rqsty-...
REQUESTY_MODEL=openai/gpt-4o-mini

Put these in config/.api_keys or the environment (or add the key from the app's AI Providers screen), then save any link. The log shows [REQUESTY] openai/gpt-4o-mini. Any model id listed by https://router.requesty.ai/v1/models works, for example anthropic/claude-sonnet-4-5.

Checks

• pytest tests/test_requesty_router.py tests/test_sync_pagination.py: 5 passed (Python 3.11)
• Syntax check on every touched Python file, bash -n start-docker-prod.sh
• ruff --select F on api.py, model_router.py, start.py: same 21 findings before and after, none new
• Live run through ModelRouter.generate_text and analyze_images with openai/gpt-4o-mini: text and vision both answered by Requesty (HTTP 200). _validate_requesty returned valid for a real key and 403 for a bad one
• App: not built locally. The change only adds string entries to existing maps and the provider list. The git-network-outline icon exists in @expo/vector-icons 15

beta has an OPENROUTER_BASE_URL change in the same files. It does not overlap with these lines, but I can rebase onto beta if you prefer.

Disclosure: I work at Requesty. Happy to adjust anything to match project conventions.

[sidinsearch]

Thanks for the PR! 🙏

After reviewing, I've decided not to merge this and will close it.

Why: Adding individual providers (Requesty, Together.ai, Fireworks, etc.) as hardcoded integrations creates maintenance burden — every new provider requires a new PR touching 15+ files (router, API, settings, docs, app screens, docker, tests).

Better path: I'm going to implement a generic Custom LLM Provider feature instead. Users will be able to paste any OpenAI-compatible endpoint (, , ) in the settings UI once, and it will work for Requesty, Together.ai, Fireworks, vLLM, Ollama remote, or any custom gateway — zero code changes needed.

The implementation is ~2 hours and makes this PR (and all future 'add provider X' PRs) obsolete.

I'll close this PR now, but your work on the validation flow and UI patterns is useful reference for the generic implementation. Thanks again!