Dokumentation

Jan Agent

Jan Agent enthält keine Inferenz-Engine und ruft daher immer einen von dir angegebenen Endpunkt auf. Mit einer einzigen Zeile über jan config set wird Kunavo in ~/.jan/config.toml eingetragen, und der Terminal-Agent kann Claude und GPT mit einem Schlüssel verwenden.

Eine Zeile `jan config set --base-url https://api.kunavo.com/v1` schreibt Kunavo in ~/.jan/config.toml, und die Vorschau-CLI von Jan Agent — ohne eigene Inferenz-Engine — läuft mit diesem Schlüssel.

jan config set — schreibt ~/.jan/config.toml

# Jan Agent is a preview on a nightly channel — check your build first.
jan --version

jan config set \
  --provider kunavo \
  --api-key sk-kn-... \
  --base-url https://api.kunavo.com/v1 \
  --model claude-sonnet-5 \
  --model claude-haiku-4-5 \
  --api-type openai

jan config list   # configured providers as JSON, keys redacted

Die Basis-URL behält ihr /v1 bei beiden Wire-Typen. Jan hängt nur die Route an: Auf der Seite zum Hinzufügen eines Providers steht, dass die Anmeldung „den Schlüssel gegen GET {base_url}/models überprüft“. Auf der Provider-Seite heißt es, dass ein konfigurierter Eintrag beim ersten Öffnen von /model in einer Sitzung nach seinem GET /models abgefragt wird. Alle Basis-URLs in der Dokumentation enden auf /v1 – auch die Anthropic-URL im Beispiel jan cli models list. Daher verwendet auch --api-type anthropic https://api.kunavo.com/v1. Das ist das Gegenteil von Claude Code und den offiziellen Anthropic-SDKs, bei denen derselbe Zusatz zu /v1/v1/messages und einem 404 führt. Ein doppelter Pfad in der Fehlermeldung verrät, welche Konvention gilt.

Jan Agent ist eine Vorschauversion, und das wird auch ausdrücklich angegeben. Im Schnellstart steht, dass das Installationsprogramm unter dev den Kanal agent-nightly verwendet – „rechne mit Builds in Nightly-Qualität“. Es gibt keine getaggte Version, auf die du verweisen kannst. Führe daher jan --version aus und notiere die ausgegebene Zeichenfolge neben dieser Konfiguration: Die unten aufgeführten Flags stammen aus der Dokumentation vom Datum am Ende dieser Seite, und eine Nightly-Version kann einen davon umbenennen. Ein Build aus dem Quellcode (scripts/install-jan-agent.sh --source) aktualisiert sich nicht selbst. So kannst du die Version festhalten.

Diese Konfiguration wurde aus der eigenen Dokumentation von Jan übernommen. Kunavo hat Jan Agent nicht mit seinem Endpunkt ausgeführt – weder eine Sitzung noch einen gestreamten Durchlauf oder einen Tool-Roundtrip; dasselbe gilt für alle Clients dieser Familie. Eine veröffentlichte Einrichtungsseite ist kein Kompatibilitätstest. Halte während des Versuchs den bisher funktionierenden Weg verfügbar und denke daran: jan config unset --provider kunavo genügt, um alles rückgängig zu machen.

Kunavo stellt keine Modelle für Embeddings, Text-to-Speech oder Speech-to-Text bereit. Ein Kunavo-Provider-Eintrag verarbeitet daher ausschließlich Chat. Jan Agent benötigt nichts Weiteres: Sein Gedächtnis liegt als einfache Dateien unter <project>/.jan/agent/memory/ und nicht in einem Vektorspeicher. Im eigenen Ablauf des Agenten ist daher keine zweite Modellart erforderlich.

Noch kein Schlüssel? Erstelle ein Kunavo-Konto, erstelle einen Schlüssel (er beginnt mit sk-kn-) und füge ab $10 Guthaben hinzu – Aufrufe werden aus diesem Guthaben bezahlt, fehlgeschlagene Aufrufe werden nicht berechnet. Das Dashboard öffnet anschließend die Jan Agent-Einrichtung.

Schritt für Schritt

