Problem

The translate5AI plugin can currently connect to exactly three hardwired LLM backends: OpenAI, Azure OpenAI and translate5 AI (self-hosted open-weights models), registered as fixed service ids in the plugin (OpenAI/Init.php:99-103). There is no way to connect translate5 to an LLM gateway such as OpenRouter or Opper. Gateways aggregate many providers (Anthropic Claude, Google Gemini, Mistral, Meta, DeepSeek, ...) behind one API and one API key, so supporting them would give translate5 users access to a wide range of state-of-the-art models for AI pre-translation and TQE without us building and maintaining one connector per provider.

Technically the gap is small but real. OpenRouter is OpenAI-API-compatible (/v1/chat/completions), and the plugin already proves that "OpenAI-compatible server + Bearer token" works generically: that is exactly how the translate5 AI service is wired. What blocks a gateway today:

• The list of services is hardcoded; server/API key are single global system configs per service (runtimeOptions.plugins.translate5AI.OpenAI.server / .apiToken etc.), with no service entry a gateway could use.
• The engines dropdown for the OpenAI service filters models through the hard regex ^(gpt-[345]|o[134]) (OpenAI/Api/Model.php:102-105), which would discard every gateway model id (e.g. anthropic/claude-sonnet-4.5). The translate5 AI service avoids this by listing all models unfiltered (OpenAI/Llama/Request/Translate5AIModels.php:26-47), which is the template a gateway must follow.
• Model capabilities (context window, max output, reasoning flags) are looked up by name patterns in Config::MODEL_CAPABILITIES (OpenAI/Api/Config.php:76-207); unknown gateway models fall back to conservative defaults, which works but underuses large-context models.

Solution

Add LLM gateways as additional services in the translate5AI plugin, following the existing translate5 AI service as the template (generic OpenAI-compatible path: Bearer auth, <server>/v1 base URL, unfiltered model listing).

• Register one new service per gateway, starting with OpenRouter, analog to Service/Translate5AI.php + LanguageResource/Translate5AI/ResourceConfig.php: new service id, UI name (e.g. "OpenRouter (LLM gateway)"), and system configs runtimeOptions.plugins.translate5AI.OpenRouter.server (default https://openrouter.ai/api), .apiToken, .matchrate via a DB migration, analog to database/009-Llama-integration.sql.
• Reuse the existing non-Azure client path unchanged: ApiClientFactory::createClient() (OpenAI/Api/ApiClientFactory.php:85-115) and ChatRequestFactory already do Bearer auth + /v1/chat/completions; a gateway service must take the same branch as translate5 AI at the ~14 isAzure()/isTranslate5AI() call sites (chat, batch, TQE, status check, engines list, delete).
• Engines/model list: list all gateway models unfiltered, analog to Translate5AIModels, and do NOT route gateway services through the Model::isModern() regex filter (OpenAI/Request/Models.php:113). The service health check via models()->list() (OpenAI/Service/Connector.php:119-144) works as-is on OpenRouter.
• Model capabilities: keep the existing conservative fallbacks (Config::MIN_OUTPUT_TOKENS / MIN_FRAME_SIZE) for unknown models and extend Config::MODEL_CAPABILITIES with patterns for the most relevant gateway models (Claude, Gemini, ...), so context-window-based batch sizing works well for them too.
• Feature scoping: fine-tuning, file upload and Azure deployment management remain unavailable for gateway services (OpenAI/Azure only). Hide/disable those UI parts for gateway resources, analog to how translate5 AI is handled in LanguageResource/Type.php:157-175.
• Opper: support it the same way if it exposes an OpenAI-compatible chat-completions endpoint (to be verified against their API docs during implementation); if it only offers its proprietary task API, it needs its own request implementation and should be split into a follow-up ticket rather than blocking OpenRouter.

Backward compatibility: purely additive. Existing OpenAI / Azure OpenAI / translate5 AI resources and configs are untouched; gateway services simply appear as additional entries in the "add language resource" wizard once their server + API token configs are set (ResourceConfig::isConfigured() pattern, OpenAI/LanguageResource/ResourceConfig.php:68-77).