OpenChamber + LiteLLM: Multi-run mit Budget und EU-Routing

Mit LiteLLM als Gateway zwischen OpenCode und den Modellanbietern wird OpenChamber teamfähig: ein Schlüssel pro Person oder Projekt, feste Budgets für Multi-run und eine zentrale Regel, welche Anbieter überhaupt Code zu sehen bekommen.

In meinem Beitrag OpenChamber: KI-Coding-Agenten steuern und prüfen ging es darum, wie OpenChamber Agenten sichtbar macht und Ergebnisse prüfbar. Sobald mehr als eine Person damit arbeitet, stellen sich drei Fragen: Wer behält die Kosten im Blick, wenn eine Aufgabe parallel an fünf Modelle geht? Wo liegen die API-Schlüssel? Und wie stellt man sicher, dass Quellcode nur bei freigegebenen Anbietern landet?

Die Antwort ist eine zusätzliche Schicht: LiteLLM. Dieser Beitrag zeigt, wie Sie beides kombinieren, und zwar in drei Schritten auf eigener Infrastruktur.

Was ist LiteLLM?

LiteLLM ist ein Open-Source-Gateway von BerriAI. Es stellt eine einheitliche, OpenAI-kompatible Schnittstelle bereit und leitet Anfragen an über 100 Anbieter weiter: Anthropic, OpenAI, Azure OpenAI, AWS Bedrock, Google Vertex AI, Mistral, aber auch selbst betriebene Modelle über Ollama oder vLLM.

Für den Einsatz mit OpenChamber sind vor allem diese Funktionen interessant:

Virtual Keys: Nutzer und Projekte erhalten eigene Schlüssel. Die echten Anbieter-Schlüssel bleiben auf dem Gateway.
Budgets und Rate-Limits: Pro Schlüssel, Team oder Projekt lassen sich Ausgabegrenzen und Anfragelimits festlegen.
Modell-Aliase und Fallbacks: Ein stabiler Name wie coding-default kann bei Ausfällen oder Limits automatisch auf ein anderes Modell umschwenken.
Kosten- und Nutzungsprotokoll: Jede Anfrage wird einem Schlüssel zugeordnet und mit Kosten erfasst.

Warum LiteLLM vor OpenChamber gehört

OpenChamber erzeugt selbst keinen Code. Die gesamte Inferenz läuft über die Provider, die in OpenCode eingerichtet sind. Genau dort setzt LiteLLM an: Es wird in OpenCode als ein einziger Provider eingetragen, und OpenChamber zeigt die dahinterliegenden Modelle automatisch an. An OpenChamber selbst ändert sich nichts.

Der Nutzen zeigt sich besonders bei Multi-run. Wer eine Aufgabe an fünf Modelle gleichzeitig schickt, verbraucht ungefähr fünfmal so viele Tokens. Ohne Gateway sind diese Kosten auf mehrere Anbieterkonten verteilt und erst auf der Monatsrechnung sichtbar. Mit LiteLLM greift eine feste Obergrenze, bevor es teuer wird.

Die Architektur: eine Schicht mehr, viel mehr Kontrolle

Eine Anfrage aus OpenChamber läuft künftig durch vier Stationen:

OpenChamber ist die Oberfläche: Sessions, Multi-run, Review.
OpenCode ist der Agent. Er kennt nur einen Provider namens LiteLLM und einen Virtual Key.
LiteLLM prüft den Schlüssel, das Budget und die erlaubten Modelle, protokolliert die Anfrage und wählt den Zielanbieter.
Der Modellanbieter (Cloud oder eigener Server) beantwortet die Anfrage.

Am besten laufen OpenChamber, OpenCode und LiteLLM auf demselben Server oder im selben internen Netz. LiteLLM muss nicht aus dem Internet erreichbar sein.

Schritt 1: LiteLLM als Docker-Stack betreiben

LiteLLM läuft als Container, für Virtual Keys und Kostenprotokoll zusammen mit einer PostgreSQL-Datenbank. Der folgende Stack lässt sich direkt mit Docker Compose oder als Stack in Portainer einsetzen:

