OpenRouter CLI: Ori, curl, llm und aichat

Wer nach einem OpenRouter CLI sucht, stößt schnell auf zwei sehr unterschiedliche Antworten. OpenRouters offizielles Kommando ori richtet vorhandene Coding-Agents ein und startet sie. Community-Clients bieten dagegen Einzelabfragen, REPL-Chats, JSON-Ausgaben oder einen breiteren Zugriff auf die API. Für eine einfache Shell-Pipeline reichen die OpenRouter-API und curl bereits aus.

Was mit „OpenRouter CLI“ praktisch gemeint ist

„OpenRouter CLI“ bezeichnet nicht den einen universellen offiziellen Terminal-Client. Gemeint sind in der Praxis drei verschiedene Szenarien: einen Agent über OpenRouter starten, die API direkt aus der Shell aufrufen oder ein Terminal-Tool eines Drittanbieters wie llm oder aichat verwenden.

Entscheidend sind Zuständigkeit und Funktionsumfang. OpenRouters ori-Integration und das @openrouter/cli DevTools-Paket sind offiziell, aber keines von beiden ist ein universeller openrouter ask-Client: Das DevTools-Paket konzentriert sich auf einen SDK-Telemetrie-Viewer und eine Statuszeile für Claude Code, während Ori vorhandene Harnesses startet.

Der offizielle Weg: Ori Harness installieren und verwenden

Ori ist OpenRouters offizielles CLI zum Konfigurieren unterstützter Coding-Agent-Harnesses. Das Tool authentifiziert sich bei OpenRouter, übergibt das ausgewählte Modell an den darunterliegenden Agent und lässt dessen gewohnte Befehle und Flags intakt. Claude Code, Codex, OpenCode und die anderen Harnesses werden dadurch nicht ersetzt.

Installiert wird Ori mit dem Befehl aus OpenRouters Ankündigung und Dokumentation:

curl -fsSL https://openrouter.ai/labs/ori/install.sh | bash

Anschließend anmelden und einen Agent starten:

ori login
ori claude
ori codex
ori opencode
ori hermes

Die aktuelle Ori-Dokumentation führt außerdem grok, pi, prime-agent und dsh als unterstützte Befehle auf. ori dsh konfiguriert DeepSeek Harness, startet es aber nicht; danach muss dsh separat ausgeführt werden. Mit ori update lässt sich Ori aktualisieren.

Das Modell wechseln, ohne den Agent auszutauschen

Ori akzeptiert eine OpenRouter-Modell-ID und reicht nicht erkannte Argumente an das zugrunde liegende Harness weiter:

ori claude --model anthropic/claude-sonnet-4.6
ori codex --model openai/gpt-5.2 --full-auto
ori opencode --model openrouter/auto
ori hermes --model openrouter/auto

Die Endpunktdetails unterscheiden sich je nach Agent. OpenRouters Anleitung für Claude Code verwendet beispielsweise die Anthropic-kompatible Basis-URL https://openrouter.ai/api, während OpenAI-kompatible Clients wie Codex https://openrouter.ai/api/v1 nutzen. Ori nimmt einem diese Unterschiede bei der Konfiguration der einzelnen Harnesses teilweise ab.

Ori verwendet browserbasiertes OAuth PKCE. Im Normalfall muss deshalb nicht in jedem Agent ein OpenRouter-API-Key hinterlegt werden. Laut der Ori-Harness-Dokumentation laufen die Anfragen über die normale OpenRouter-Abrechnung und Aktivitätsanzeige; eine separate Ori-Rechnung gibt es nicht. Die Inferenzkosten hängen weiterhin vom ausgewählten Modell und vom verwendeten Harness ab.

Ori ist kein eigenständiger Chat-REPL

Ori ist die richtige Wahl, wenn du bereits mit den Tools, Dateioperationen oder Freigabemodellen eines Agents arbeiten möchtest. Für einen einfachen Prompt, eine strukturierte Antwort oder eine Shell-Pipeline ohne Coding-Agent sind curl, ein direkter Client, llm oder aichat passender.

Diese Abgrenzung ist wichtig, weil OpenRouter Ori offiziell als Kompatibilitäts- und Konfigurationsschicht positioniert. Auch das offizielle @openrouter/cli-Paket sorgt gelegentlich für Verwirrung: Die aktuell dokumentierten Befehle lauten openrouter devtools und openrouter statusline. In der Version-1.0-Linie wurden frühere Proxy-Befehle wie start, stop, restart und code entfernt.

Diese OpenRouter-Clients aus der Community sind interessant

