Skip to content

Support BYOK providers beyond OpenAI/Anthropic/Gemini (OpenRouter, Minimax, etc.) #132

@SebastianBoehler

Description

@SebastianBoehler

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.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions