Pi

Un bloc fournisseur personnalisé dans ~/.pi/agent/models.json — baseUrl, api et identifiants des modèles — place l’agent de codage terminal Pi d’Earendil sur Claude et GPT avec une seule clé.

{
  "providers": {
    "kunavo": {
      "baseUrl": "https://api.kunavo.com/v1",
      "api": "openai-completions",
      "apiKey": "$KUNAVO_API_KEY",
      "models": [
        {
          "id": "claude-sonnet-5",
          "name": "Claude Sonnet 5",
          "reasoning": true,
          "input": ["text", "image"],
          "contextWindow": 1000000,
          "maxTokens": 128000
        },
        {
          "id": "claude-haiku-4-5",
          "name": "Claude Haiku 4.5",
          "input": ["text", "image"],
          "contextWindow": 200000,
          "maxTokens": 64000
        }
      ]
    }
  }
}

Étape par étape

1. Créez une clé sur /app/keys et copiez-la — elle n’est affichée qu’une seule fois.
2. Définissez-la dans l’environnement sous la forme KUNAVO_API_KEY. Pi résout "$NAME" ou "${NAME}" dans le champ apiKey, ainsi qu’une valeur littérale ou une commande commençant par !command. Utilisez la forme entre accolades lorsqu’un texte littéral suit le nom de la variable.
3. Créez ou modifiez ~/.pi/agent/models.json et collez-y le bloc ci-dessus. Un fournisseur qui n’est pas intégré doit avoir baseUrl et une valeur api au niveau du fournisseur ou du modèle — le code source de Pi refuse de charger le modèle sans ces éléments — et tout le reste est facultatif. L’ouverture de /model recharge le fichier.
4. Lancez pi, exécutez /model et choisissez l’un des identifiants que vous avez déclarés. S’ils ne figurent pas dans la liste, vérifiez la clé avant le JSON — consultez la remarque ci-dessus sur l’ordre de résolution.
5. Donnez-lui une tâche qui lit et modifie un vrai fichier. Pi s’appuie sur les appels d’outils pour presque tout ce qu’il fait ; un premier essai qui touche au système de fichiers vous en apprend donc bien plus qu’une salutation. C’est aussi lors de cet essai qu’apparaîtrait une incompatibilité de streaming ou de schéma d’outil, précisément le type de problème que Kunavo n’a pas testé pour vous.

Vérifié avec Documentation de Pi : choisir un modèle le 1 octobre 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.

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

L’autre option : anthropic-messages

Jusqu’à la mise à jour de sa documentation du 22 septembre 2026, Pi documentait quatre valeurs pour le champ api d’un fournisseur personnalisé : openai-completions, openai-responses, anthropic-messages et google-generative-ai. La page actualisée sur les modèles n’en répertorie aucune : elle affiche openai-completions dans un exemple et décrit le cas comme « un point de terminaison compatible avec OpenAI, Anthropic ou Google ». Le code source de Pi en v0.99.2 définit ce champ comme une chaîne libre et l’envoie à l’une des dix implémentations intégrées correspondantes : les quatre précédentes, plus openai-codex-responses, azure-openai-responses, google-vertex, mistral-conversations, bedrock-converse-stream et pi-messages. Seules les quatre premières ont jamais été documentées pour un fournisseur personnalisé, et aucune des six autres n’a été testée ici ; rien sur cette page n’affirme qu’elles fonctionnent avec un point de terminaison tiers.

anthropic-messages fait partie des quatre valeurs documentées, et Kunavo prend en charge l’interface Anthropic Messages ainsi que l’interface compatible avec OpenAI. Cette route peut donc être configurée. Cette page n’inscrira toutefois pas de base URL dans un bloc prêt à coller : la documentation de Pi n’a jamais établi cette valeur pour cette api. Jusqu’au 22 septembre, elle la présentait de deux manières — https://proxy.example.com/v1 dans un exemple, https://proxy.example.com sans préfixe dans un autre — puis la mise à jour a supprimé les deux sans trancher. Si vous choisissez cette route, faites un essai ; si le premier appel renvoie 404 plutôt que 401, c’est cette ligne qu’il faut modifier.

Trois champs du schéma compat de Pi pour cette api méritent d’être connus avant d’y arriver (source, v0.99.2). La seule règle de la documentation qui s’applique aux trois mérite d’être citée d’abord : les paramètres de compatibilité « doivent décrire des différences vérifiées dans le comportement des requêtes ou des réponses du point de terminaison. Ne les activez pas uniquement parce qu’un point de terminaison annonce une compatibilité avec OpenAI ou Anthropic ».

1. compat.supportsEagerToolInputStreaming — pour un backend qui refuse le streaming anticipé des entrées par outil.
2. compat.supportsStrictTools — indique si le point de terminaison accepte les définitions d’outils au format JSON Schema strict ; un modèle personnalisé n’hérite pas de ce qu’un modèle Anthropic intégré déclare.
3. compat.supportsMidConvoEffort — modification du niveau d’effort de raisonnement en cours de conversation. La prise en charge par ce point de terminaison est une question d’exécution ; Kunavo ne l’a pas vérifiée en lançant quoi que ce soit.

Le bloc openai-completions en haut de cette page évite ces trois paramètres ; c’est pour cette raison, en toute transparence, qu’il vaut mieux commencer par là — et non parce qu’il serait prétendument plus performant.