Community-Clients unterscheiden sich vor allem durch die Oberfläche, die sie im Terminal anbieten. Die praktische Entscheidung hängt davon ab, ob du einen interaktiven Picker, vollständigen API-Zugriff, ein kleines Binary, Multi-Modell-Automatisierung oder eine verlässlich maschinenlesbare Ausgabe brauchst.

Bei diesen Angaben handelt es sich um dokumentierte Funktionen, nicht um direkt vergleichbare Performance-Benchmarks.

Der kleinste verlässliche Workflow mit curl und jq

Wenn curl und jq bereits installiert sind, ist die rohe OpenRouter-API der kleinste und transparenteste Weg über das Terminal. Der OpenRouter-Quickstart dokumentiert Bearer-Authentifizierung, den OpenAI-kompatiblen Endpunkt /api/v1/chat/completions, ein model-Feld, ein messages-Array und optionales Streaming.

Key und Modell für die aktuelle Shell-Sitzung setzen:

export OPENROUTER_API_KEY='sk-or-v1-...'
export OR_MODEL='openai/gpt-4o'

Danach einen einzelnen Prompt senden:

curl -sS https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer ${OPENROUTER_API_KEY}" \
  -H "Content-Type: application/json" \
  -d "$(jq -n \
    --arg model "$OR_MODEL" \
    --arg prompt "Explain Unix pipes in three sentences." \
    '{model: $model, messages: [{role: "user", content: $prompt}], stream: false}')" \
  | jq -r '.choices[0].message.content // .error.message'

Verwende für das Modell eine Umgebungsvariable, statt die Modell-ID in jedes Skript zu kopieren. Die offizielle Models API liefert unter anderem id, Kontextlänge, Preise, unterstützte Parameter, Provider-Limits und optionale Benchmark-Metadaten.

Wiederverwendbare Shell-Funktionen bauen

Die folgenden Funktionen halten den Request-Body JSON-sicher, weil jq den Prompt encodiert. orask nimmt ein Argument entgegen, orpipe liest die komplette Standardeingabe als einen Prompt ein.

orask() {
  local prompt="$*"
  local model="${OR_MODEL:?Set OR_MODEL to an OpenRouter model ID}"

  jq -n \
    --arg model "$model" \
    --arg prompt "$prompt" \
    '{model: $model, messages: [{role: "user", content: $prompt}], stream: false}' \
  | curl -sS --fail-with-body \
      https://openrouter.ai/api/v1/chat/completions \
      -H "Authorization: Bearer ${OPENROUTER_API_KEY:?Set OPENROUTER_API_KEY}" \
      -H "Content-Type: application/json" \
      -d @- \
  | jq -r '.choices[0].message.content // .error.message // "Unknown OpenRouter error"'
}

orpipe() {
  orask "$(cat)"
}

Beispiele:

orask "Turn this error message into a likely diagnosis: connection reset by peer"
cat README.md | orpipe

Braucht ein Skript zusätzlich Metadaten, sollte die JSON-Antwort vollständig erhalten bleiben:

orjson() {
  local prompt="$*"
  local model="${OR_MODEL:?Set OR_MODEL to an OpenRouter model ID}"

  jq -n \
    --arg model "$model" \
    --arg prompt "$prompt" \
    '{model: $model, messages: [{role: "user", content: $prompt}], stream: false}' \
  | curl -sS --fail-with-body \
      https://openrouter.ai/api/v1/chat/completions \
      -H "Authorization: Bearer ${OPENROUTER_API_KEY:?Set OPENROUTER_API_KEY}" \
      -H "Content-Type: application/json" \
      -d @-
}

So bleibt das usage-Objekt für die Kostenabrechnung verfügbar. Außerdem lassen sich API-Fehler von einer leeren Modellantwort unterscheiden.

Kompatible Modelle direkt auf der Kommandozeile finden

Ein Modell im Katalog unterstützt nicht automatisch jeden Anfrageparameter. Die OpenRouter Models API kann nach supported_parameters filtern, darunter tools, und nach Preis, Kontext, Durchsatz, Latenz, Popularität oder Aktualität sortieren.

Modelle mit Tool-Unterstützung am günstigen Ende der dokumentierten Sortierung auflisten:

curl -sS -G https://openrouter.ai/api/v1/models \
  --data-urlencode 'supported_parameters=tools' \
  --data-urlencode 'sort=pricing-low-to-high' \
| jq -r '.data[] | [.id, .context_length, .pricing.prompt, .pricing.completion] | @tsv' \
| head -20

Bevor ein Modell in ein produktives Skript wandert, sollte es einzeln geprüft werden. OpenRouter dokumentiert den Detail-Endpunkt für ein Modell als /api/v1/model/{author}/{slug}:

curl -sS \
  "https://openrouter.ai/api/v1/model/${OR_MODEL}" \
| jq '.data | {id, context_length, architecture, pricing, supported_parameters, top_provider}'

Die Werte unter pricing werden pro Token oder Einheit angegeben. Eine rohe Dezimalzahl darf daher nicht ohne Umrechnung als Preis pro Million Dollar verstanden werden. Für den tatsächlichen Verbrauch ist das Feld usage in der Antwort die verlässlichere Quelle.

Batch-Verarbeitung in einer Shell-Pipeline

Ein praktischer Batch-Workflow verwendet eine Prompt-Zeile pro Eingabe und ein JSON-Objekt pro Ergebnis. Das folgende Skript protokolliert den ursprünglichen Prompt, die Antwort, die Nutzungsdaten und ein Fehlerfeld, ohne Modelltext und maschinenlesbare Ausgabe zu vermischen.

prompts.txt anlegen:

Summarize the release notes in one paragraph.
List three security risks in this configuration.
Extract the names and versions from this sentence.

Batch ausführen:

#!/usr/bin/env bash
set -u

: "${OPENROUTER_API_KEY:?Set OPENROUTER_API_KEY}"
: "${OR_MODEL:?Set OR_MODEL}"

while IFS= read -r prompt || [[ -n "$prompt" ]]; do
  [[ -z "$prompt" ]] && continue

  request=$(jq -n \
    --arg model "$OR_MODEL" \
    --arg prompt "$prompt" \
    '{model: $model, messages: [{role: "user", content: $prompt}], stream: false}')

  response=$(curl -sS --fail-with-body \
    https://openrouter.ai/api/v1/chat/completions \
    -H "Authorization: Bearer ${OPENROUTER_API_KEY}" \
    -H "Content-Type: application/json" \
    -d "$request" || true)

  if jq -e '.choices[0].message.content' >/dev/null 2>&1 <<<"$response"; then
    jq -c --arg prompt "$prompt" \
      '{prompt: $prompt, answer: .choices[0].message.content, usage: (.usage // null)}' \
      <<<"$response"
  else
    jq -c --arg prompt "$prompt" \
      '{prompt: $prompt, answer: null, error: (.error.message // "Request failed"), usage: (.usage // null)}' \
      <<<"$response"
  fi
done < prompts.txt > results.jsonl

Das Skript arbeitet sequenziell. Parallelisierung sollte erst dazukommen, wenn Rate-Limits und Budget geprüft sind, denn parallele Anfragen können die Kosten schnell erhöhen. Auf der Preisseite nennt OpenRouter für den kostenlosen Tarif 50 Anfragen pro Tag und für Pay-as-you-go eine Plattformgebühr von 5,5 %. Ein kostenloses Modell bedeutet daher keine unbegrenzte Batch-Kapazität.

Welche Rolle llm und aichat spielen

llm und aichat sind allgemeine Terminal-Workbenches mit OpenRouter-Unterstützung. Sie lohnen sich eher als ein kleiner Wrapper, wenn wiederverwendbare Prompts, Sitzungen, Anhänge, Tools, lokale Modelle oder ein nachvollziehbares Arbeitsprotokoll gefragt sind.

llm-openrouter: die protokollierte und erweiterbare Variante

Zuerst das Basisprogramm llm installieren, anschließend das OpenRouter-Plugin:

llm install llm-openrouter
llm keys set openrouter

Das Plugin verwendet laut Dokumentation OPENROUTER_KEY als Namen der Umgebungsvariable. OpenRouter-Modelle erscheinen unter Namen wie openrouter/anthropic/claude-sonnet-5. Die Modellliste wird eine Stunde lang gecacht und lässt sich so aktualisieren:

llm openrouter refresh
llm models list

Ein normaler Prompt und eine Shell-Pipeline sehen so aus:

llm -m openrouter/anthropic/claude-sonnet-5 \
  "Give me five short names for a pet tarantula"

cat app.py | llm -m openrouter/anthropic/claude-sonnet-5 \
  -s "Review this code for a security bug"

Das Plugin dokumentiert Schemas, Anhänge, Tool-Aufrufe, Reasoning-Optionen, JSON für Provider-Routing, OpenRouter-Webtools und die Prüfung von Keys. Damit liegt es zwischen rohem curl und einem autonomen Coding-Harness. Allerdings kann der Modell-Cache gegenüber dem Live-Katalog veraltet sein.

aichat: das umfassendere Terminal-Tool

