OpenRouter CLI : Ori, curl, llm et aichat

Quand on cherche un OpenRouter CLI, on tombe en réalité sur deux réponses différentes. La commande officielle ori d’OpenRouter configure et lance des agents de code existants, tandis que les clients communautaires proposent des prompts ponctuels, un chat en REPL, une sortie JSON ou une couverture plus large de l’API. Et si votre besoin se limite à alimenter un pipeline shell, l’API OpenRouter et curl suffisent.

Ce que recouvre vraiment « OpenRouter CLI »

« OpenRouter CLI » ne désigne pas un client universel officiel pour le terminal. L’expression recouvre trois usages distincts : lancer un agent via OpenRouter, appeler directement l’API depuis un shell ou utiliser un atelier de terminal tiers comme llm ou aichat.

La distinction essentielle concerne l’origine et le périmètre des outils. L’intégration ori d’OpenRouter et le package DevTools @openrouter/cli sont officiels, mais aucun des deux ne constitue un client généraliste de type openrouter ask : le package DevTools se concentre sur un visualiseur de télémétrie du SDK et une barre d’état pour Claude Code, tandis qu’Ori lance des agents existants.

La voie officielle : installer et utiliser Ori Harness

Ori est le CLI officiel d’OpenRouter pour configurer les environnements d’agents de code pris en charge. Il s’authentifie auprès d’OpenRouter, transmet le modèle choisi à l’agent sous-jacent et conserve les commandes et options habituelles de cet agent. Il ne remplace donc ni Claude Code, ni Codex, ni OpenCode, ni les autres environnements compatibles.

Installez-le avec la commande indiquée dans l’annonce et le guide OpenRouter :

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

Authentifiez-vous ensuite et lancez un agent :

ori login
ori claude
ori codex
ori opencode
ori hermes

La documentation actuelle d’Ori mentionne également grok, pi, prime-agent et dsh parmi les commandes prises en charge. ori dsh configure DeepSeek Harness, mais ne le démarre pas : exécutez ensuite dsh. La mise à jour d’Ori s’effectue avec ori update.

Choisir un modèle sans changer d’agent

Ori accepte un identifiant de modèle OpenRouter et transmet les arguments qu’il ne reconnaît pas à l’environnement sous-jacent :

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

Les détails de connexion ne sont pas identiques d’un agent à l’autre. Par exemple, les instructions d’OpenRouter pour Claude Code utilisent l’URL de base compatible Anthropic https://openrouter.ai/api, tandis que les clients compatibles OpenAI comme Codex utilisent https://openrouter.ai/api/v1. Ori sert notamment à masquer ces différences de configuration propres à chaque environnement.

Ori utilise OAuth PKCE dans le navigateur : en principe, il n’est donc pas nécessaire de coller une clé API OpenRouter dans chaque agent. La documentation Ori Harness d’OpenRouter précise que les requêtes suivent la facturation et le suivi d’activité standard d’OpenRouter, sans facturation Ori distincte. Le modèle choisi et l’environnement sous-jacent déterminent toutefois toujours le coût de l’inférence.

Ori n’est pas un REPL de chat autonome

Utilisez Ori si vous avez déjà besoin des outils d’un agent, de ses opérations sur les fichiers ou de son système de validation. Préférez curl, un client direct, llm ou aichat pour envoyer un prompt, obtenir une réponse structurée ou construire un pipeline shell sans lancer d’agent de code.

Cette distinction est importante : les supports officiels présentent Ori comme une couche de compatibilité et de configuration. Le package officiel @openrouter/cli entretient une autre confusion. Ses commandes actuellement documentées sont openrouter devtools et openrouter statusline, tandis que sa branche 1.0 a supprimé les anciennes commandes de proxy comme start, stop, restart et code.

Les clients OpenRouter communautaires à connaître

Les clients communautaires se distinguent surtout par l’interface proposée dans le terminal. Le choix dépend de votre besoin : sélecteur interactif, couverture complète de l’API, binaire léger, automatisation multi-modèle ou sortie machine lisible et prévisible.

Il s’agit de fonctionnalités documentées, et non de benchmarks de performances directement comparables.

Le workflow le plus simple et fiable : curl et jq