Erstellen Sie unter /app/keys einen Schlüssel und kopieren Sie ihn — er wird nur einmal angezeigt.
Prüfe, was du gerade konfigurierst: jan --version. Jan Desktop enthält ebenfalls eine CLI, die mit jan aufgerufen wird, aber einen anderen Befehlssatz hat. Vergewissere dich daher, dass jan config set --help --base-url aufführt, bevor du mit den übrigen Angaben fortfährst.
Führe die obige Zeile jan config set aus. --provider ist eine selbst gewählte ID und kein Name aus einer festen Liste – im eigenen Beispiel der Dokumentation für lokale Hardware wird --provider local verwendet. --model kann wiederholt werden und ersetzt die vorhandene Liste, statt sie zu ergänzen.
Prüfe mit jan config list (Schlüssel werden ausgeblendet) oder mit jan config path für die Datei selbst, ob die Änderung übernommen wurde. Führe anschließend jan cli models list aus, um zu sehen, was jeder Provider anbietet. Eine manuell eingegebene Modell-ID bleibt erhalten, auch wenn sie nicht mehr vom Endpunkt aufgeführt wird; jan cli models refresh --provider kunavo behandelt dagegen die Liste des Endpunkts als maßgeblich.
Wechsle in ein Projekt und führe jan aus. Wähle anschließend mit /model das Modell aus. Für den ersten Durchlauf empfiehlt sich jan --plan: Der Vorgang ist schreibgeschützt, sodass eine Protokollabweichung auffällt, bevor etwas auf die Festplatte geschrieben wird.
Gib dem Modell eine Aufgabe, bei der es eine Datei bearbeitet. Jan Agent ist ein Agent. Deshalb sollte ein erster Durchlauf Tool-Aufrufe und Streaming überprüfen: An einem Endpunkt, der nur teilweise passt, würden diese Funktionen zuerst fehlschlagen. Eine Begrüßung überprüft weder das eine noch das andere.

Abgeglichen mit Die Provider-Seite von Jan Agent am 21. September 2026. Einstellungen von Drittanbietern können sich ändern; wenn ein Feldname hier nicht mehr mit deiner Ansicht übereinstimmt, ist diese Seite maßgeblich, nicht diese hier.

Dies ist die Kurzfassung. Die vollständige Anleitung – Modellauswahl, Kosten einer tatsächlichen Sitzung und Fehlerszenarien – findest du in der Leitfaden zu Jan-Modellen und API-Kosten, der auch Jan Desktop behandelt.

Vor dem Debugging des Clients prüfen

Eine Anfrage klärt, ob der Fehler am Endpunkt, am Schlüssel oder an der Konfigurationsdatei liegt. Wenn diese Anfrage JSON zurückgibt, funktionieren dieselbe Basis-URL und derselbe Schlüssel in Jan Agent.

# Settles whether a failure is the endpoint, the key, or the client.
curl -sS https://api.kunavo.com/v1/models \
  -H "Authorization: Bearer sk-kn-..."

Welche Modell-ID in das Feld gehört

Jedes Textmodell ist über eine Modell-ID erreichbar – die aktuelle Liste findest du unter GET /v1/models, den Katalog mit Preisen auf der Modellseite. Die Tarife sind USD pro 1 Mio. Token, Eingabe / Ausgabe.

Modell-ID	Kunavo: Ein- und Ausgabe	Wo es in Jan Agent hineinpasst
`claude-sonnet-5`	$1.40 / $7.00	das Standard-Arbeitsmodell – die ID, die unter --model an erster Stelle stehen sollte
`claude-opus-5`	$3.50 / $17.50	ein Plan, bei dem ein Fehler teuer wäre; kombinieren Sie ihn mit jan --plan
`claude-haiku-4-5`	$0.70 / $3.50	günstige Durchläufe: Triage, Zusammenfassungen und der Ablauf, der den ganzen Tag läuft
`gpt-5-6-sol`	$2.00 / $12.00	eine zweite Modellfamilie mit demselben Schlüssel und derselben Basis-URL
`gpt-5-6-terra`	$0.70 / $4.20	Lesen großer Kontextmengen, weiterhin mit dem api-type openai

Die Abrechnung erfolgt pro Token aus einem vorausbezahlten Guthaben ohne Monatsgebühr – siehe Abrechnung. Bei wiederholtem Kontext – dem Großteil dessen, was ein Editor oder Chat-Client sendet – verändert Prompt-Caching die Rechnung stärker als die Modellwahl.

Zwei verschiedene Dinge werden als Jan-API-Schlüssel bezeichnet

Sie stehen in derselben Datei und bedeuten das Gegenteil voneinander. Deshalb kann jan config list für jemanden falsch aussehen, der den anderen Schlüssel erwartet.

Was	Herkunft	Was damit authentifiziert wird
`jan login`	Anmeldung bei Tokamak, dem selbst gehosteten Backend, über die Shell oder mit /login in der Konsole	Ihre eigene Tokamak-Bereitstellung. Jan Agent schreibt den Schlüssel, den es erhält, für Sie in ~/.jan/config.toml
`jan config set --api-key`	Ein Zugangsschlüssel, den Sie bereits für einen Endpunkt besitzen – hier Kunavos sk-kn-Schlüssel	Dieser Endpunkt, der pro Anfrage abgerechnet wird. Um diese Zeile geht es auf dieser Seite

