Summary
Extend BYOK provider support so Weco can accept third-party provider keys such as OpenRouter and Minimax, not just the current built-in providers.
Motivation
Today, overriding an OpenAI-compatible base URL in the CLI is not sufficient because optimization requests are executed through the Weco backend, which owns provider dispatch. That means OpenRouter support needs to be implemented as a real provider path server-side rather than as a local client-only base URL tweak.
Requested behavior
- Accept additional BYOK providers such as
openrouter, minimax, and similar router/aggregator providers
- Support provider-specific default models when
--model is omitted
- Allow explicit provider-native model IDs where applicable
- Keep provider validation and docs aligned between CLI and backend
OpenRouter-specific expectation
--api-key openrouter=... should work as a first-class BYOK option
- If
--model is omitted, a sensible OpenRouter default such as openrouter/auto should be supported
- Explicit OpenRouter model IDs should also work
Why this matters
This would make Weco usable with teams that centralize spend and routing through vendors like OpenRouter instead of maintaining separate provider keys for each lab.
Possible implementation direction
Consider moving BYOK provider support toward an extensible provider registry instead of a fixed allowlist so router-style providers can be added without changing multiple validation paths.
Summary
Extend BYOK provider support so Weco can accept third-party provider keys such as OpenRouter and Minimax, not just the current built-in providers.
Motivation
Today, overriding an OpenAI-compatible base URL in the CLI is not sufficient because optimization requests are executed through the Weco backend, which owns provider dispatch. That means OpenRouter support needs to be implemented as a real provider path server-side rather than as a local client-only base URL tweak.
Requested behavior
openrouter,minimax, and similar router/aggregator providers--modelis omittedOpenRouter-specific expectation
--api-key openrouter=...should work as a first-class BYOK option--modelis omitted, a sensible OpenRouter default such asopenrouter/autoshould be supportedWhy this matters
This would make Weco usable with teams that centralize spend and routing through vendors like OpenRouter instead of maintaining separate provider keys for each lab.
Possible implementation direction
Consider moving BYOK provider support toward an extensible provider registry instead of a fixed allowlist so router-style providers can be added without changing multiple validation paths.