Documentation

Oh My Pi

Oh My Pi conserve ses fournisseurs dans un seul fichier YAML. Trois lignes sous le nom de votre choix — baseUrl, api, apiKey — et omp achemine les requêtes vers Claude et GPT à l’aide d’une seule clé, en récupérant la liste des modèles au lieu de vous demander de la saisir.

Un bloc fournisseur dans ~/.omp/agent/models.yml — baseUrl, api, apiKey — dirige Oh My Pi vers Kunavo, et la découverte remplit la liste des modèles depuis GET /v1/models.

~/.omp/agent/models.yml

providers:
  kunavo:
    baseUrl: https://api.kunavo.com/v1
    api: openai-completions
    apiKey: KUNAVO_API_KEY       # an env-var name; literal text also works
    discovery:
      type: openai-models-list   # reads GET /v1/models

# Prefer a fixed list to a discovered one? Drop the discovery block and
# declare ids instead. Omitted metadata defaults to a 128,000-token context
# window and a 16,384-token output limit, so set the real numbers from
# /models when they differ.
#
#     models:
#       - id: claude-sonnet-5
#         name: Claude Sonnet 5
#         contextWindow: ...
#         maxTokens: ...

L’URL de base conserve son suffixe /v1. omp documente baseUrl comme « racine du point de terminaison » et openai-completions comme « complétions de chat compatibles avec OpenAI ». Son propre article de dépannage sur les erreurs 404 indique : « Les URL de base génériques compatibles avec OpenAI se terminent souvent par /v1 ». Tous les exemples de fournisseurs personnalisés des deux pages se terminent de la même façon. « Souvent » est une réserve, pas une garantie — mais Kunavo fournit /v1/chat/completions, donc https://api.kunavo.com/v1 est la racine qui permet de l’atteindre. C’est l’inverse des clients de type Anthropic, qui requièrent l’origine seule.

N’indiquez pas authHeader pour cette route. omp précise que ce paramètre sert à une passerelle qui « a spécifiquement besoin que Authorization: Bearer soit injecté comme en-tête ordinaire », et note que « les clients des fournisseurs standard appliquent déjà leur méthode d’authentification habituelle » — ce que fait le client compatible avec OpenAI, et Kunavo l’accepte. Ajoutez-le uniquement si vous constatez une erreur 401 que le curl ci-dessous ne reproduit pas.

Cette configuration a été consultée dans la documentation d’omp à la date indiquée ci-dessous. Kunavo n’a pas exécuté omp sur son point de terminaison : ni session, ni échange en continu, ni aller-retour d’appel d’outil, ni vérification de l’acheminement. Une page de configuration publiée ne constitue pas un test, et rien ici ne doit être interprété comme tel. Le curl ci-dessous est le point que vous pouvez vérifier en dix secondes ; le reste dépend d’omp.

Kunavo ne fournit aucun modèle d’embeddings, de synthèse vocale ou de reconnaissance vocale ; ce fournisseur ne répond donc qu’aux requêtes de chat. Toute configuration qui transcrit de l’audio ou construit un index vectoriel conserve la clé de fournisseur qu’elle utilise déjà.

Pas encore de clé ? Créez un compte Kunavo, créez une clé (elle commence par sk-kn-) et ajoutez un crédit à partir de 10 $ — les appels sont payés sur ce solde et les appels échoués ne sont pas facturés. Le tableau de bord s’ouvre ensuite sur la configuration Oh My Pi.

Étape par étape

Créez une clé sur /app/keys et copiez-la — elle n’est affichée qu’une seule fois.
Définissez-la comme KUNAVO_API_KEY dans le shell qui démarre omp. omp interprète d’abord apiKey comme le nom d’une variable d’environnement et, si elle est introuvable, utilise le texte littéral comme clé. Une faute de frappe dans le nom de la variable passe donc inaperçue et échoue dès la première requête. Une valeur commençant par ! est exécutée comme commande shell : c’est la méthode utilisée avec 1Password.
Placez le bloc ci-dessus dans ~/.omp/agent/models.yml. L’identifiant du fournisseur — kunavo ici — est à votre choix et devient la première partie de chaque sélecteur.
Exécutez omp models kunavo pour charger le fichier et afficher uniquement ce fournisseur. Une erreur YAML ou de schéma affiche models.yml validation failed ainsi que le champ en cause ; omp models refresh kunavo force une nouvelle requête de découverte au lieu d’utiliser le catalogue en cache.
Vérifiez-le à l’aide d’un sélecteur exact : omp -p --model kunavo/claude-sonnet-5 "Reply with only OK". Ensuite, démarrez omp, saisissez /model et attribuez l’identifiant souhaité à Default — le hub de modèles recharge models.yml à son ouverture. /switch ne modifie que la session en cours.

