Problem
API Route users can access its OpenAI-compatible endpoint, but there is no built-in provider entry for discovering and configuring it. I maintain API Route and would like to ask whether you would welcome an optional integration.
CONTRIBUTING.md requires prior maintainer sign-off for AI-assisted changes to provider policy or credentials, so I am opening this issue before preparing a PR.
Proposed solution
Following the recent Cheaper Inference provider in #6761, add a narrowly scoped API Route provider descriptor and setup documentation:
- Base URL:
https://global.api-route.com/v1; use the existing OpenAI-compatible Chat Completions transport.
- Independent, opt-in
API_ROUTE_API_KEY; preserve the existing credential and provider-selection behavior.
- Exact unprefixed model IDs from the API Route catalog, including
deepseek-v4-flash.
- Keep unknown pricing/capability metadata unset until verified, and follow the current route/offering schema instead of copying another provider's model facts.
- Focused descriptor/configuration tests; no changes to global prompts, authentication architecture, sponsorship, or default provider selection.
Would you approve this direction? What endpoint/model discovery evidence or acceptance checks would you require before a PR?
Use case
Someone who already has an API Route key can choose the provider directly and run a model through their own paid account.
Alternatives considered
A documented custom OpenAI-compatible provider recipe would be suitable if you prefer to limit new built-in entries.
Impact
This would reduce setup steps for API Route users. I do not have usage statistics for Codewhale users of the service.
Additional context
Documentation: https://www.api-route.com/docs/overview. API key management: https://www.api-route.com/tokens. Public model catalog: https://www.api-route.com/pricing. The authenticated /v1/models endpoint requires the user's own key.
This issue was prepared with AI assistance; I am responsible for the proposed integration.
Problem
API Route users can access its OpenAI-compatible endpoint, but there is no built-in provider entry for discovering and configuring it. I maintain API Route and would like to ask whether you would welcome an optional integration.
CONTRIBUTING.md requires prior maintainer sign-off for AI-assisted changes to provider policy or credentials, so I am opening this issue before preparing a PR.
Proposed solution
Following the recent Cheaper Inference provider in #6761, add a narrowly scoped API Route provider descriptor and setup documentation:
https://global.api-route.com/v1; use the existing OpenAI-compatible Chat Completions transport.API_ROUTE_API_KEY; preserve the existing credential and provider-selection behavior.deepseek-v4-flash.Would you approve this direction? What endpoint/model discovery evidence or acceptance checks would you require before a PR?
Use case
Someone who already has an API Route key can choose the provider directly and run a model through their own paid account.
Alternatives considered
A documented custom OpenAI-compatible provider recipe would be suitable if you prefer to limit new built-in entries.
Impact
This would reduce setup steps for API Route users. I do not have usage statistics for Codewhale users of the service.
Additional context
Documentation: https://www.api-route.com/docs/overview. API key management: https://www.api-route.com/tokens. Public model catalog: https://www.api-route.com/pricing. The authenticated
/v1/modelsendpoint requires the user's own key.This issue was prepared with AI assistance; I am responsible for the proposed integration.