# In 5 Minuten von LiteLLM umziehen Ziehen Sie Ihre Apps mit neuer Basis-URL und neuem Schlüssel von einem LiteLLM-Proxy zu Kaeso um, und übertragen Sie dann den Rest Ihrer config.yaml. Webseite: https://kaeso.app/de/articles/migrate-from-litellm In anderen Sprachen: [English](https://kaeso.app/articles/migrate-from-litellm.md) · [简体中文](https://kaeso.app/zh-CN/articles/migrate-from-litellm.md) Von Kaeso Team · 5 November 2026 Wenn Ihre Apps heute einen LiteLLM-Proxy aufrufen, sprechen sie bereits die API von OpenAI oder von Anthropic. Kaeso spricht beide. Eine App umzuziehen ist deshalb vor allem ein Adresswechsel: eine neue Basis-URL und ein neuer Schlüssel. Ihr Code, Ihr SDK und die Art, wie Sie Antworten streamen, bleiben, wie sie sind. Die fünf Minuten gelten für diesen Wechsel: Kaeso starten, einen Anbieter verbinden und eine App darauf zeigen lassen. Eine lange `config.yaml` zu übertragen dauert länger, deshalb geht die zweite Hälfte dieser Anleitung sie Stück für Stück durch: Modelle, Fallbacks, Schlüssel, Budgets, Caching und Protokolle, auch das, was anders funktioniert, und das Wenige, was Kaeso nicht kann. Lassen Sie LiteLLM laufen, während Sie umziehen. Nichts hier verändert es, und jede App kehrt zurück, indem Sie ihre Basis-URL zurückstellen. ## Bevor Sie beginnen - **Ein Server.** Linux mit Docker Engine und Docker Compose 2.24 oder neuer, 2 vCPUs, 4 GB Arbeitsspeicher und 20 GB Festplatte. Um Kaeso zuerst auf Ihrem eigenen Rechner auszuprobieren, verwenden Sie `localhost` als Domain. - **Eine Domain**, deren DNS-Eintrag auf den Server zeigt, mit offenen Ports 80 und 443, damit das mitgelieferte Caddy ein Zertifikat erhält. - **Ihre Anbieter-Schlüssel.** Die, die LiteLLM heute nutzt; Ihre `config.yaml` nennt sie als `os.environ/OPENAI_API_KEY` und ähnlich. - **Ein SMTP-Server** für Anmeldelinks und Einladungen. Zum Ausprobieren können Sie ihn weglassen. ## Der Wechsel ### Kaeso starten Jedes Release veröffentlicht eine `compose.yaml`, die das Gateway, die Konsole, PostgreSQL, ClickHouse für die Anfrageprotokolle, Valkey und Caddy startet. Laden Sie sie herunter, schreiben Sie die Einstellungen und starten Sie alles: ```bash mkdir -m 700 kaeso && cd kaeso curl -fsSLO https://github.com/logicplanes/kaeso/releases/latest/download/compose.yaml umask 077 cat > .env < master-keys sudo chown 65532:65532 master-keys && sudo chmod 0400 master-keys docker compose up -d --wait docker compose exec gateway kaeso setup-link ``` Der erste Start dauert ein bis zwei Minuten, während die Images geladen werden. Unter Docker Desktop oder Colima führen Sie statt der `chown`-Zeile nur `chmod 0400 master-keys` aus. `KAESO_MAIL_TRANSPORT=log` schreibt E-Mails ins Protokoll des Gateways, statt sie zu senden. Zum Ausprobieren allein genügt das. Bevor Sie jemanden einladen, ersetzen Sie es durch Ihren SMTP-Server ([E-Mail-Einstellungen](https://docs.kaeso.app/de/self-hosting/email)). Ein Name bedeutet hier zweierlei. Der Hauptschlüssel von Kaeso verschlüsselt die Anbieter-Schlüssel, die es speichert; er ist nicht LiteLLMs `master_key`, und nichts ruft damit Modelle auf. Bewahren Sie eine Kopie von `master-keys` sicher auf, getrennt von Ihren Datenbank-Backups. Der letzte Befehl gibt einen Einrichtungslink aus. Öffnen Sie ihn, geben Sie Ihren Namen, Ihre E-Mail-Adresse, ein Passwort und einen Namen für Ihre Organisation ein, und wählen Sie **Kaeso einrichten**. Sie sind jetzt Admin der Instanz und Inhaber der Organisation. ### Einen Anbieter verbinden Öffnen Sie **Anbieter**, wählen Sie **Anbieter-Schlüssel hinzufügen**, wählen Sie den Anbieter und fügen Sie seinen Schlüssel ein. Der erste Schlüssel eines Anbieters wird sein Standard, den jedes Projekt nutzt. Kaeso speichert den Schlüssel verschlüsselt und zeigt ihn nie wieder. Apps sehen ihn nie: Sie rufen Kaeso mit eigenen Schlüsseln auf. ### Ihre Modelle hinzufügen Anfragen können nur Modelle aus dem Katalog eines Projekts nennen, so wie LiteLLM im Wesentlichen nur bedient, was `model_list` nennt. Wählen Sie unter **Projekte** die Option **Projekt erstellen** und benennen Sie es nach Ihrer App. Öffnen Sie dann **Modelle**, wählen Sie **Modelle hinzufügen**, suchen Sie die Modelle, die Ihre App aufruft, etwa `claude-sonnet-5-5` oder `gpt-6-sol`, und fügen Sie sie hinzu. Preise und Kontextfenster geben Sie nicht ein. Sie kommen aus [KPMR](https://kpmr.kaeso.app), der Kaeso Provider & Model Registry, und die Installation hält sie selbst aktuell. ### Einen Schlüssel erstellen Wählen Sie im Projekt **API-Schlüssel**, dann **Schlüssel erstellen**. Benennen Sie ihn nach der App, behalten Sie den Zugriff **Inferenz** und wählen Sie ein Ablaufdatum. Kopieren Sie den Schlüssel, `sk-kso-…`, bevor Sie den Dialog schließen: Kaeso behält nur einen Hash davon. ### Die App auf Kaeso zeigen lassen Ändern Sie die Basis-URL und den Schlüssel. Sonst nichts: ```diff import os from openai import OpenAI client = OpenAI( - base_url="http://litellm.internal:4000", - api_key=os.environ["LITELLM_API_KEY"], + base_url="https://kaeso.example.com/v1", + api_key=os.environ["KAESO_API_KEY"], ) ``` Liest die App ihre Einstellungen aus der Umgebung, ändern Sie stattdessen diese: ```bash OPENAI_BASE_URL=https://kaeso.example.com/v1 OPENAI_API_KEY=sk-kso-… ANTHROPIC_BASE_URL=https://kaeso.example.com ANTHROPIC_API_KEY=sk-kso-… ``` Achten Sie auf das `/v1`. LiteLLM antwortet auf `/chat/completions` ebenso wie auf `/v1/chat/completions`, deshalb zeigen viele Apps mit dem OpenAI-SDK auf den bloßen Host. Kaeso bedient seine Modell-API nur unter `/v1`, der Rest der Domain ist die Konsole. Beim Anthropic-SDK ist es umgekehrt: Es hängt `/v1` selbst an, seine Basis-URL ist also die bloße Domain. | SDK | Basis-URL | Sendet den Schlüssel als | | --- | --- | --- | | OpenAI | `https://kaeso.example.com/v1` | `Authorization: Bearer` | | Anthropic | `https://kaeso.example.com` | `x-api-key` oder `Authorization: Bearer` | Senden Sie eine Anfrage. Jede Antwort trägt einen Header `kaeso-request-id`, und die **Anfrageprotokolle** des Projekts zeigen die Anfrage wenige Sekunden später mit Status, Token, Kosten und Zeiten. Das ist der Wechsel. Wie bei LiteLLM erreicht jedes SDK jedes Chatmodell, das OpenAI-SDK kann also Claude aufrufen. Sendet die App ein Feld, das der Anbieter des Modells nicht annimmt, lässt Kaeso es nicht stillschweigend fallen: Es lehnt die Anfrage mit einem Fehler ab, der das Feld nennt, damit keine Einstellung unbemerkt verloren geht. ### Claude Code und Codex Coding-Tools sind Apps wie alle anderen. Für Claude Code ändern Sie zwei Werte in `~/.claude/settings.json`: ```json { "env": { "ANTHROPIC_BASE_URL": "https://kaeso.example.com", "ANTHROPIC_AUTH_TOKEN": "sk-kso-…" } } ``` Claude Code ruft ein Opus-, ein Sonnet- und ein Haiku-Modell auf, das letzte für Hintergrundaufgaben, also müssen alle drei im Katalog des Projekts stehen. `ANTHROPIC_DEFAULT_OPUS_MODEL`, `ANTHROPIC_DEFAULT_SONNET_MODEL` und `ANTHROPIC_DEFAULT_HAIKU_MODEL` legen fest, welche, und können auch einen Alias nennen. Für Codex fügen Sie Kaeso als Modellanbieter hinzu, mit `base_url = "https://kaeso.example.com/v1"` und `wire_api = "responses"`. [Coding-Tools](https://docs.kaeso.app/de/get-started/coding-tools) zeigt beide Dateien vollständig. ## Ihre config.yaml, Zeile für Zeile Hier eine LiteLLM-Konfiguration, wie viele Teams sie betreiben: drei Modelle, eines davon unter eigenem Namen, Fallbacks, Wiederholungen, ein Redis-Cache und eine Datenbank für Schlüssel und Ausgaben. ```yaml model_list: - model_name: claude-sonnet-5-5 litellm_params: model: anthropic/claude-sonnet-5-5 api_key: os.environ/ANTHROPIC_API_KEY - model_name: gpt-6-sol litellm_params: model: openai/gpt-6-sol api_key: os.environ/OPENAI_API_KEY - model_name: fast litellm_params: model: openai/gpt-5.4-mini api_key: os.environ/OPENAI_API_KEY litellm_settings: num_retries: 2 fallbacks: [{"claude-sonnet-5-5": ["gpt-6-sol"]}] context_window_fallbacks: [{"fast": ["claude-sonnet-5-5"]}] cache: true cache_params: {type: redis} general_settings: master_key: os.environ/LITELLM_MASTER_KEY database_url: os.environ/DATABASE_URL ``` In Kaeso steht nichts davon in einer Datei. Sie stellen es in der Konsole ein oder per Skript über die Platform API, und das Audit-Log hält jede Änderung fest. | In der config.yaml | In Kaeso | | --- | --- | | `api_key: os.environ/…` | Ein Anbieter-Schlüssel unter **Anbieter**, verschlüsselt gespeichert | | `model_list` | Der Katalog des Projekts unter **Modelle** | | `model_name: claude-sonnet-5-5` | Das Modell selbst: Apps senden weiter denselben Namen | | `model_name: fast` | Ein Alias namens `fast` | | `fallbacks`, `context_window_fallbacks` | Die Route des Alias, mit Fallbacks | | `num_retries` | Die eigenen Wiederholungen des SDK | | `cache: true` | Der Antwort-Cache des Projekts | | `master_key` | Konsolenkonten für Menschen, Plattform-Schlüssel für Skripte | | `database_url`, Redis | PostgreSQL, ClickHouse und Valkey aus der `compose.yaml` | | Virtuelle Schlüssel | API-Schlüssel, `sk-kso-…`, einer pro App | | Teams | Projekte | | `max_budget`, `tpm_limit`, `rpm_limit` | Limits für ein Projekt, ein Mitglied oder einen Schlüssel | Die folgenden Abschnitte nehmen sich diese Punkte einzeln vor. ## Modelle und Anbieter ### Namen, die Ihre Apps schon senden Ein `model_name`, der die eigene Modell-ID des Anbieters ist, etwa `claude-sonnet-5-5`, braucht nur das Modell im Katalog. Apps senden ihn weiter. Ein eigener Name, etwa `fast`, wird ein Alias. Öffnen Sie unter **Modelle** den Tab **Aliasse**, wählen Sie **Alias erstellen**, nennen Sie ihn `fast` und wählen Sie `gpt-5.4-mini`. Apps senden `fast`, und Sie können ihn später auf ein anderes Modell legen, ohne die Apps anzufassen. Kaeso liest auch die Form `provider/model`, ein Name wie `anthropic/claude-sonnet-5-5` funktioniert also unverändert. Ein Alias darf allerdings kein `/` enthalten, ein LiteLLM-Name wie `prod/claude` muss sich also in der App ändern. ### Anbieter-Präfixe LiteLLMs Präfix in `litellm_params.model` sagt Ihnen, welchen Anbieter-Schlüssel Sie hinzufügen. Die meisten heißen in Kaeso gleich, einige werden anders geschrieben: | LiteLLM | Kaeso | | --- | --- | | `openai/`, `anthropic/`, `groq/`, `mistral/`, `deepseek/`, `xai/`, `cerebras/`, `openrouter/` | Dieselbe ID | | `together_ai/` | `togetherai` | | `cohere/`, `cohere_chat/` | `cohere` | | `moonshot/` | `moonshotai` | | `dashscope/` | `alibaba`, QwenCloud | | `vercel_ai_gateway/` | `vercel` | Zwei Abkürzungen helfen bei großen Konfigurationen. **Alle aktuellen OpenAI-Modelle hinzufügen**, und derselbe Button für jeden anderen Anbieter, ersetzt einen Platzhalter wie `openai/*`; er fügt die Modelle hinzu, die der Anbieter heute hat, keine, die später erscheinen. Und wenn zwei Anbieter dieselbe Modell-ID bedienen, nennen Sie den, den Sie meinen, etwa `groq/openai/gpt-oss-120b`. ### Preise, die Sie selbst festlegen LiteLLM nimmt `input_cost_per_token` und `output_cost_per_token` in US-Dollar pro Token. Kaesos Preise sind in US-Dollar pro Million Token, multiplizieren Sie also mit einer Million: Aus `0.000003` wird `3`. Öffnen Sie das Sheet des Modells, wählen Sie **Werte anpassen** und tragen Sie den Preis ein. Er gilt nur für dieses Projekt, und **Auf KPMR zurücksetzen** macht ihn rückgängig. ### Selbst betriebene Server Ein Eintrag mit `api_base`, etwa ein vLLM-, Ollama- oder LM-Studio-Server, wird ein eigener Anbieter. Öffnen Sie unter **Anbieter** den Bereich **Eigene Anbieter**, wählen Sie **Eigenen Anbieter hinzufügen**, geben Sie Basis-URL und Schlüssel ein und wählen Sie **Einstellungen erkennen**. Kaeso fragt den Server, wie es ihn aufruft, und listet seine Modelle, wenn Sie sie einem Projekt hinzufügen. Was Ihr Server kostet, kann Kaeso nicht wissen, deshalb tragen Sie die Preise jedes Modells ein; `0` ist richtig für Hardware, die Sie nicht pro Token bezahlen. Steht der Server unter einer privaten Adresse, erlauben Sie sein Netz in `compose.override.yaml` neben der `compose.yaml` und übernehmen es mit `docker compose up -d --wait`: ```yaml services: gateway: environment: KAESO_CUSTOM_PROVIDERS_ALLOWED_NETWORKS: 10.0.0.0/8 ``` ### Anbieter, die Kaeso nicht hat Kaeso hat vierzehn Anbieter eingebaut: Anthropic, Cerebras, Cohere, DeepSeek, Groq, Mistral, Moonshot, Ollama Cloud, OpenAI, OpenRouter, QwenCloud, SpaceX, Together AI und Vercel AI Gateway. Azure OpenAI, Amazon Bedrock, Google Vertex AI und die Gemini API gehören nicht dazu. Nutzt Ihre Konfiguration `azure/`, `bedrock/`, `vertex_ai/` oder `gemini/`, haben Sie zwei Wege. Gemini-Modelle bedienen auch OpenRouter und Vercel AI Gateway, etwa `openrouter/google/gemini-2.5-pro`. Für den Rest behalten Sie LiteLLM hinter Kaeso, wie das Ende dieser Anleitung zeigt. ## Fallbacks, Wiederholungen und Lastverteilung ### Fallbacks In LiteLLM sind Fallbacks eine Liste nach Modellnamen. In Kaeso gehören sie zu einem Alias: Seine Route versucht ein Modell, dann das nächste. Routen kommen mit Kaeso 0.6.0, das beim Schreiben dieses Artikels als Release Candidate vorliegt; unter 0.5.6 zeigt ein Alias auf ein einzelnes Modell. Damit Ihre Apps ihren Namen behalten, geben Sie dem Alias diesen Namen. Ein Alias hat Vorrang vor einem gleichnamigen Modell, und die Liste markiert ihn mit **Verdeckt ein Modell**. Für die Konfiguration oben: 1. Erstellen Sie einen Alias namens `claude-sonnet-5-5`. 2. Wählen Sie unter **Beginnen mit** die Vorlage **Eine Fallback-Kette**. 3. Machen Sie `claude-sonnet-5-5` zum ersten Schritt und `gpt-6-sol` zu seinem Fallback, und wählen Sie dann **Speichern**. Ein Schritt weicht aus, wenn sein Modell nicht verfügbar ist, ein Ratenlimit erreicht oder etwas in der Anfrage nicht annehmen kann, etwa Bilder. Das sind `unavailable`, `limited` und `unsupported`, die Standardgründe. Ein vierter Grund, `rejected`, deckt ab, was `context_window_fallbacks` und `content_policy_fallbacks` taten: Der Anbieter lehnt die Anfrage selbst ab, wegen eines zu langen Kontexts oder ihres Inhalts. Nehmen Sie ihn nur für einen Fallback auf, der annehmen kann, was das erste Modell ablehnte. Für lange Prompts gibt es einen besseren Weg, als auf einen Fehler zu warten. **Beginnen mit** bietet auch **Lange Prompts woanders hin**: eine Bedingung auf die Eingabe-Tokens der Anfrage, damit ein langer Prompt direkt an das Modell mit dem größeren Kontext geht. Jede Antwort auf einen Alias trägt einen Header `kaeso-route`, der jeden versuchten Schritt mit seinem Status auflistet. Das Anfrageprotokoll hält dieselben Schritte unter **Zuerst versucht** fest, und der Tab **Testen** zeigt vor dem Speichern, wohin eine Anfrage ginge. ### Wiederholungen Kaeso sendet jede Anfrage einmal. Die SDKs von OpenAI und Anthropic wiederholen von sich aus, standardmäßig zweimal, wenn ein Fehler es zulässt. Haben Sie sich auf `num_retries` verlassen, um am Proxy zu wiederholen, erhöhen Sie stattdessen `max_retries` im Client (`maxRetries` in TypeScript). ### Lastverteilung Mehrere Einträge unter einem `model_name`, etwa dasselbe Modell mit zwei Schlüsseln, haben keine direkte Entsprechung. Ein Projekt nutzt einen Schlüssel pro Anbieter, und Kaeso bündelt keine Schlüssel und wählt kein Deployment nach Latenz oder Auslastung. Um Arbeit auf mehrere Anbieterkonten zu verteilen, weisen Sie einen Anbieter-Schlüssel mit **Projekten zuweisen** einzelnen Projekten zu. Um Verkehr zwischen Modellen aufzuteilen, nutzen Sie eine Aufteilung in einer Route: Sie schickt jede Anfrage nach Gewicht einen ihrer Zweige hinunter, pro Anfrage, pro Aufrufer oder pro Wert eines Headers. ## Schlüssel, Teams und Budgets ### Neue Schlüssel für jede App LiteLLMs virtuelle Schlüssel kommen nicht mit: Kaeso stellt eigene aus und behält davon nur Hashes. Jede App bekommt einen neuen Schlüssel, und das ist ohnehin die eine Änderung, die Sie an ihr vornehmen. Teams werden Projekte. Jedes Projekt hat seinen eigenen Katalog, eigene Schlüssel, Limits und Protokolle, und Menschen treten ihm mit einer Rolle bei: Admin, Entwickler oder Betrachter. Geben Sie Software ein Dienstkonto statt des Schlüssels einer Person, damit ihre Schlüssel weiter funktionieren, wenn diese Person geht. ### Was aus den Einstellungen eines virtuellen Schlüssels wird | `/key/generate` | Kaeso | | --- | --- | | `key_alias` | Der Name des Schlüssels | | `models` | Die **Modelle** des Schlüssels | | `duration` | Der Ablauf: 1, 7, 30 oder 90 Tage, ein Datum oder nie | | `max_budget` mit `budget_duration` | Ein Ausgabenbudget pro Tag, pro Monat oder insgesamt | | `tpm_limit` | Eine Token-Rate | | `rpm_limit` | Eine Anfragerate | | `team_id` | Das Projekt | | `user_id` | Das Mitglied oder Dienstkonto, dem der Schlüssel gehört | Tage und Monate sind in Kaeso Kalendertage und -monate in UTC, eine `budget_duration` von `30d` wird also ein Monatsbudget und `1d` ein Tagesbudget. Ein Budget ist standardmäßig hart und lehnt Anfragen ab, sobald es aufgebraucht ist; schalten Sie das ab, sendet es nur Warnungen, standardmäßig bei 50, 80 und 100 Prozent. Kaeso hat kein Limit für parallele Anfragen, `max_parallel_requests` hat also keine Entsprechung, ebenso wenig die `metadata` eines Schlüssels: Sein Name ist das, was Anfrageprotokolle und Nutzung zeigen. Limits sind verschachtelt. Das Budget eines Schlüssels kann nicht höher sein als das seines Inhabers, und das eines Inhabers nicht höher als das des Projekts. Ein Team-Budget aus LiteLLM wird also ein Limit für das Projekt. ### Viele Schlüssel auf einmal Bei Dutzenden Schlüsseln nutzen Sie die Platform API. Erstellen Sie unter **Organisationseinstellungen** › **Plattform-Schlüssel** einen Plattform-Schlüssel, und legen Sie dann für jede App ein Dienstkonto und einen Schlüssel mit seinen Limits an: ```bash ORG_URL=https://kaeso.example.com/platform/v1/orgs/org_… PROJECT=proj_… ACCOUNT=$(curl -s "$ORG_URL/projects/$PROJECT/service-accounts" \ -H "Authorization: Bearer $KAESO_PLATFORM_KEY" \ -H "content-type: application/json" \ -d '{"name": "support-bot", "role": "developer"}' | jq -r .id) curl -s "$ORG_URL/projects/$PROJECT/service-accounts/$ACCOUNT/keys" \ -H "Authorization: Bearer $KAESO_PLATFORM_KEY" \ -H "content-type: application/json" \ -d '{ "name": "support-bot", "expires_in_days": 90, "limits": [ {"kind": "spend_budget", "period": "month", "amount": "50"}, {"kind": "request_rate", "period": "minute", "amount": 600} ] }' | jq -r .secret ``` Der letzte Befehl gibt den neuen Schlüssel einmal aus. Speichern Sie ihn dort, wo die App ihn liest. [Mit der Platform API automatisieren](https://docs.kaeso.app/de/api/automation) deckt den Rest ab, vom Hinzufügen von Modellen bis zum Rotieren von Schlüsseln. ## Caching Aus `cache: true` wird ein Schalter pro Projekt. Öffnen Sie die **Einstellungen** des Projekts, schalten Sie unter **Antwort-Cache** die Option **Antworten cachen** ein und wählen Sie, wie lange Antworten bleiben, von 5 Minuten bis 7 Tagen. Der Cache beantwortet eine Anfrage nur, wenn sie mit einer früheren übereinstimmt, verglichen nach der Übersetzung, sodass sich eine OpenAI-App und eine Anthropic-App einen Eintrag teilen können. Er speichert nicht gestreamte Antworten und wird nur innerhalb des Projekts geteilt. Einen semantischen Cache gibt es nicht. Apps steuern ihn pro Anfrage mit dem üblichen Header `Cache-Control`: `no-cache` fragt den Anbieter erneut, `no-store` umgeht den Cache. Jede Antwort sagt in `kaeso-cache`, was geschah, und ein Treffer kostet die Budgets nichts. ## Protokolle und Ausgaben Kaeso hält jede Anfrage selbst fest: Modell, Anbieter, Status, Token, Kosten, Zeiten, Schlüssel und Absender, und standardmäßig auch, was gesendet und zurückgegeben wurde. Die Organisation wählt, wie lange: 90 Tage Metadaten und 30 Tage Inhalte, wenn Sie nichts ändern. Um gar keine Prompts aufzubewahren, wie mit `turn_off_message_logging`, schalten Sie **Anfrageinhalte protokollieren** unter **Organisationseinstellungen** › **Protokollierung** ab, oder nur für ein einzelnes Projekt. Die Nutzung lässt sich nach Tag, Modell, Schlüssel oder Mitglied lesen, in der Konsole oder über die Platform API, und die Anfrageprotokolle lassen sich als CSV oder JSON Lines exportieren. Das Gateway stellt Prometheus-Metriken auf einem eigenen Port für Ihre Dashboards bereit. Kaeso leitet seine Protokolle nicht an fremde Werkzeuge weiter, Callbacks wie Langfuse oder Datadog haben also keine Entsprechung; lesen Sie stattdessen die Protokolle der Platform API oder den Export. Auch die bisherigen Ausgaben ziehen nicht mit um. Kaeso zählt ab der ersten Anfrage, die es bedient. Behalten Sie also einen Dump der LiteLLM-Datenbank, wenn Sie die Historie brauchen. ## LiteLLM für das behalten, was Kaeso nicht kann Kaesos Modell-API umfasst Chat Completions, Responses, Messages, Embeddings, Token-Zählungen und die Liste der Modelle. Sie hat keine Endpunkte für Bilder, Audio, Rerank, Moderation, Dateien oder Batches, keine Durchreich-Routen und keine Guardrails, und sie leitet keine MCP-Server für Ihre Apps weiter. Außerdem lehnt sie Responses-Anfragen ab, die den Anbieter bitten, eine Antwort zu speichern oder fortzusetzen, etwa mit `previous_response_id`; senden Sie jedes Mal die ganze Unterhaltung. Für diese Endpunkte rufen Sie LiteLLM weiter direkt auf; nichts hindert eine App daran, beide zu nutzen. Für einen Anbieter, den Kaeso nicht hat, können Sie einen Schritt weitergehen und LiteLLM als eigenen Anbieter hinter Kaeso stellen: 1. Erstellen Sie in LiteLLM einen virtuellen Schlüssel, beschränkt auf die Modelle, die Kaeso erreichen soll, etwa Ihre Bedrock- und Azure-Einträge. 2. Steht LiteLLM unter einer privaten Adresse, erlauben Sie sein Netz in `compose.override.yaml`, wie für einen selbst betriebenen Server. 3. Wählen Sie in Kaeso **Eigenen Anbieter hinzufügen** mit der Adresse von LiteLLM, etwa `http://10.0.0.12:4000/v1`, und diesem Schlüssel. **Einstellungen erkennen** findet Chat Completions. Setzen Sie die **ID** auf `litellm`. 4. Fügen Sie seine Modelle einem Projekt hinzu und tragen Sie ihre Preise ein. Kaeso rechnet sie zu diesen Preisen ab und hält die Budgets daran. Apps rufen dann LiteLLMs `model_name` mit der ID davor auf, etwa `litellm/bedrock-claude`, oder einen Alias, den Sie danach benennen, über denselben Schlüssel und dieselbe Basis-URL wie jedes andere Modell. Kaesos Schlüssel, Limits und Protokolle gelten für sie wie für jede andere Anfrage. ## Zurückwechseln und abschalten Bis Sie LiteLLM stoppen, ist der Rückweg dieselbe Änderung andersherum: die alte Basis-URL und der alte Schlüssel. Ziehen Sie eine App nach der anderen um und sehen Sie zu, wie ihre Anfragen in Kaesos Anfrageprotokollen erscheinen. Sobald der Verkehr jeder App in Kaeso ankommt und die Protokolle von LiteLLM still werden, ziehen Sie einen letzten Dump seiner Datenbank und stoppen es. Hat ein Teil Ihres Setups in keinen der Abschnitte oben gepasst, [schreiben Sie uns](https://kaeso.app/de/contact). Das hilft zu entscheiden, was Kaeso als Nächstes kann.