Si curl et jq sont déjà installés, l’API OpenRouter brute constitue le chemin le plus léger et le plus transparent depuis un terminal. Le Quickstart d’OpenRouter documente l’authentification Bearer, l’endpoint compatible OpenAI /api/v1/chat/completions, le champ model, le tableau messages et la diffusion en continu facultative.

Définissez une clé et un modèle pour la session shell :

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

Envoyez ensuite un prompt :

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'

Utilisez une variable d’environnement pour le modèle plutôt que de recopier son identifiant dans chaque script. L’API officielle des modèles expose notamment id, la longueur du contexte, les tarifs, les paramètres pris en charge, les limites des fournisseurs et, en option, des métadonnées de benchmark.

Encapsuler la requête dans des fonctions shell réutilisables

Ces fonctions gardent un corps JSON valide en laissant jq encoder le prompt. orask prend un argument, tandis que orpipe lit l’intégralité de l’entrée standard comme un seul prompt.

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)"
}

Exemples :

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

Pour les scripts qui ont besoin des métadonnées, conservez le JSON au lieu de n’extraire que le texte :

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 @-
}

L’objet usage de la réponse reste ainsi disponible pour suivre les coûts, et les erreurs d’API peuvent être distinguées d’une réponse vide du modèle.

Trouver les modèles compatibles depuis la ligne de commande

Un modèle présent dans le catalogue ne prend pas forcément en charge tous les paramètres de requête. L’API des modèles d’OpenRouter permet de filtrer selon les supported_parameters, notamment tools, et de trier par tarif, contexte, débit, latence, popularité ou récence.

Listez les modèles compatibles avec les outils en commençant par les moins chers selon l’ordre de tri documenté :

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

Inspectez un modèle avant de l’intégrer à un script de production. OpenRouter documente la route de détail au singulier sous la forme /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}'

Les valeurs de pricing sont exprimées par token ou par unité. Ne les interprétez donc pas comme un tarif en dollars par million sans effectuer la conversion. Le champ de réponse usage est la source la plus sûre pour connaître le nombre de tokens d’entrée et de sortie réellement consommés par une requête.

Traiter des lots dans un pipeline shell

Un workflow par lots pratique consiste à placer un prompt par ligne dans un fichier texte et à produire un objet JSON par résultat. Le script ci-dessous conserve le prompt d’origine, la réponse, l’utilisation et un champ d’erreur, sans mélanger le texte généré par le modèle avec une sortie exploitable par une machine.

Créez prompts.txt :

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

Lancez le traitement par lots :

#!/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

Le script s’exécute de manière séquentielle. N’ajoutez de la concurrence qu’après avoir vérifié les limites de débit et le budget, car les requêtes parallèles peuvent rapidement augmenter les coûts. La page tarifaire d’OpenRouter indique 50 requêtes par jour pour l’offre gratuite et des frais de plateforme de 5,5 % pour le paiement à l’usage : un modèle gratuit ne fournit donc pas une capacité illimitée pour les traitements par lots.

Quelle place pour llm et aichat ?

llm et aichat sont des ateliers de terminal généralistes compatibles avec OpenRouter. Ils deviennent pertinents lorsque vous voulez réutiliser des prompts, conserver des sessions, gérer des pièces jointes et des outils, utiliser des modèles locaux ou garder une trace du travail effectué.

llm-openrouter : l’option extensible avec historique

Commencez par installer la commande de base llm, puis ajoutez le plugin OpenRouter :

llm install llm-openrouter
llm keys set openrouter

Le plugin documente OPENROUTER_KEY comme nom de variable d’environnement. Il expose les modèles OpenRouter sous des noms tels que openrouter/anthropic/claude-sonnet-5, conserve la liste des modèles en cache pendant une heure et permet de la rafraîchir avec :

llm openrouter refresh
llm models list

Un prompt classique et un pipeline shell s’utilisent ainsi :

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"

Le plugin documente les schémas, les pièces jointes, les appels d’outils, les options de raisonnement, le routage des fournisseurs en JSON, les outils web d’OpenRouter et l’inspection des clés. Il se situe entre curl brut et un environnement de code autonome, mais son cache de modèles peut accuser un retard sur le catalogue en direct.

