Neuer OpenAI-kompatibler Provider mit eigener Basis-URL - #9
Open
skerbis wants to merge 2 commits into
Open
Conversation
Service::getPlatform() built the Ollama platform from base_url only, even though the profile's api_key column exists and Symfony AI's Ollama\PlatformFactory::create() already accepts an optional API key as its second argument (applied as auth_bearer on the HTTP client). This made it impossible to point a profile at an externally reachable or reverse-proxy-secured Ollama server. Now passes the stored api_key through (empty string treated as none, same as an unsecured local instance). Unhides the API key field for Ollama in the profile form and clarifies both language files. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neither the existing "openai" provider (hardcoded to api.openai.com,
no base_url override, and targets the newer /v1/responses API) nor
"ollama" (native Ollama /api/chat protocol) work against self-hosted
gateways that only expose the classic OpenAI Chat Completions API
(Open WebUI, LiteLLM, vLLM, LM Studio, text-generation-webui, ...).
Adds a new "openai_compatible" provider: custom base_url + optional
Bearer token, POSTs to {base_url}/chat/completions, parses
choices[0].message.content. Reuses Symfony AI's Contract::create()
without additional normalizers — the base message/image normalizers
already produce the classic {messages:[...], model} / {type:
"image_url", image_url:{url:...}} shape needed here, so no custom
Contract subclass or payload building was necessary; only a
ModelClient, ResultConverter and ModelCatalog (accepts any model
name, no fixed catalog) were added under lib/Bridge/OpenAiCompatible.
Also includes the Ollama API-key passthrough fix from the previous,
now-superseded PR (Service::getPlatform() never forwarded api_key to
OllamaFactory::create(), even though it accepts one; the field was
also hidden for Ollama in the profile form).
vendor/composer/autoload_{classmap,static}.php regenerated via
`composer dump-autoload -o` per this repo's documented workflow.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This was referenced Sep 3, 2026
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.
Hintergrund
Ich betreibe einen selbstgehosteten KI-Server (Open WebUI vor Ollama), extern erreichbar und per Bearer-Token abgesichert. Weder der bestehende "OpenAI"-Provider (fest auf
api.openai.comverdrahtet, kein Basis-URL-Override, zielt zudem auf die neuere/v1/responses-API) noch "Ollama" (natives/api/chat-Protokoll) funktionieren gegen einen solchen Server – nur dessen klassische OpenAI-Chat-Completions-kompatible API unter/v1/...ist erreichbar. Das betrifft nicht nur Open WebUI, sondern auch LiteLLM, vLLM, LM Studio, text-generation-webui und ähnliche Setups – ein häufiger Anwendungsfall beim Selbsthosten.Änderungen
{base_url}/chat/completions, liestchoices[0].message.content. Neue Klassen unterlib/Bridge/OpenAiCompatible/(ModelClient,ResultConverter,ModelCatalog– akzeptiert beliebige Modellnamen, kein fester Katalog wie bei Ollama nötig, da selbstgehostete Server beliebige Modellnamen haben können).Contract::create()ohne zusätzliche Normalizer – die Basis-Normalizer für Nachrichten/Bilder erzeugen bereits exakt das klassische{messages:[...], model}- bzw.{type:"image_url", image_url:{url:...}}-Format, keine eigene Contract-Klasse nötig.Service::getPlatform()gab den API-Key nie anOllamaFactory::create()weiter, obwohl die Bibliothek das unterstützt; Feld war für Ollama in der UI zudem ausgeblendet).vendor/composer/autoload_{classmap,static}.phppercomposer dump-autoload -oneu erzeugt (laut CLAUDE.md dieses Repos der dokumentierte Workflow nach Klassen-Änderungen inlib/).Testplan
php -lauf allen geänderten/neuen PHP-Dateiennode --check assets/profiles.jscurl-Test vonPOST /v1/chat/completionsmit Bearer-Token bestätigt Antwort vom Modell (HTTP 200, echter Content) – das native Ollama-/api/chatliefert dort dagegen nur die Weboberfläche/405.🤖 Generated with Claude Code