Vérifié avec Page des fournisseurs d’omp le 21 septembre 2026. Les paramètres tiers évoluent ; si le nom d’un champ ne correspond plus à ce que vous voyez ici, cette page fait autorité, pas celle-ci.

Voici la version courte. Le guide complet — choix du modèle, coût d’une session réelle et modes d’échec — se trouve dans la comparaison entre Oh My Pi et OpenCode.

Vérifiez avant de déboguer le client

Une requête suffit à déterminer si l’échec vient de l’endpoint, de la clé ou du fichier de configuration. Si cette requête renvoie du JSON, la même URL de base et la même clé fonctionnent dans Oh My Pi.

# 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-..."

Quel identifiant de modèle saisir dans le champ

Tous les modèles textuels sont accessibles sous forme d’identifiant de modèle — la liste à jour se trouve sur GET /v1/models, et le catalogue avec les prix sur la page des modèles. Les tarifs sont en USD par million de tokens, entrée / sortie.

Identifiant du modèle	Entrée / sortie sur Kunavo	Où cela s’intègre dans Oh My Pi
`claude-sonnet-5`	$1.40 / $7.00	le rôle par défaut — le modèle utilisé dans la plupart des sessions
`claude-opus-5`	$3.50 / $17.50	le rôle de planification, où un plan erroné coûte plus cher que les jetons
`claude-haiku-4-5`	$0.70 / $3.50	le rôle smol : triage, résumés et appels incessants
`gpt-5-6-sol`	$2.00 / $12.00	un deuxième avis d’une autre famille, avec le même bloc fournisseur

La facturation se fait au token à partir d’un solde prépayé, sans frais mensuels — consultez la facturation. Avec un contexte répété — ce qu’envoient la plupart des éditeurs et clients de chat — la mise en cache des prompts influe davantage sur la facture que le choix du modèle.

Découverte : quel type choisir et quels modèles apparaissent dans le sélecteur

omp propose six valeurs discovery.type et deux semblent convenir à une passerelle. Une seule convient. proxy est documenté pour « un proxy mixte OpenAI/Anthropic dont les lignes de modèles indiquent supported_endpoint_types », et il déduit le protocole de chaque modèle à partir de ce champ. Kunavo ne publie pas GET /v1/models ; avec proxy, chaque ligne utiliserait donc par défaut le api défini au niveau du fournisseur — ou serait exclue si aucun n’est défini. openai-models-list, décrit comme un « point de terminaison GET /v1/models générique compatible avec OpenAI », est le bon choix ; c’est pourquoi le bloc ci-dessus conserve api: openai-completions : selon la règle d’omp, « à l’exception de proxy, la découverte requiert un api au niveau du fournisseur ».

Il y a une conséquence à connaître avant d’ouvrir le sélecteur. La liste des modèles de Kunavo représente l’ensemble du catalogue activé : un fournisseur découvert affiche donc des identifiants d’image, de vidéo et de musique à côté de ceux du chat, alors que le transport de chat ne peut pas les appeler. Kunavo publie context_length pour les lignes de chat — champ qu’utilise la découverte générique d’omp après max_model_len, selon sa documentation sur les modèles — mais l’omet pour les lignes multimédias. Celles-ci apparaissent donc avec la valeur par défaut de 128,000 jetons d’omp, plutôt qu’avec un nombre réel. Pour obtenir un sélecteur court et exact, supprimez le bloc de découverte et déclarez les trois ou quatre identifiants que vous utilisez réellement.

omp peut aussi utiliser anthropic-messages, et Kunavo répond à /v1/messages. Cette page ne fournit pas de bloc de configuration pour cette combinaison : les deux pages citées ici établissent la forme de l’URL de base pour la route compatible avec OpenAI et ne précisent pas comment un /v1 final est traité sur la route compatible avec Anthropic ; or un bloc de configuration doit pouvoir être copié-collé. Si vous choisissez cette voie,disableStrictTools: true est la solution documentée lorsque les appels d’outils échouent avec une erreur 400 sur un point de terminaison compatible avec Anthropic.

Questions fréquentes

Comment ajouter un fournisseur d’API personnalisé à Oh My Pi ?

Tout se passe dans ~/.omp/agent/models.yml. Ajoutez une clé sous `providers:` — vous choisissez son nom, qui devient la partie fournisseur du sélecteur — et renseignez baseUrl, api et apiKey, dans l’ordre utilisé par l’exemple « Add a custom provider » d’omp. Vous pouvez soit répertorier manuellement les modèles sous `models:`, soit ajouter un bloc `discovery:` pour qu’omp les récupère. Exécutez ensuite `omp models <your-provider-id>` pour vérifier que le fichier a été chargé, puis sélectionnez un modèle avec `omp --model <provider>/<model-id>` ou le hub /model pendant une session.

Faut-il ajouter /v1 à la fin de baseUrl dans Oh My Pi ?

Pour un point de terminaison compatible avec OpenAI, oui. omp appelle baseUrl la racine du point de terminaison et ajoute la route correspondant à la famille api déclarée ; avec `api: openai-completions`, il demande donc les complétions de chat sous la racine indiquée. Sa propre note de dépannage sur les erreurs 404 précise que les URL de base génériques compatibles avec OpenAI se terminent souvent par /v1, et tous les exemples de fournisseurs personnalisés de sa documentation le font. Kunavo fournit /v1/chat/completions ; la racine à indiquer est donc https://api.kunavo.com/v1. Sans /v1, vous obtiendrez une erreur 404 ou « unsupported endpoint », et non une erreur d’authentification.

Où Oh My Pi cherche-t-il la clé API, et quelle valeur est prioritaire ?

Une valeur apiKey dans models.yml est résolue en trois étapes : si elle commence par !, elle est exécutée comme commande shell et sa sortie standard, une fois les espaces superflus retirés, est utilisée ; sinon, omp cherche une variable d’environnement portant exactement ce nom et, si elle n’existe pas, traite le texte lui-même comme la clé. Ce dernier recours est le piège : une faute de frappe dans le nom de la variable passe inaperçue et échoue dès la première requête. Dans l’ordre de priorité général, une clé de models.yml est prioritaire sur les identifiants OAuth enregistrés, une règle qu’omp indique avoir définie délibérément ; une clé fournie pour une passerelle n’est donc pas remplacée par une connexion en amont.

Quel type de découverte une passerelle doit-elle utiliser dans omp ?

openai-models-list, et non proxy, sauf si la passerelle indique supported_endpoint_types sur chaque ligne de modèle — ce champ permet à proxy de déterminer si un modèle doit utiliser /v1/messages ou /v1/chat/completions. Sans ce champ, les modèles utilisent l’api défini au niveau du fournisseur ou sont exclus. Le /v1/models de Kunavo ne publie pas ce champ ; le type générique de liste OpenAI est donc le bon choix. omp exige un api au niveau du fournisseur pour tous les types de découverte, à l’exception de proxy. Exécutez `omp models refresh <provider>` pour forcer une nouvelle récupération au lieu d’utiliser le catalogue en cache.

Kunavo a-t-il testé Oh My Pi sur son point de terminaison ?

Non. Ce qui a été vérifié le 21 septembre 2026, c’est la documentation d’omp : les noms et l’ordre des champs, la règle de résolution des clés et les types de découverte en sont tirés ; deux détails ont été vérifiés sur la route /v1/models de Kunavo, plutôt que supposés. Aucune session omp n’a été exécutée ici sur api.kunavo.com et aucune affirmation n’est faite quant à la diffusion en continu, aux aller-retours d’appels d’outils ou à l’acheminement des modèles dans le client. La seule chose qui puisse être vérifiée séparément est le fonctionnement du point de terminaison et de la clé, ce que permet la commande curl de cette page.