Jan Desktop stellt keines von beidem aus: Es hat kein Konto, also gibt es dort nichts zu generieren. Sein lokaler API-Server erwartet einen Schlüssel, den Sie selbst festlegen – das ist wieder eine dritte Bedeutung und gehört zu einem anderen Host.

Was Jan Desktop weitergibt und wo das endet

Jan Agent liest Anbietereinstellungen aus vier Quellen, wobei jede die darüberliegende überschreibt. Die zweite überrascht viele.

~/.jan/config.toml – die Basis und die einzige Datei, in die jan config set schreibt.
Jan Desktops settings.json – nur zur Übernahme. Sie fügt Anbieter hinzu, die Sie nicht in Agent konfiguriert haben, überschreibt niemals bereits konfigurierte Anbieter und wird nie zurückgeschrieben.
Ein [provider]-Block in der agent.toml eines Projekts – eine ausdrückliche Auswahl pro Projekt, die daher beides übersteuert. Diese Datei wird normalerweise committet; lassen Sie also api_key daraus heraus.
--provider / --api-key in der Befehlszeile oder JAN_API_KEY / <PROVIDER>_API_KEY – am ausdrücklichsten und am flüchtigsten.

Zwei Folgen, die Sie kennen sollten, bevor Sie am falschen Ort nach einem Fehler suchen. jan config list kann keine Anbieter melden, während jan cli models list zahlreiche zurückgibt – letzteres enthält die von Desktop übernommenen Anbieter, die nicht in ~/.jan/config.toml gespeichert sind. Und ein übernommener Anbieter wird nie aktualisiert, weil es hier keinen Eintrag gibt, den man umschreiben könnte: Wenn die Modellliste von Kunavo aktuell bleiben soll, muss Kunavo als eigener jan config set-Eintrag vorhanden sein, wie im obigen Block.

Wenn zwei Anbieter dieselbe Modell-ID anbieten

Kunavo stellt IDs wie claude-sonnet-5 bereit; dasselbe gilt für einen Anbietereintrag, der direkt auf den Hersteller verweist. Jan Agent muss einen davon auswählen, und die dokumentierte Reihenfolge lautet: zuerst eine exakte Übereinstimmung in der models-Liste eines Anbieters, dann ein <provider>/<model>-Präfix, das einen konfigurierten Anbieter benennt. Wenn mehrere dieselbe ID anbieten, gewinnt ein Anbieter mit Zugangsdaten gegenüber einem ansonsten identischen Anbieter ohne Schlüssel. Mit kunavo/claude-sonnet-5 geben Sie also an, welchen Sie meinen. Der Zusatz gilt nur für Jan – er wird vor dem Senden der Anfrage entfernt, da vorgelagerte Anbieter eine Anbieter-ID im Modellnamen zurückweisen.

Derselbe Eintrag direkt in der Konsole

Wenn Sie lieber keine Flags eingeben möchten: Unter /settings > providers verwalten Sie dieselben ~/.jan/config.toml-Einträge, und mit a öffnen Sie ein Formular zum Hinzufügen mit den Feldern name, base url, api key und durch Leerzeichen getrennten models. Das Formular bietet zwei Dinge, die mit den Flags nicht möglich sind: Die Basis-URL muss https:// sein (oder http:// für einen Localhost-Endpunkt), damit ein Schlüssel nie über eine unverschlüsselte Remote-Verbindung gesendet wird – Kunavo ist https://, daher ist das kein Hindernis. Beim Bearbeiten zeigt das API-Schlüsselfeld (unchanged) an und behält den gespeicherten Wert bei, sofern Sie nichts eingeben. Wenn Sie das Feld leeren, wird der Schlüssel gelöscht statt beibehalten.

Häufig gestellte Fragen

Wie richte ich Jan Agent auf einen benutzerdefinierten API-Endpunkt aus?

Mit einem Befehl: jan config set --provider <id> --api-key <key> --base-url <url> --model <model> --api-type openai. Die Anbieter-ID legen Sie selbst fest; sie muss nicht aus einer festen Liste stammen. --model kann wiederholt angegeben werden und ersetzt die vorhandene Liste. --api-type ist standardmäßig OpenAI-kompatibel und kann daher bei einem OpenAI-kompatiblen Endpunkt weggelassen werden. Der Eintrag wird in ~/.jan/config.toml geschrieben, den Sie auch über /settings > providers in der Konsole bearbeiten können. Laut Jans eigener Anleitung zum Hinzufügen eines Anbieters benötigt ein einfacher OpenAI-kompatibler Endpunkt überhaupt keinen Code, sondern nur diese Konfiguration.

