Oh My Pi et Pi : le fork, les différences et lequel utiliser

Oh My Pi est un fork de Pi, et non un rival apparu à ses côtés : le code a suivi le chemin Pi → Oh My Pi, les deux projets sont toujours actifs aujourd’hui et optimisent désormais des objectifs opposés. Pi est un harness de terminal volontairement minimal que vous étendez en TypeScript. Oh My Pi est issu de la même lignée, reconstruite comme une interface de programmation incluant d’emblée un LSP, un débogueur, des sous-agents et un outil de navigateur. Les deux sont sous licence MIT et leur installation coûte 0 $, si bien que le choix porte sur le workflow, le modèle d’exécution et le format de configuration, et non sur des frais de licence.

Les noms d’abord, car trois d’entre eux se confondent. Pi désigne ici le harness d’agent disponible sur pi.dev, publié par Earendil Works depuis earendil-works/pi. Il ne s’agit ni de Pi d’Inflection AI (pi.ai), ni de la monnaie Pi Network, ni de Raspberry Pi. Oh My Pi désigne l’agent disponible sur omp.sh, issu de can1357/oh-my-pi, dont le binaire est omp — et non les boulangeries de tartes qui dominent une recherche sur cette expression, ni Oh My Zsh ou Oh My Posh malgré l’écho de leurs noms. Et pi-mono n’est pas un troisième produit : c’est l’ancien nom du dépôt de Pi. github.com/badlogic/pi-mono renvoie maintenant par une redirection 301 vers earendil-works/pi, même si des documents tiers utilisent encore l’ancien chemin — la page officielle d’intégration de Pi de DeepSeek se trouve littéralement à l’adresse /agent_integrations/pi_mono/.

Le sens du fork mérite d’être précisé, car les recherches s’effectuent dans les deux sens et la réponse n’est pas symétrique. Le README d’Oh My Pi indique dans son propre en-tête qu’il s’agit d’un « fork de Pi par @mariozechner », avec un lien vers l’URL antérieure au changement de nom. GitHub indique fork: false et parent: null pour ce dépôt, car il s’agit d’un fork de source plutôt que du fork créé avec le bouton — l’API ne vous le signalera donc pas. Le dépôt contient toujours docs/porting-from-pi-mono.md, une checklist de fusion dont le dernier point de synchronisation enregistré est le commit b21b42d, daté du 22 mars 2026. Ce marqueur constitue la seule preuve de divergence disponible de l’extérieur ; cette page ne peut pas confirmer si une synchronisation ultérieure non enregistrée a eu lieu.

Oh My Pi ou Pi : lequel choisir ?

Cinq axes déterminent ce choix — quel que soit le sens par lequel vous l’abordez — et un seul concerne les fonctionnalités.

• Workflow. Choisissez Pi si vous voulez un cœur réduit et prévoyez d’écrire vous-même les éléments manquants. Jusqu’à la mise à jour de sa documentation du 22 septembre 2026, ses propres documents d’utilisation indiquaient qu’il « n’incluait intentionnellement ni MCP intégré, ni sous-agents, ni fenêtres contextuelles d’autorisation, ni mode planification, ni listes de tâches, ni bash en arrière-plan », et vous orientaient plutôt vers les extensions, les packages, les conteneurs et tmux. La mise à jour a supprimé cette phrase, puis la v0.99.0 a fait de MCP une extension intégrée chargée par défaut ; les sous-agents, le mode planification, les listes de tâches et les invites d’approbation restent des extensions dans la v0.99.2. Choisissez Oh My Pi si vous voulez ces éléments intégrés dès le premier jour et n’avez aucune envie de maintenir une extension.
• Autorisations et modèle d’exécution. Aucun des deux réglages par défaut n’est le choix sûr ; choisissez donc le mode d’échec avec lequel vous pouvez composer. Pi n’a aucun système d’autorisation et l’indique explicitement. Oh My Pi en propose un véritable à trois niveaux, livré par défaut avec yolo. Si vous avez besoin d’invites par outil, Oh My Pi peut vous les fournir après une seule ligne de configuration ; Pi ne peut pas le faire sans extension.
• Limites de protocole et de plan. Si votre route modèle est un endpoint tiers compatible avec OpenAI ou Anthropic, les deux peuvent l’atteindre, mais Oh My Pi documente neuf dialectes filaires là où Pi en documentait quatre jusqu’à la mise à jour de sa documentation du 22 septembre 2026, et ajoute une route par variable d’environnement que Pi ne possède pas. L’écart entre les dialectes est moins marqué dans le code que sur le papier : le code source de Pi en v0.99.2 achemine le api d’un fournisseur personnalisé vers n’importe laquelle de dix implémentations intégrées, dont six n’ont jamais été documentées pour cet usage. Si votre route est un abonnement OAuth — Claude Pro/Max, Codex, GitHub Copilot — les deux clients l’attachent via /login et stockent un jeton fournisseur, qu’une passerelle intermédiaire rejetterait ; la propre documentation des fournisseurs d’Oh My Pi donne cette raison pour laquelle une clé models.yml prend délibérément le pas sur l’OAuth stocké. Ne regroupez pas les plans de programmation chinois avec cette catégorie : Pi répertorie ZAI/GLM, Kimi For Coding et les Qwen Token Plans dans son tableau de clés API (ZAI_API_KEY, KIMI_API_KEY, QWEN_TOKEN_PLAN_API_KEY), tandis qu’Oh My Pi les marque plan plutôt que oauth ; ce sont donc des fournisseurs ordinaires à clé dans les deux cas.
• Coût. Le client est gratuit des deux côtés et aucun ne modifie votre tarif par jeton. L’asymétrie tient au fait que Pi dispose d’une passerelle payante propriétaire (Radius, exploitée par la même société) reliée à son propre /login, tandis qu’Oh My Pi ne vend aucune route hébergée — le seul serveur qu’il exploite est le relais situé derrière les liens de session /collab, qui ne facture rien.
• Coût de migration. Environ un bloc fournisseur à retaper. Les formats et répertoires de configuration diffèrent — JSON sous ~/.pi, YAML sous ~/.omp — et aucun outil d’importation n’est documenté dans l’un ou l’autre dépôt. Quelques noms de variables d’environnement sont communs, avec les réserves indiquées ci-dessous.