services:
  litellm:
    image: ghcr.io/berriai/litellm:main-stable   # in Produktion auf eine feste Version pinnen
    command: ["--config", "/app/config.yaml", "--port", "4000"]
    volumes:
      - ./config.yaml:/app/config.yaml:ro
    environment:
      LITELLM_MASTER_KEY: ${LITELLM_MASTER_KEY}   # beginnt mit sk-
      LITELLM_SALT_KEY: ${LITELLM_SALT_KEY}       # verschlüsselt gespeicherte Anbieter-Keys
      DATABASE_URL: postgresql://litellm:${DB_PASSWORD}@db:5432/litellm
      ANTHROPIC_API_KEY: ${ANTHROPIC_API_KEY}
    ports:
      - "127.0.0.1:4000:4000"   # nur lokal erreichbar
    depends_on: [db]
    restart: unless-stopped

  db:
    image: postgres:16
    environment:
      POSTGRES_USER: litellm
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_DB: litellm
    volumes:
      - litellm-db:/var/lib/postgresql/data
    restart: unless-stopped

volumes:
  litellm-db:

Die Modelle definieren Sie in der config.yaml. Der Wert unter model_name ist der Name, den OpenCode und OpenChamber später sehen:

model_list:
  - model_name: claude-sonnet
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: local-coder
    litellm_params:
      model: ollama/qwen3-coder
      api_base: http://ollama:11434

router_settings:
  fallbacks:
    - claude-sonnet: ["local-coder"]

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  database_url: os.environ/DATABASE_URL

Das Beispiel geht davon aus, dass ein Ollama-Container im selben Docker-Netz läuft. Fällt Claude aus oder ist das Limit erreicht, übernimmt automatisch das lokale Modell.

Nach dem Start erreichen Sie die Admin-Oberfläche unter http://localhost:4000/ui. Ein schneller Test zeigt, ob die Modelle verfügbar sind:

curl http://localhost:4000/v1/models -H "Authorization: Bearer $LITELLM_MASTER_KEY"

Schritt 2: LiteLLM als Provider in OpenCode eintragen

OpenChamber übernimmt die Provider-Konfiguration von OpenCode. Sie tragen LiteLLM deshalb in der OpenCode-Konfiguration ein, und zwar auf dem Rechner, auf dem die OpenChamber-Instanz läuft. Global gilt ~/.config/opencode/opencode.json, projektbezogen eine opencode.json im Repository.

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "litellm": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LiteLLM",
      "options": {
        "baseURL": "http://localhost:4000/v1",
        "apiKey": "{env:LITELLM_API_KEY}"
      },
      "models": {
        "claude-sonnet": {
          "name": "Claude Sonnet (via LiteLLM)",
          "limit": { "context": 200000, "output": 32000 },
          "modalities": { "input": ["text", "image"], "output": ["text"] }
        },
        "local-coder": {
          "name": "Lokales Coding-Modell",
          "limit": { "context": 128000, "output": 16000 }
        }
      }
    }
  }
}

Drei Details entscheiden, ob es auf Anhieb funktioniert:

Die Schlüssel unter models müssen exakt den model_name-Werten aus der LiteLLM-Konfiguration entsprechen.
Die baseURL endet auf /v1. Fehlt das, schlagen alle Anfragen fehl.
Den Virtual Key übergeben Sie als Umgebungsvariable LITELLM_API_KEY. Das passt besser zu einer Server-Instanz als die interaktive Anmeldung mit /connect im Terminal.

Nach einem Neustart von OpenChamber erscheinen die Modelle in der Modellauswahl und stehen auch für Multi-run zur Verfügung.

Schritt 3: Virtual Keys und Budgets für Multi-run

Der Master Key dient nur der Verwaltung. Für die tägliche Arbeit erzeugen Sie pro Person, Team oder Projekt einen eigenen Virtual Key mit festen Grenzen:

curl -X POST http://localhost:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "key_alias": "openchamber-team-web",
    "models": ["claude-sonnet", "local-coder"],
    "max_budget": 150,
    "budget_duration": "30d",
    "rpm_limit": 60
  }'

Dieser Schlüssel darf nur die beiden freigegebenen Modelle nutzen, maximal 150 US-Dollar in 30 Tagen ausgeben und 60 Anfragen pro Minute stellen. Ist das Budget aufgebraucht, lehnt LiteLLM weitere Anfragen ab, statt still weiter Kosten zu erzeugen. Dieselben Einstellungen lassen sich auch in der Admin-Oberfläche setzen.

Für Multi-run bewähren sich zwei Muster:

