Oh My Pi vs OpenCode : workflow, modèles et coût total

Les deux clients sont des logiciels MIT gratuits : le choix ne porte donc pas sur le prix, mais sur la question de savoir si vous voulez que la facture des modèles provienne du même compte que le client. OpenCode vend directement des modèles : un abonnement à $10 par mois appelé OpenCode Go et une passerelle à la demande appelée OpenCode Zen. Oh My Pi ne vend absolument rien et attend que vous fournissiez une clé. Choisissez Oh My Pi si vous savez déjà où acheter vos tokens et souhaitez un contrôle approfondi de leur routage ; choisissez OpenCode si vous voulez une surface plus large — terminal, IDE, serveur, SDK — ainsi que la possibilité d’acheter des modèles sans le quitter.

Trois collisions de noms doivent être résolues avant que tout cela soit utile, car deux d’entre elles vous dirigeraient vers la mauvaise documentation.

Quel projet est lequel

Faits concernant le dépôt, les versions et les paquets relevés dans les API GitHub et npm le 19 septembre 2026. Oh My Pi est un fork explicite : son README indique qu’« omp est un fork de Pi par Mario Zechner, réécrit comme une surface orientée codage », et le dépôt contient toujours une liste de contrôle pour reporter les modifications depuis le projet amont. Le changement d’OpenCode était un changement de marque de l’entreprise, et non un changement de propriétaire — l’organisation sst indique désormais « We've moved to https://github.com/anomalyco » et l’organisation anomalyco est nommée Anomaly. Cette page n’affirme pas de date pour ce changement de nom, car les éléments publics disponibles ne permettent pas de la déterminer de manière cohérente.

Lequel choisir

Flux de travail. Oh My Pi est un agent pensé d’abord pour le terminal, avec une couche de routage particulièrement explicite : son README décrit neuf rôles qui routent le travail selon l’intention — default pour les tours normaux, smol pour la distribution de sous-agents économiques, slow pour le raisonnement approfondi, ainsi que plan, commit, vision, task, advisor et tiny — chacun pouvant désigner un modèle différent, avec des chaînes de repli sous retry.fallbackChains lorsque le modèle principal atteint une limite de quota. OpenCode s’étend plutôt horizontalement : deux agents intégrés entre lesquels vous basculez avec Tab, ainsi que des intégrations documentées dans un IDE, une surface web, un serveur, un SDK et des plugins. Si votre problème est « je veux que des modèles économiques s’occupent des tâches économiques », c’est la structure intégrée d’omp. Si votre problème est « je veux que cet agent soit accessible depuis davantage d’endroits », c’est celle d’OpenCode.

Permissions et exécution. Aucun des deux n’est prudent par défaut. La documentation du mode d’approbation d’omp désigne yolo comme mode par défaut : read, write et exec sont approuvés automatiquement et aucune confirmation n’est demandée ; always-ask et write sont les paramètres plus stricts. Le système reconnaît bien une courte liste de motifs bash critiques — rm -rf /, fork bombs, téléchargement distant suivi d’une exécution, etc. — mais lisez attentivement la page du mode d’approbation d’omp avant de vous y fier : le même document indique qu’en yolo, une simple surcharge critique est ignorée, et que seule une politique explicite prompt/deny de l’outil ou de l’utilisateur force encore l’arrêt. La page des permissions d’OpenCode indique que la plupart des permissions sont par défaut sur "allow", tandis que doom_loop et external_directory sont par défaut sur "ask" et que les fichiers .env sont refusés en lecture. Les structures diffèrent également, ce qui compte lorsque vous transposez une politique : omp déclare un niveau read/write/exec par outil et le remplace avec tools.approval.<toolName>, tandis qu’OpenCode évalue des règles de motif dont la dernière correspondante l’emporte.

Limites des forfaits et du protocole. La seule restriction de type forfait ici fonctionne dans un sens inattendu. Aucun des deux clients ne conditionne l’utilisation de votre propre clé à un forfait. En revanche, OpenCode Go impose des attentes concernant les clients qui l’utilisent : il indique que le forfait est conçu pour OpenCode et d’autres agents de codage produisant des requêtes similaires, que « Traffic is monitored for abuse » et que votre client « should » envoyer un trafic typique d’agent de codage, « Identify itself with its own user agent » et « Send a stable session ID in x-opencode-session » pour chaque conversation. omp met précisément cette plomberie en œuvre pour son fournisseur opencode-go. Le tableau des clients validés d’OpenCode contient une ligne simplement nommée « Pi », qui ne distingue pas le projet amont de ce fork ; il est donc impossible de déterminer à partir de la page si elle couvre Oh My Pi — ce guide n’affirme pas qu’Oh My Pi est un client OpenCode Go validé.

Ce que coûte chacun