Muss die Basis-URL von Jan Agent auf /v1 enden?

Ja, auch beim Anthropic-Protokolltyp. Jan hängt nur den Routenpfad an: Auf der Anleitung zum Hinzufügen eines Anbieters steht, dass die Anmeldung den Schlüssel mit GET {base_url}/models validiert. Auf der Anbieterseite steht, dass ein konfigurierter Eintrag beim ersten Öffnen von /model in einer Sitzung mit GET /models abgefragt wird. Da der angehängte Pfad /models und nicht /v1/models lautet, muss die gespeicherte Basis-URL bereits auf dem /v1-Stamm liegen – für Kunavo also https://api.kunavo.com/v1. Jede in Jans Dokumentation angegebene Basis-URL endet auf dieselbe Weise, auch der Anthropic-Eintrag im Beispiel für jan cli models list. Das Gegenteil gilt für Claude Code und die offiziellen Anthropic-SDKs: Dort führt das Anhängen von /v1 zu /v1/v1/messages und einem 404-Fehler.

Was ist der Unterschied zwischen jan login und jan config set --api-key?

Damit werden unterschiedliche Dinge authentifiziert. jan login meldet Sie bei Tokamak, dem selbst gehosteten Backend, an und speichert den zurückgegebenen Schlüssel in ~/.jan/config.toml – die Anmeldung erfolgt bei Ihrer eigenen Bereitstellung. jan config set --api-key speichert Zugangsdaten, die Sie bereits für einen Endpunkt besitzen; so verwenden Sie einen Drittanbieter wie Kunavo. Jan Desktop selbst stellt keines davon aus, da es kein Konto hat, von dem eines ausgestellt werden könnte. Der Schlüssel, den sein lokaler API-Server verlangt, ist eine Zeichenfolge, die Sie selbst festlegen – also wieder eine dritte Bedeutung dieses Begriffs.

Warum zeigt jan config list nichts an, während jan cli models list Modelle anzeigt?

Weil die beiden Befehle unterschiedliche Mengen auslesen. jan config list zeigt nur an, was in ~/.jan/config.toml gespeichert ist, während jan cli models list auch die von Jan Desktop übernommenen Anbieter umfasst, die dort nicht gespeichert sind. Jans Dokumentation weist ausdrücklich darauf hin. Praktisch bedeutet das, dass ein übernommener Anbieter nie aktualisiert wird – es gibt keinen Eintrag, den man umschreiben könnte. Wenn die Modellliste eines Anbieters aktuell bleiben soll, fügen Sie ihn zunächst mit jan config set hinzu.

Kann Jan Agent Claude-Modelle ohne ein Anthropic-Konto ausführen?

Ja. Jan Agent enthält keine Inferenz-Engine. Ein Modell läuft daher immer an dem Endpunkt, den Sie konfigurieren, und --api-type bezeichnet das Protokoll und nicht den Anbieter. Eine Claude-ID wird an der von Ihnen festgelegten Basis-URL aufgelöst; die Zugangsdaten, die Sie verwenden, gehören also zu diesem Endpunkt. Kunavo stellt Claude- und GPT-IDs mit einem Schlüssel über seine OpenAI-kompatible Schnittstelle bereit. Diese Konfiguration wurde anhand von Jans eigener Dokumentation erstellt und nicht durch einen Test mit dem Client. Jan Agent ist außerdem eine Vorschauversion im Nightly-Kanal. Prüfen Sie daher mit jan --version, ob die Flags für den von Ihnen verwendeten Build gelten.

Jan Agent gibt bei jeder Anfrage einen 404-Fehler zurück. Was ist falsch?

Fast immer ist die Basis-URL das Problem. Fehlt /v1, fragt Jan am Ursprung /models und /chat/completions ab; das führt zu einem 404-Fehler statt zu einem Authentifizierungsfehler. Ein doppeltes /v1/v1 in der Fehlermeldung bedeutet, dass das Suffix an eine Basis-URL angehängt wurde, die es bereits enthielt. Prüfen Sie den Endpunkt zunächst außerhalb des Clients mit einem einfachen curl-Aufruf von GET /v1/models und demselben Schlüssel: Eine JSON-Antwort bedeutet, dass Endpunkt und Schlüssel in Ordnung sind und der konfigurierte Eintrag das Problem ist; 401 weist auf ein Problem mit dem Schlüssel hin, 404 auf ein Problem mit der URL. Prüfen Sie anschließend jan config path und lesen Sie den gespeicherten base_url-Wert direkt aus.