feat: add Requesty as an OpenAI-compatible provider#2399
Open
Thibaultjaigu wants to merge 1 commit into
Open
Conversation
Requesty is an OpenAI-compatible LLM gateway. This mirrors the existing OpenRouter named-provider wiring 1:1: - llm_wrapper.py / openai_compatible_llm.py: add "requesty" to the provider lists and a base_url branch -> https://router.requesty.ai/v1 - config.py: default model map (openai/gpt-4o-mini), embeddings env vars, dataclass fields, and from_env wiring (REQUESTY_API_KEY fallbacks) - embeddings.py: requesty branch (same /v1 base) + Supported list - docs/llmProviders.json: factual provider entries Tested live against https://router.requesty.ai/v1/chat/completions (model openai/gpt-4o-mini) -> HTTP 200.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Requesty is an OpenAI-compatible LLM gateway. This adds it as a named provider, mirroring the existing OpenRouter named-provider wiring as closely as possible.
What changed
hindsight-api-slim/hindsight_api/engine/llm_wrapper.py— add"requesty"to the factory provider list and thevalid_providerslist, plus a base-URL branch resolving tohttps://router.requesty.ai/v1.hindsight-api-slim/hindsight_api/engine/providers/openai_compatible_llm.py— same three sites (provider list, API-key-required list, base-URL branch).hindsight-api-slim/hindsight_api/config.py— default-model map entry (openai/gpt-4o-mini), Requesty embeddings env-var constants, dataclass fields, andfrom_envwiring (with the same key fallback chain OpenRouter uses:EMBEDDINGS_REQUESTY_API_KEY→REQUESTY_API_KEY→LLM_API_KEY).hindsight-api-slim/hindsight_api/engine/embeddings.py— arequestyembeddings branch (same/v1base, OpenAI-compatible) and theSupported:list string.hindsight-docs/docs/developer/configuration.md+hindsight-docs/src/data/llmProviders.json— factual provider/env entries mirroring the OpenRouter rows.Model naming is
provider/model(e.g.openai/gpt-4o-mini), identical to OpenRouter. No LiteLLM-router internals or reranker config were touched.Tested live
Standalone probe POSTing to
https://router.requesty.ai/v1/chat/completionswithmodel: openai/gpt-4o-mini,max_tokens: 32→ HTTP 200 (response modelgpt-4o-mini-2024-07-18).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.