Ce qui ne devrait pas déterminer votre choix : les numéros de version. Oh My Pi a renuméroté ses versions lors du fork ; sa 18.2.7 et la 0.86.1 de Pi correspondent donc à des schémas différents, et non à dix-huit versions de maturité supplémentaire.

Ce qui diffère réellement entre les deux

Informations lues dans la documentation propre aux deux dépôts le 19 septembre 2026 : les pages de présentation, de sécurité et des modèles de Pi, ainsi que les pages README, approval-mode et providers d’Oh My Pi. Les lignes relatives à la conception annoncée, à MCP, au modèle d’autorisation et aux dialectes de Pi ont été revérifiées le 1er octobre 2026 à partir de sa documentation mise à jour, de son README et de son code source en v0.99.2. Les nombres de fonctionnalités de la ligne Oh My Pi correspondent aux propres affirmations de ce projet ; aucune méthodologie n’est publiée à leur sujet, et le tableau de benchmarks de son README constitue également une affirmation du fournisseur que cette page ne reproduit pas.

Les deux sont actifs. Aucun indicateur ne permet de trancher la question de savoir « lequel est le plus grand »

L’erreur la plus courante concernant ces deux projets consiste à traiter l’un d’eux comme abandonné ou remplacé. Les deux ont publié du code le jour de cette vérification.

Chiffres du dépôt, des versions et des étoiles issus de l’API GitHub, consultée le 21 septembre 2026 ; nombres de téléchargements issus de l’API de téléchargements npm pour la semaine se terminant le 16 septembre 2026. Ne transformez pas l’une ou l’autre colonne en verdict d’adoption. La comparaison npm n’est notamment pas homogène : la documentation de Pi commence par npm install -g, tandis que le README d’Oh My Pi documente curl-to-shell, Homebrew, Bun, Nix, PowerShell et mise, sans jamais fournir de commande npm ; npm le sous-évalue donc sensiblement, dans une proportion impossible à mesurer ici. Les étoiles favorisent Pi ; la cadence de publication favorise Oh My Pi ; toute phrase sur la popularité fondée sur un seul indicateur sera erronée dans au moins une direction.

Si vous souhaitez des éléments neutres de tiers confirmant que les deux projets sont actuels, sans passer par les métriques : Ollama publie une page d’intégration pour Oh My Pi et pour Pi, et DeepSeek publie également un guide d’intégration d’agent pour chacun — son guide Pi étant toujours classé sous l’ancien chemin pi_mono. Les quatre pages ont répondu le 21 septembre 2026.

Diriger l’un ou l’autre vers votre propre endpoint

C’est ici que le fork est le plus visible et qu’un mauvais /v1 peut vous coûter un après-midi. Les deux clients peuvent atteindre un endpoint tiers compatible avec OpenAI ou Anthropic, mais par des mécanismes différents et avec des conventions d’URL opposées.

