Zeit für llm://-Verbindungszeichenfolgen

Modell- und Provider-Konfiguration mit llm://-URLs vereinfachen

Update: Dieser Artikel führte zu einem Internet-Draft für das llm://-URI-Schema und dem ergänzenden llm-strings-npm-Paket. Die Implementierung ist ebenfalls auf GitHub verfügbar.

Erinnert ihr euch an die schlechten alten Zeiten, als das Verbinden mit einer Datenbank bedeutete, einen Sammelsurium-Mix aus Umgebungsvariablen jonglieren zu müssen?

Es war ein Kartenhaus aus empfindlicher Konfiguration. DB_HOST, DB_PORT, DB_USER, DB_PASSWORD, DB_NAME … oder war es DB_USERNAME? Heißt es DB_PASS oder DB_PWD? Brauche ich diesmal die PG_*-Präfixe? Und wo zum Teufel gehört die Timeout-Einstellung hin?

Ein fragiles Kartenhaus, bereit, deinen Production-Build zum Einsturz zu bringen, weil du vergessen hast, HOST großzuschreiben.

Dann hatte jemand die brillante Idee, einfach eine URL¹ zu verwenden:

postgres://user:pass@host:5432/dbname

Eine Zeichenkette. Alles, was du brauchst. Universell parsbar. Portabel. Darf ich sagen … schön?

Warum also behandeln wir LLMs, als wäre es 1999?

Die Explosion der Env-Variablen

Meine .env-Datei sieht gerade aus wie ein Friedhof verlassener API-Keys. OPENAI_API_KEY, ANTHROPIC_API_KEY, MISTRAL_API_KEY, GROQ_API_KEY. Und fangt mir gar nicht erst mit Azure an — dort braucht man einen Endpoint, einen Deployment-Namen, eine API-Version und einen Key, nur um „Hallo“ zu sagen.

Das ist nicht nur hässlich, sondern erzeugt Reibung. Jedes Mal, wenn ich ein Modell austauschen oder einen neuen Provider testen will, schreibe ich Initialisierungscode um, suche die Dokumentation nach anbieterspezifischen Parameternamen ab und füge meiner Umgebungskonfiguration drei weitere Zeilen hinzu.

Was wäre, wenn wir einfach … die Idee mit der DB-URL klauen übernehmen?

LLM-Verbindungszeichenketten

Stell dir vor, du konfigurierst deine gesamte Modellschnittstelle mit einer einzigen Zeile:

llm://api.openai.com/gpt-5.2?reasoning_effort=none&temp=0.7&max_tokens=1500
llm://api.z.ai/glm-4.7?top_p=0.9&cache=true

Anatomie einer LLM-Verbindungszeichenkette

Das Schema ist llm://. Der Host ist die API-Basis-URL des Providers. Der Pfad ist der Modellname. Und Query-Parameter übernehmen all die Laufzeitoptionen, die deinen Code normalerweise zumüllen.

Authentifizierung erforderlich? Na gut, dann kommt sie eben dazu.

Genau wie bei postgres:// können wir die Authentifizierung direkt einbauen:

llm://app-name:sk-proj-123456@api.openai.com/gpt-5.2?reasoning_effort=none&temp=0.7

Hinweis: Ja, Zugangsdaten direkt in URLs zu packen, kann ein Sicherheitsrisiko sein, wenn du sie in öffentliche Logs kopierst. Aber moderne Logging-Dienste erkennen und entfernen solche Muster ziemlich zuverlässig. Und mal ehrlich: Behandelst du deine .env-Datei wirklich besser? Prüfen, bereinigen und mit Vorsicht verwenden.

Ausfallsicherheit? Warum zum Teufel nicht.

Viele Datenbankbibliotheken unterstützen Round-Robin-Failover, indem mehrere Hosts angegeben werden. Warum sollten unsere KI-Agenten nicht genauso zuverlässig sein?

llms://primary.gpt,backup.gpt/gpt-6?temp=0.9

Das s in llms:// ist kein Tippfehler. Es steht für den Plural. Wenn primary.gpt hängt, versucht der Client automatisch backup.gpt erneut. Ganz ohne komplexe Router-Logik.

Eine Zeichenkette mit allem — von deiner Authentifizierung über deinen Endpoint bis zu deinen Hyperparametern.

Alternative Formate

Ich bin nicht mit llm:// verheiratet. Das konkrete Schema ist weniger wichtig als der Standard selbst.

Ich könnte mir eine Welt vorstellen, in der wir aus Gründen der Kürze anbieterspezifische Schemas verwenden und trotzdem die Standardstruktur beibehalten:

ollama://localhost:11434/llama3
vercel://anthropic/sonnet-4.5?temp=0.8&web_search={"maxUses":3}
bedrock://us-west-2.aws/anthropic/sonnet-4.5?temp=0.8&cacheControl=ephemeral

Unabhängig von der genauen Syntax liegen die zentralen Vorteile auf der Hand:

1. Portabilität: Kopiere deine komplette Konfiguration aus einem lokalen Skript in einen Cloud-Worker.
2. CLI-tauglich: Übergib deinen Skripten ein einziges Argument. my-agent --model "llm://..." ist besser als my-agent --model gpt-4 --temp 0.7 --key $KEY --host ....
3. Sprachunabhängig: Jede Programmiersprache hat einen robusten URL-Parser. Validierung, Parsing und Bereinigung gibt es quasi gratis dazu.

Die Datenbankwelt hat Jahrzehnte gebraucht, um das herauszufinden.
Die gute Nachricht: In KI-Zeit gerechnet ist das gerade einmal ungefähr ein halbes Vibe-Jahr her.

Das Urteil

Wir brauchen keinen weiteren komplexen Konfigurationsstandard und auch keine neue YAML-basierte Manifestdatei. Wir müssen einfach das eine Werkzeug verwenden, das im restlichen Internet seit 30 Jahren funktioniert.

Hören wir auf, das Rad neu zu erfinden, und behandeln wir unsere LLM-Verbindungen mit demselben Respekt wie unsere Datenbanken. Deine .env-Datei — und dein Verstand — werden es dir danken.