Vérifié le 19 septembre 2026. Les éléments indiquant qu’Oh My Pi ne vend rien sont indirects mais solides : son plan du site publie 36 URL, la page d’accueil et 35 pages de documentation, sans route de tarification, facturation, paiement ou inscription, et le dépôt est sous licence MIT. Son seul point de contact hébergé est un relais de collaboration de session qui utilise par défaut wss://my.omp.sh et scelle chaque charge utile de session avant qu’elle n’atteigne le socket — sans prix ni inscription associés. Une URL de relais personnalisée est acceptée, mais la même page indique que le relais de production n’est actuellement pas distribué pour un auto-hébergement.

Les chiffres de $10 constituent un plafond, pas une allocation

Il est important de comprendre précisément OpenCode Go, car les résumés tiers sont systématiquement erronés. La page officielle indique que « les limites d’utilisation sont définies sous forme de montants mensuels en dollars », et non en nombre de requêtes. Chaque modèle possède son propre plafond mensuel en dollars — 15 $, 30 $ ou 60 $ selon le modèle — et les fenêtres plus courtes correspondent à des pourcentages de ce même plafond par modèle : la fenêtre de 5 heures en représente 20 % et la fenêtre hebdomadaire 50 %. Ainsi, le chiffre de « 12 $ par tranche de 5 heures » souvent répété n’est vrai que pour un modèle dont le plafond mensuel est de 60 $. Deux autres règles modifient le calcul : « Un seul membre par espace de travail peut s’abonner à OpenCode Go », et atteindre un plafond ne provoque pas un blocage complet — la page indique que vous pouvez continuer à utiliser les modèles gratuits, ou activer un recours au solde afin que les requêtes soient débitées du crédit Zen au lieu d’être bloquées. Consultez le tableau des modèles directement sur la page plutôt qu’un résumé. La page indique que la liste peut changer, et elle évolue plus vite qu’un guide ne peut la suivre : le plafond d’un modèle était différent lors de deux vérifications espacées d’une journée, alors qu’un multiplicateur promotionnel limité dans le temps était affiché pour celui-ci ; considérez donc tout plafond cité où que ce soit — y compris ici — comme une illustration du mécanisme plutôt qu’un chiffre actuel.

Zen est le volet facturé à l’usage du même compte. Sa documentation indique que chaque requête est facturée sur un solde de crédits, que ce solde est rechargé automatiquement de 20 $ lorsqu’il tombe sous 5 $, sauf si vous modifiez ou désactivez cette option, et que les frais de carte sont répercutés au coût réel, à hauteur de 4,4 % plus 0,30 $ par transaction. Sa position déclarée est de « répercuter toute baisse de prix en vendant au prix coûtant ; la seule majoration sert donc à couvrir nos frais de traitement ». Deux éléments sont explicitement temporaires et deviendront obsolètes : les modèles affichés à 0 $ sont chacun décrits comme gratuits « pour une durée limitée », la plupart avec une note indiquant que l’équipe utilise cette période pour recueillir des retours et améliorer le modèle, et les espaces de travail d’équipe sont gratuits uniquement dans le cadre d’une bêta. Le nombre de modèles gratuits affichés change ; comptez-les sur la page plutôt que de vous fier à un chiffre indiqué ici. Ces deux informations figuraient sur la page le 19 septembre 2026 et doivent être relues avant d’établir votre budget sur cette base. Pour la grille tarifaire complète de Go et Zen, la tarification OpenCode en assure déjà le suivi.

Une estimation de tokens à comparaison équivalente

Il s’agit d’un calcul de tokens, pas du coût mesuré d’une tâche ni d’un plafond de facturation. Supposons une session de 200,000 tokens d’entrée non mis en cache et 15,000 tokens de sortie, et comparons uniquement les deux noms de modèles présents sur les deux listes tarifaires. Les tarifs Kunavo proviennent du catalogue en ligne ; les tarifs Zen ont été relevés dans sa propre documentation le 19 septembre 2026.

Lisez ceci de manière restrictive. Selon ces hypothèses, les deux listes tarifaires aboutissent à la même estimation pour Claude Sonnet 5 et à des estimations différentes pour Claude Opus 5 ; il s’agit d’une affirmation concernant deux tarifs publiés à une date donnée, et non d’une affirmation générale selon laquelle l’une ou l’autre passerelle serait moins chère. Zen publie des tarifs pour des modèles que Kunavo ne vend pas, et le catalogue Kunavo contient des modèles que Zen ne répertorie pas ; la majeure partie de chaque grille tarifaire n’a donc aucun équivalent à comparer. Le tarif affiché le moins cher et le coût le plus bas pour terminer une tâche sont également deux questions différentes : un modèle moins cher qui nécessite trois tentatives peut coûter plus cher qu’un modèle plus onéreux qui réussit en une seule passe.