Oh My Pi possède une route par variable d’environnement que Pi n’a pas. Son fournisseur Anthropic résout l’URL de base via normalizeAnthropicBaseUrl($env.ANTHROPIC_BASE_URL), avant la valeur officielle par défaut, et ce normaliseur supprime un /v1 final — https://api.kunavo.com et https://api.kunavo.com/v1 aboutissent donc au même hôte. Informations lues dans packages/ai/src/providers/anthropic-state.ts, où resolveDirectAnthropicBaseUrl() et le normaliseur sont définis, le 19 septembre 2026 — à partir du code source, et non d’une requête que nous aurions effectuée.

# Oh My Pi honours ANTHROPIC_BASE_URL for its built-in anthropic provider.
# normalizeAnthropicBaseUrl() strips a trailing /v1, so both forms resolve
# to the same host here. Pi ships no equivalent gateway base-URL variable.
export ANTHROPIC_API_KEY="$KUNAVO_API_KEY"
export ANTHROPIC_BASE_URL="https://api.kunavo.com"
omp

Cette route comporte un piège de priorité. L’ordre documenté par Oh My Pi place un models.yml apiKey en position 2, avant l’OAuth stocké en position 3, mais une variable d’environnement du fournisseur en position 5, après. Si vous êtes déjà connecté à Anthropic via /login, le jeton d’abonnement l’emporte sur ANTHROPIC_API_KEY et votre clé de passerelle n’est jamais utilisée. Définissez la clé dans la configuration ou déconnectez-vous d’abord de ce fournisseur.

Pour un fournisseur nommé, Oh My Pi utilise YAML — et ici le /v1 est réajouté, car son chemin OpenAI ajoute /chat/completions textuellement à l’URL de base supprimée.

providers:
  kunavo:
    baseUrl: https://api.kunavo.com/v1   # /v1 REQUIRED: omp appends /chat/completions
    api: openai-completions              # use anthropic-messages, and then drop /v1
    apiKey: KUNAVO_API_KEY               # env var name, a literal, or "!cmd"
    authHeader: true                     # send Authorization: Bearer <key>
    models:
      - id: claude-sonnet-5
        contextWindow: 200000
        maxTokens: 64000

Pour diriger Pi vers une passerelle, vous disposez d’une seule route : ~/.pi/agent/models.json. Pi ne lit aucun ANTHROPIC_BASE_URL — une recherche dans le code du dépôt le 19 septembre 2026 renvoie deux occurrences de cette chaîne exacte, toutes deux sans remplacement (une constante Cloudflare AI Gateway et un script de génération de modèles) — et il n’existe pas non plus de OPENAI_BASE_URL nu. Une variable d’URL de base existe, mais ce n’est pas une solution générale : AZURE_OPENAI_BASE_URL, répertoriée dans les documents des fournisseurs de Pi, dirige le fournisseur Azure OpenAI vers votre propre ressource Azure et rien d’autre.

{
  "providers": {
    "kunavo": {
      "baseUrl": "https://api.kunavo.com",
      "api": "anthropic-messages",
      "apiKey": "$KUNAVO_API_KEY",
      "models": [
        {
          "id": "claude-sonnet-5",
          "contextWindow": 200000,
          "maxTokens": 64000
        }
      ]
    }
  }
}

Concernant le suffixe, la documentation de Pi n’a jamais tranché et vous devez le savoir plutôt que de faire confiance à un exemple. Jusqu’à la mise à jour de sa documentation du 22 septembre 2026, sa page des modèles affichait un proxy anthropic-messages sous la forme https://proxy.example.com/v1 à un endroit et sous la forme https://proxy.example.com sans suffixe à un autre ; la mise à jour a supprimé les deux sans trancher la question. La forme sans suffixe est celle à suivre, et ce raisonnement est déduit du code plutôt que testé à l’exécution : Pi ne fournit rien de comparable au normaliseur d’Oh My Pi qui supprime /v1 sur le chemin anthropic-messages — la seule normalisation décrite dans sa documentation concerne Azure : les URL racines de ressources sur les propres domaines d’Azure « sont normalisées vers le chemin de l’API OpenAI » — sa valeur Anthropic intégrée par défaut est https://api.anthropic.com sans /v1, tandis que sa valeur OpenAI par défaut est https://api.openai.com/v1, et pour anthropic-messages il transmet directement model.baseUrl au SDK officiel Anthropic, qui ajoute lui-même /v1/messages. Un /v1 à cet endroit produirait /v1/v1/messages. Kunavo documente la même convention sur sa page consacrée à l’URL de base : l’origine uniquement pour les clients de type Anthropic, /v1 pour ceux de type OpenAI.