aichat ist ein Rust-basiertes CLI, das neben OpenRouter mehr als 20 benannte Provider und OpenAI-kompatible Endpunkte unterstützt. Zum dokumentierten Funktionsumfang gehören der CMD-Modus, ein Chat-REPL, Shell-Hilfe, Sitzungen, Makros, RAG, Function Calling, MCP-Tools, Agents sowie ein lokaler Server mit Endpunkten für Chat, Embeddings und Reranking.

Für OpenRouter wird ein OpenAI-kompatibler Client mit https://openrouter.ai/api/v1 konfiguriert. Die Beispiele des Projekts verwenden die Modellschreibweise openrouter:<model>. Ist das Terminal bereits zur Anwendungsschnittstelle geworden, passt aichat gut. Für einen kleineren und leichter überprüfbaren Request-Pfad sind curl oder llm überschaubarer.

Wenn der Fehler gar kein CLI-Problem ist

Fehler bei OpenRouter-CLIs können an der Shell, am Client, am ausgewählten Modell oder am Konto entstehen. Bevor das Tool gewechselt wird, sollten diese Ebenen getrennt voneinander geprüft werden.

In einer Reddit-Diskussion über OpenCode und Kilo Code schrieb Nutzer u/GrevireDev:

„Both Kilo Code and OpenCode maintain a hard-coded/preloaded list of OpenRouter models instead of dynamically fetching the full catalog.“ — r/openrouter

Nutzer u/DrunkenRobotBipBop wies in einer anderen OpenRouter-Diskussion auf Kosten und Caching hin:

„Take care of how you handle caching in openrouter. Everytime the provider changes, the cache is gone and you are going to pay full price.“ — r/openrouter

Diese Aussagen sind als Hinweise für die Fehlersuche zu verstehen, nicht als Abrechnungsregeln. Kosten sollten anhand der Request-Nutzung, der Provider-Daten und der aktuellen OpenRouter-Preise überprüft werden.

OpenRouter CLI: Häufige Fragen

Hinter der Suchanfrage openrouter cli stehen immer wieder dieselben Fragen zu Einrichtung und Auswahl. Die kurzen Antworten verweisen jeweils auf die passende Ebene: offizieller Launcher, rohe API, Community-Client oder Modellkatalog.

Gibt es ein offizielles OpenRouter CLI?

Ja. OpenRouter dokumentiert offiziell das ori-CLI. Ori ist allerdings ein Launcher und eine Konfigurationsschicht für vorhandene Coding-Harnesses. Das npm-Paket @openrouter/cli ist ein separates DevTools-Werkzeug, während direkte Chat-/API-CLIs wie @aaronjmars/openroutercli aus der Community stammen.

Kann ich OpenRouter im Terminal nutzen, ohne ein CLI zu installieren?

Ja. Für einen einzelnen Prompt genügt eine Bearer-authentifizierte curl-Anfrage an https://openrouter.ai/api/v1/chat/completions. Mit jq lässt sich daraus entweder nur der Text extrahieren oder die vollständige JSON-Antwort für eine Pipeline erhalten.

Welches OpenRouter CLI eignet sich für JSON-Pipelines?

Für ein kleines Skript erzeugt rohes curl die wenigsten versteckten Verhaltensweisen. Für eine breitere Befehlsoberfläche bietet sich ein Client mit dokumentiertem JSON-Modus an, etwa @aaronjmars/openroutercli. Alternativ kann llm verwendet und die benötigten Antwortdaten explizit erhalten werden.

Warum zeigt mein CLI weniger Modelle als die OpenRouter-Website?

Ein Client kann seinen Katalog cachen oder eine vorab geladene Modellliste mitbringen. Vergleiche den Picker mit curl https://openrouter.ai/api/v1/models, aktualisiere den Client-Cache, sofern möglich, und übergib die exakt zurückgelieferte Modell-ID statt eines Anzeigenamens.

Benötigt Ori einen OpenRouter-API-Key?

Laut OpenRouters Ori-Dokumentation verwendet der normale Login-Weg OAuth PKCE. Nutzer müssen daher keinen separaten API-Key erstellen und einfügen. Für rohes curl, llm-openrouter und die meisten Community-Clients werden weiterhin ein Key oder eine eigene Authentifizierungskonfiguration benötigt.

Vor der Automatisierung eines OpenRouter-CLI-Workflows

Rufe vor dem Festlegen eines Modells den Live-Katalog der Models API ab, protokolliere Modell-ID und Antwort-usage und setze ein Budget für Konto oder Key. Das CLI ist nur die Oberfläche: Modell, Provider-Route, Kontextgröße und Kontolimits bei OpenRouter bestimmen weiterhin, ob ein Workflow zuverlässig und bezahlbar bleibt.