Les montants de $10 ne sont pas comparables non plus, malgré leur apparence. Les $10 d’OpenCode Go correspondent à un abonnement mensuel récurrent dont la valeur dépend de votre consommation effective jusqu’au plafond par modèle. Le minimum de 10 de Kunavo correspond à un approvisionnement en crédit prépayé — un seuil de financement, pas des frais mensuels ni le prix d’une tâche. Le montant du catalogue Kunavo constitue un seuil de facturation plutôt qu’un plafond : lorsque l’amont signale son coût, la facture correspond au montant le plus élevé entre le coût du catalogue et le coût amont multiplié par la majoration applicable. Les frais de cache et les outils externes ne sont pas pris en compte dans cet exemple ; voir les détails de facturation.

Configurer l’un ou l’autre client avec votre propre clé

C’est ici que les deux clients divergent le plus, et que la migration vous coûte réellement du temps. Les deux acceptent un endpoint compatible OpenAI personnalisé sans condition liée à un forfait. Les différences concernent le fichier, les formats de protocole que chacun utilise et un piège de détection automatique.

Les deux tableaux ci-dessus sont tirés de la documentation propre aux projets le 19 septembre 2026 — les docs/models.md d’omp et la page des fournisseurs d’OpenCode.

Oh My Pi et le piège de la découverte

# Derived from omp's documented schema in docs/models.md.
# Not runtime-tested by Kunavo against a running omp.
providers:
  # OpenAI wire. baseUrl ENDS IN /v1 here.
  kunavo:
    baseUrl: https://api.kunavo.com/v1
    apiKey: KUNAVO_API_KEY      # an env var name, or a literal key
    api: openai-completions     # required whenever discovery is set
    authHeader: true            # sends Authorization: Bearer <key>
    discovery:
      type: openai-models-list  # reads /v1/models, picks up context_length

  # Anthropic wire. Written without /v1, matching omp's own proxy examples;
  # omp's docs say its Anthropic SDK strips a trailing /v1 either way.
  kunavo-anthropic:
    baseUrl: https://api.kunavo.com
    apiKey: KUNAVO_API_KEY
    api: anthropic-messages
    authHeader: true
    # disableStrictTools: true  # only if strict tool schemas are rejected
    models:
      - id: claude-sonnet-5
        name: Claude Sonnet 5

Un détail mérite à lui seul toute cette section. omp documente un mode discovery.type: proxy conçu pour les passerelles qui exposent à la fois /v1/messages et /v1/chat/completions derrière un même hôte — exactement la structure de Kunavo. Mais il déduit le protocole de chaque modèle depuis un champ supported_endpoint_types dans GET /v1/models, et les modèles qui n’en disposent pas « fall back to provider-level api if set, else dropped ». Le /v1/models de Kunavo n’émet pas ce champ ; discovery.type: proxy seul supprimerait donc le catalogue. L’extrait ci-dessus évite ce problème : discovery.type: openai-models-list lit d’abord max_model_len, puis context_length, et Kunavo publie bien context_length. La règle de validation propre à omp rend le api: au niveau du fournisseur obligatoire dès que la découverte est définie, sauf en mode proxy.

Un autre comportement d’omp est utile avec une passerelle : son ordre documenté de résolution des clés place un models.yml apiKey au-dessus de l’OAuth stocké, et indique que c’est volontaire, « so a key supplied for a custom baseUrl or gateway is honored instead of forwarding an upstream OAuth token the proxy would reject ». Cela élimine la cause la plus courante d’échec d’authentification d’une passerelle avant qu’elle ne se produise.

OpenCode et la particularité Anthropic

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "kunavo": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Kunavo",
      "options": {
        "baseURL": "https://api.kunavo.com/v1",
        "apiKey": "{env:KUNAVO_API_KEY}"
      },
      "models": {
        "claude-sonnet-5": {
          "name": "Claude Sonnet 5",
          "limit": { "context": 1000000, "output": 128000 }
        }
      }
    }
  },
  "model": "kunavo/claude-sonnet-5"
}

Le chemin des complétions de chat ci-dessus suit directement la structure documentée par OpenCode pour les fournisseurs personnalisés. Le chemin compatible Anthropic n’en possède pas : OpenCode documente l’accès à un endpoint Anthropic en remplaçant le fournisseur intégré — « You can customize the base URL for any provider by setting the baseURL option » — ce qui signifie que vous héritez des identifiants de modèles de ce fournisseur et renoncez aux modèles servis depuis l’hôte propre au fournisseur dans la même configuration. Un fournisseur personnalisé déclarant "npm": "@ai-sdk/anthropic" est autorisé par le schéma JSON publié d’OpenCode, où npm est une chaîne sans contrainte, mais il n’apparaît nulle part dans la documentation des fournisseurs ; considérez cette voie comme non vérifiée.