Deux autres limites méritent d’être anticipées. Jusqu’à la mise à jour de la documentation de Pi du 22 septembre 2026, son tableau documenté répertoriait quatre dialectes pour les fournisseurs personnalisés, alors que le dépôt fournit des gestionnaires supplémentaires ; la mise à jour a supprimé le tableau sans nommer de liste de remplacement, de sorte que ces quatre dialectes restent la seule surface documentée par Pi pour les fournisseurs personnalisés. Les gestionnaires supplémentaires ne sont toutefois pas réservés aux intégrations natives : le code source de Pi en v0.99.2 typifie un models.json api comme une chaîne libre et l’achemine vers l’une des dix implémentations enregistrées qui correspond (BUILTIN_APIS dans packages/ai/src/compat.ts), si bien qu’un fournisseur personnalisé peut nommer bedrock-converse-stream ou google-vertex — le fonctionnement de l’un ou l’autre avec un endpoint tiers n’est pas documenté et n’a pas été testé ici. Du côté d’Oh My Pi, disabledProviders est vérifié avant les identifiants — un ID fournisseur intercepté par cette liste disparaît silencieusement quelle que soit la clé fournie — tandis que les tableaux de paramètres sont entièrement remplacés par la couche de priorité supérieure plutôt que fusionnés ; une liste au niveau du projet élimine donc discrètement la liste globale. Les deux projets proposent également des mécanismes de compatibilité dont vous pourriez réellement avoir besoin avec une passerelle : disableStrictTools pour Oh My Pi, supportsEagerToolInputStreaming et allowEmptySignature pour Pi. Le fait que Kunavo accepte les schémas stricts par défaut, les marqueurs de cache ou la diffusion anticipée des entrées d’outil de l’un ou l’autre client n’a pas été testé ici.

Ce que coûte réellement le changement

Moins que ne le suggère l’écart entre les numéros de version, et plus qu’une simple copie de fichier. Aucun import, convertisseur de sessions ou migrateur de configuration n’est documenté dans l’arborescence de documentation de l’un ou l’autre dépôt ; prévoyez donc de retaper le bloc fournisseur dans l’autre format — JSON vers YAML, ou l’inverse. Les identifiants ne sont pas transférés non plus : Pi les stocke dans ~/.pi/agent/auth.json, tandis qu’Oh My Pi conserve un magasin d’authentification SQLite dans ~/.omp/agent/agent.db.

Les variables d’environnement vont moins loin que ne le laisse penser leur ascendance commune ; lisez donc attentivement ce qui suit. Oh My Pi lit bien les noms préfixés par PI_ — notamment PI_CONFIG_DIR et PI_CODING_AGENT_DIR — mais ceux-ci déplacent les répertoires d’Oh My Pi ; en en exportant un dans un profil shell partagé avec Pi, vous dirigez les deux clients vers le même chemin au lieu de rendre une configuration portable. Le miroir OMP_ vers PI_ décrit dans sa référence des variables d’environnement est encore plus limité : ce document précise que la règle s’applique à l’intérieur de chaque fichier .env analysé et explicitement « pas aux variables arbitraires héritées du processus parent ». Ce qui ne sera pas transféré du tout, c’est tout ce qui repose sur le harness : une extension TypeScript de Pi est écrite pour l’API de Pi, et environ six mois de développement maintenu séparément depuis le marqueur de synchronisation du 22 mars 2026 correspondent précisément à la période où ces API divergent. Testez une extension au lieu de supposer qu’elle est portable.

Le coût est identique des deux côtés

Aucun des deux clients ne vous facture quoi que ce soit ; passer de l’un à l’autre modifie donc de zéro vos dépenses de modèles. La variable est la route par laquelle vous achetez les jetons, et sur ce point les deux diffèrent d’une manière : Pi possède une passerelle payante propriétaire, Oh My Pi non. Radius est exploité par Earendil, son code est fermé, et on y accède via le /login de Pi ; sa FAQ indique qu’elle facture « les frais que nous payons à notre prestataire de paiement en plus des prix affichés » — un pourcentage qu’elle ne publie pas, si bien qu’un total Radius ne peut pas être calculé de l’extérieur. La seule passerelle d’Oh My Pi est omp auth-gateway serve, un logiciel que vous hébergez, la sécurité du transport étant déléguée à l’opérateur.