aichat : l’atelier de terminal plus généraliste

aichat est un CLI basé sur Rust qui prend en charge OpenRouter, ainsi que plus de 20 fournisseurs nommés et les endpoints compatibles OpenAI. Sa surface fonctionnelle documentée comprend le mode CMD, un Chat-REPL, l’assistance shell, les sessions, les macros, le RAG, les appels de fonctions, les outils MCP, les agents et un serveur local proposant des endpoints de chat, d’embeddings et de reranking.

Sa configuration OpenRouter repose sur un client compatible OpenAI pointant vers https://openrouter.ai/api/v1, et les exemples du projet utilisent une forme de modèle openrouter:<model>. Choisissez-le lorsque le terminal devient l’interface de votre application ; préférez curl ou llm si vous recherchez un chemin de requête plus léger et plus facile à inspecter.

Diagnostiquer les erreurs qui ressemblent à un problème de CLI

Les erreurs liées à un CLI OpenRouter peuvent apparaître à la jonction entre le shell, le client, le modèle choisi et le compte. Analysez séparément ces différentes couches avant de changer d’outil.

Dans une discussion Reddit consacrée à OpenCode et Kilo Code, l’utilisateur u/GrevireDev écrivait :

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

L’utilisateur u/DrunkenRobotBipBop formulait cette observation sur les coûts et le cache dans une autre discussion OpenRouter :

« 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

Considérez ces remarques comme des pistes de diagnostic, pas comme des règles de facturation ; vérifiez les coûts à partir de l’utilisation de la requête, des données du fournisseur et des tarifs actuels d’OpenRouter.

FAQ sur OpenRouter CLI

Voici les questions qui reviennent le plus souvent derrière la recherche openrouter cli. Les réponses courtes ci-dessous renvoient à la bonne couche : lanceur officiel, API brute, client communautaire ou catalogue de modèles.

Existe-t-il un CLI officiel pour OpenRouter ?

Oui. OpenRouter documente officiellement le CLI ori, mais Ori est une couche de lancement et de configuration pour les environnements d’agents de code existants. Le package npm @openrouter/cli d’OpenRouter est un utilitaire DevTools distinct, tandis que les CLI de chat et d’API directe comme @aaronjmars/openroutercli sont des projets communautaires.

Puis-je utiliser OpenRouter dans un terminal sans installer de CLI ?

Oui. Une requête curl authentifiée avec Bearer vers https://openrouter.ai/api/v1/chat/completions suffit pour envoyer un prompt ponctuel. jq peut ensuite extraire le texte ou conserver le JSON pour l’intégrer à un pipeline.

Quel est le meilleur CLI OpenRouter pour envoyer du JSON dans un pipe ?

Pour un petit script, l’API brute avec curl réduit les comportements implicites au minimum. Pour disposer de davantage de commandes, choisissez un client qui documente un mode JSON, comme @aaronjmars/openroutercli, ou utilisez llm en conservant explicitement les données de réponse dont vous avez besoin.

Pourquoi mon CLI affiche-t-il moins de modèles que le site OpenRouter ?

Le client peut conserver son catalogue en cache ou intégrer une liste de modèles préchargée. Comparez le contenu du sélecteur avec curl https://openrouter.ai/api/v1/models, actualisez le cache lorsque le client le permet et transmettez l’identifiant exact du modèle renvoyé par l’API plutôt que son nom d’affichage.

Ori nécessite-t-il une clé API OpenRouter ?

La documentation Ori d’OpenRouter indique que le parcours de connexion habituel utilise OAuth PKCE : il n’est donc pas nécessaire de créer puis de coller une clé API distincte. En revanche, curl brut, llm-openrouter et la plupart des clients communautaires nécessitent toujours une clé ou leur propre configuration d’authentification.

Avant d’automatiser un workflow OpenRouter CLI

Interrogez l’API des modèles en direct avant d’en figer un, consignez son identifiant ainsi que l’objet usage de la réponse, puis définissez un budget au niveau du compte ou de la clé. Le CLI n’est que la façade : le modèle OpenRouter, la route du fournisseur, la taille du contexte et les limites du compte restent les variables qui déterminent la fiabilité et le coût du workflow.