Surveillez l’orthographe de l’URL de base, mais vérifiez la règle propre à chaque client au lieu d’appliquer une convention unique aux deux. La surface compatible OpenAI attend https://api.kunavo.com/v1 dans les deux cas. Sur le protocole Anthropic, ils documentent une gestion différente : la documentation d’omp indique que son SDK Anthropic « strips a trailing /v1 from baseUrl before appending /v1/messages », et ses propres exemples de proxy Anthropic utilisent une URL de base sans /v1 ; OpenCode documente le chemin Anthropic comme un remplacement du baseURL du fournisseur intégré, et son exemple de remplacement se termine par /v1. La forme limitée à l’origine — https://api.kunavo.com, le client ajoutant /v1/messages — est la règle pour ANTHROPIC_BASE_URL lui-même, où un /v1 final produit bien /v1/v1/messages ; voir la référence de l’URL de base. Kunavo accepte Authorization: Bearer et x-api-key, de sorte que authHeader: true d’omp et la valeur par défaut de l’AI SDK disposent tous deux d’un chemin valide.

Ce que coûte réellement la migration

Passer de l’un de ces deux clients à l’autre implique une réécriture de la configuration, pas une copie. Le registre de découverte des fichiers de contexte d’omp inclut bien une source opencode, mais sa documentation limite cette source à un seul fichier au niveau utilisateur, ~/.config/opencode/AGENTS.md, sans équivalent au niveau du projet — vos instructions de projet ne sont donc transférées que si elles se trouvent déjà dans un fichier découvert par les deux clients, tel qu’un AGENTS.md à la racine du dépôt. Rien dans la documentation d’omp ne lit les blocs de fournisseurs de opencode.json ; les URL de base, les clés, les entrées de modèles et les limites de contexte doivent donc être redéclarées depuis zéro.

Une différence mérite une décision réfléchie plutôt qu’un haussement d’épaules. La page des fournisseurs d’OpenCode avertit que les versions précédentes intégraient des plugins permettant d’utiliser un abonnement Claude Pro ou Max et que « this is no longer the case as of 1.3.0 », au motif que le fournisseur l’interdit ; la même page répertorie toujours ChatGPT Plus, GitHub Copilot et GitLab Duo comme des abonnements utilisables sans configuration. omp, en revanche, fournit toujours des connexions OAuth avec rotation multi-comptes pour plusieurs fournisseurs de forfaits de codage. Si vous comptez payer par abonnement plutôt qu’avec une clé facturée au token, cette différence détermine le client — et il s’agit d’une question de politique : vérifiez les conditions actuelles de l’abonnement lui-même plutôt que la documentation de l’un ou l’autre client. Notez également que la propre section Anthropic d’OpenCode est publiée de manière incohérente : un texte décrivant une option de connexion Pro/Max précède l’avertissement qui l’a supprimée ; ce guide cite l’avertissement, car il s’agit de la déclaration datée et précise.

Enfin, si vous changez uniquement l’endroit où les tokens sont achetés, et non le client utilisé, commencez par là — c’est l’expérience la moins coûteuse. Comparez les fournisseurs avec la meilleure API pour OpenCode, ou consultez le fonctionnement d’une passerelle LLM si le concept de passerelle est précisément ce qui est nouveau. Si vous envisagez d’autres clients, les alternatives à OpenCode couvre un éventail plus large.

Testez-le sur une tâche limitée

Kunavo publie un guide de configuration pour OpenCode, mais pas encore pour Oh My Pi ; par ailleurs, une référence de configuration publiée ne constitue pas un test de compatibilité : aucun des deux clients n’a été testé ici en conditions réelles avec le point de terminaison de Kunavo, et l’extrait omp ci-dessus est le premier publié par Kunavo, dérivé du schéma documenté par omp. Gardez une route opérationnelle disponible pendant que vous essayez l’un ou l’autre, exécutez une seule tâche limitée, puis consultez le montant effectivement enregistré par votre compte pour celle-ci. Commencez par le guide d’intégration d’OpenCode, puis créez un compte Kunavo lorsque vous serez prêt à approvisionner une clé.

Questions fréquentes

Les faits concernant le dépôt, la version et le package ont été vérifiés auprès des API GitHub et npm le 19 septembre 2026 ; les pages Go, Zen, permissions, fournisseurs et entreprise d’OpenCode, ainsi que l’arborescence docs/ et le sitemap d’Oh My Pi, ont été consultés le même jour. Les valeurs api autorisées par Oh My Pi ont été revérifiées le 1er octobre 2026 par rapport à son docs/models.md et à son schéma models.yml dans la version v18.4.8. Aucun des deux clients n’a été testé en conditions réelles avec Kunavo. Les tarifs des tokens Kunavo proviennent du catalogue en ligne, et chaque montant en dollars de cette page correspond à un calcul illustratif de tokens, non au coût mesuré d’une tâche.