Avant de l’intégrer à un budget, éliminons une idée reçue : un abonnement Claude Pro ou Max connecté dans l’un ou l’autre harness ne correspond pas à un usage gratuit. Jusqu’à la suppression de cette phrase lors de la mise à jour de sa documentation du 22 septembre 2026, la documentation des fournisseurs de Pi indiquait que l’utilisation d’un harness tiers « puise dans l’usage supplémentaire et est facturée au jeton, et non déduite des limites du forfait Claude » ; l’avertissement affiché par Pi lorsqu’un modèle Anthropic s’exécute avec une authentification par abonnement indique toujours qu’elle « puise dans l’usage supplémentaire et est facturée au jeton, et non selon les limites de votre forfait Claude » (source, v0.99.2). Aucune déclaration équivalente n’a été trouvée dans la documentation d’Oh My Pi ; ne supposez donc pas qu’il se comporte différemment et vérifiez votre propre compte.

Pour la route par passerelle, voici le calcul fondé sur la charge de travail plutôt que sur le client. Supposons un mois de travail d’agent régulier : 5,000,000 jetons d’entrée non mis en cache et 400,000 jetons de sortie, sans lectures ni écritures du cache et sans frais d’image ou d’outil. Les tarifs sont les prix actuels du catalogue Kunavo par million de jetons.

Il s’agit d’estimations illustratives de jetons fondées sur les hypothèses ci-dessus, et non de coûts de tâches mesurés ni d’un plafond de facturation. La colonne est identique pour les deux clients, car le client n’est pas une variable de tarification — mais la charge de travail peut différer : l’outil task d’Oh My Pi distribue les sous-agents en parallèle, et chaque agent parallèle possède son propre contexte, ce qui constitue un multiplicateur de jetons d’entrée qu’aucun tableau présenté ici ne peut dimensionner pour vous. Mesurez-le sur une modification limitée avant d’extrapoler l’estimation.

Deux réserves propres à Kunavo doivent être intégrées au même montant. Le montant du catalogue constitue un plancher de facturation et non un plafond : lorsque l’amont communique son coût, la facture correspond au plus élevé entre le coût du catalogue et le coût amont multiplié par la majoration applicable, comme l’explique le guide de facturation. Et le rechargement minimal est de $10 de crédit prépayé — l’argent nécessaire pour approvisionner un compte, et non des frais de tâche ou un abonnement.

Kunavo publie un guide de configuration pour chaque client — Pi et Oh My Pi — mais n’a testé aucun des deux en conditions réelles avec son endpoint ; un guide de configuration est une référence de paramétrage, pas un test de compatibilité. Les deux configurations ci-dessus sont rédigées à partir de la documentation et du code publiés et doivent être vérifiées sur votre propre machine. Conservez une route fonctionnelle pendant vos essais. Lorsque vous souhaitez chiffrer une tâche réelle plutôt qu’un modèle, créez un compte Kunavo, approvisionnez-le et exécutez une modification limitée avec le modèle présélectionné. Si vous choisissez encore un harness plutôt qu’un fournisseur, la tarification de l’agent de programmation Pi détaille les quatre routes de facturation de Pi, et Pi ou OpenCode compare Pi à un autre client disposant d’un guide de configuration Kunavo publié.

Questions fréquentes

Les arborescences de documentation et les packages npm des deux dépôts ont été vérifiés le 19 septembre 2026, et les affirmations concernant l’URL de base et l’ordre des informations d’authentification ont été lues dans les fichiers sources nommés dans le texte à la même date ; les métriques des dépôts et les historiques des versions ont été relus le 21 septembre 2026. Après la mise à jour de la documentation de Pi le 22 septembre 2026, ses exemples d’URL de base anthropic-messages, sa phrase sur la normalisation d’Azure, ses valeurs api documentées et l’ordre des informations d’authentification ont été revérifiés le 1er octobre 2026 par comparaison avec la documentation mise à jour et le code source en v0.99.2. Le même jour, après la sortie de Pi v0.99.0 avec MCP intégré, sa liste de fonctionnalités omises, sa formulation concernant la confiance accordée aux projets et sa conception déclarée ont été revérifiées par comparaison avec ses pages d’utilisation, MCP, paramètres et sécurité, son README, les valeurs api prises en charge par le mécanisme de routage de son code source et l’index des intégrations de ce site. La ligne concernant l’utilisation supplémentaire a été revérifiée par comparaison avec l’avertissement affiché dans le terminal par ce code source. Le 1er octobre 2026 également, les valeurs api documentées d’Oh My Pi ont été revérifiées par comparaison avec son docs/models.md et son schéma models.yml en v18.4.8. Les tarifs Kunavo sont affichés à partir du catalogue en direct et chaque montant en dollars présenté ici est un exemple de calcul fondé sur les jetons. Aucun des deux clients n’a été testé en exécution avec Kunavo, et aucune comparaison de performances ou de benchmarks entre les deux projets n’est sous-entendue — il n’en existe aucune que cette page pourrait citer.