Eigener Schlüssel für Modellvergleiche: Ein separater Key mit kleinerem Budget für Experimente mit vielen Modellen, ein zweiter für die normale Arbeit mit einem freigegebenen Standardmodell.
Kosten pro Projekt: Ein Key pro Kunden- oder Fachprojekt. So sehen Sie in der Auswertung von LiteLLM direkt, welches Projekt welche Kosten verursacht, und können sie sauber zuordnen.

Datenschutz: Code nur an freigegebene Anbieter

Wer mit OpenChamber arbeitet, schickt Prompts und Quellcode an den gewählten Modellanbieter. Für Behörden und Unternehmen mit sensiblen Fachanwendungen ist das der kritische Punkt. LiteLLM macht daraus eine zentrale, prüfbare Regel: In der config.yaml steht nur, was freigegeben ist. Ein Modell, das dort fehlt, kann niemand im Team auswählen.

Typische Freigaben mit Datenverarbeitung in der EU sehen so aus:

model_list:
  # Azure OpenAI mit Bereitstellung in einer EU-Region
  - model_name: gpt-eu
    litellm_params:
      model: azure/<deployment-name>
      api_base: https://<ressource>.openai.azure.com
      api_key: os.environ/AZURE_API_KEY
      api_version: "<api-version>"

  # Claude über AWS Bedrock in Frankfurt
  - model_name: claude-eu
    litellm_params:
      model: bedrock/<modell-id-aus-der-bedrock-konsole>
      aws_region_name: eu-central-1

  # Eigenes Modell im eigenen Rechenzentrum
  - model_name: local-coder
    litellm_params:
      model: openai/qwen3-coder
      api_base: http://vllm.intern:8000/v1

Die Platzhalter in spitzen Klammern ersetzen Sie durch die Werte aus Ihrem jeweiligen Vertrag. Welche Region und welche Vertragsbedingungen (AVV, Speicherung, Training) im Einzelfall ausreichen, klären Sie mit Ihrer oder Ihrem Datenschutzbeauftragten. Das Gateway sorgt nur dafür, dass die getroffene Entscheidung technisch eingehalten wird.

Prüfen Sie außerdem, was LiteLLM selbst protokolliert. Für die Kostenzuordnung reichen Metadaten wie Schlüssel, Modell und Tokenzahl. Prompt-Inhalte gehören in der Regel nicht in die Datenbank des Gateways.

Worauf Sie achten sollten

Bilder und Screenshots: OpenCode behandelt Modelle eigener OpenAI-kompatibler Provider standardmäßig als reine Textmodelle und entfernt Bilder aus der Anfrage. Für Vision-Modelle tragen Sie modalities wie in Schritt 2 ein. Sonst liefert etwa der integrierte Browser keine Screenshots an das Modell.
Kontextlimits: Ohne limit kennt OpenCode die Kontextgröße nicht und kann lange Sessions nicht sinnvoll zusammenfassen.
Fallbacks und Vision: Steht hinter einem Alias ein Fallback auf ein reines Textmodell, scheitern Anfragen mit Bildern, sobald der Fallback greift.
Kostenanzeige: Bei eigenen Modellnamen kennt OpenChamber unter Umständen keine Preise. Maßgeblich sind dann die Zahlen aus LiteLLM.
Netzwerk: LiteLLM gehört ins interne Netz. Wenn Sie OpenChamber per Tunnel oder Relay freigeben, sollte das Gateway davon nicht betroffen sein.
Updates: Pinnen Sie das LiteLLM-Image auf eine feste Version und aktualisieren Sie bewusst. Das Gateway sieht sämtliche Anbieter-Schlüssel und gehört entsprechend geschützt.

Fazit

OpenChamber macht Agenten sichtbar und Ergebnisse prüfbar. LiteLLM ergänzt die fehlende Steuerung darunter: zentrale Schlüssel, feste Budgets und eine klare Liste freigegebener Modelle. Der Aufwand ist überschaubar: ein zusätzlicher Container, ein Provider-Eintrag in OpenCode, ein paar Virtual Keys. Gerade für Teams, die Multi-run ernsthaft nutzen oder mit sensiblem Code arbeiten, ist diese Schicht der Schritt vom Experiment zum geregelten Betrieb.

Sie möchten OpenChamber mit LiteLLM auf eigener Infrastruktur einführen? sevmatic unterstützt Sie bei Konzeption, Einrichtung und Einführung. Vereinbaren Sie ein kostenloses Erstgespräch.