Tutoriel Pi Coding Agent 2026 : npm, clés API et Claude/GPT/Gemini en TypeScript

Pourquoi « encore un IDE Agent » ne résout pas le multi-modèles

En 2026, la douleur de la plupart des équipes n'est pas « l'absence d'agent ». C'est que la clé, le modèle et l'environnement d'exécution sont soudés dans le même produit. Claude Code consomme l'abonnement Anthropic. Codex CLI consomme ChatGPT. Cursor range le choix de modèle derrière le compte de l'éditeur. Vous voulez Claude l'après-midi pour une refonte d'architecture, Gemini le soir pour balayer les tests, GPT le week-end pour rédiger le message de commit — et chaque fois il faut changer de fenêtre, de droits, de contexte. Ce n'est pas un problème de « modèle trop faible ». C'est un problème de produit trop fermé.

Le réflexe habituel, c'est d'attendre le prochain IDE Agent : une barre latérale plus jolie, un diff plus fluide, un mode plan plus bavard. Ça améliore l'après-midi où vous êtes collé à l'éditeur. Ça n'améliore pas la nuit où un script de revue doit tourner tout seul, ni le lundi où le budget vous pousse à basculer de Claude vers Gemini sans réécrire les règles du dépôt. Un IDE plus épais empile des fonctions. Il ne sépare pas les couches.

Pi casse cette hypothèse. Le positionnement officiel est un harness minimal : par défaut, le modèle n'a que quatre outils — read, write, edit, bash. Le sub-agent, le plan mode, les portes de permissions, le MCP — tout ce que les autres produits intègrent — devient extension, Skill ou Pi Package, à ajouter selon votre workflow. Le modèle est un backend interchangeable, pas le produit lui-même. Vous n'achetez pas « l'intelligence Claude ». Vous installez une boucle d'outils, puis vous branchez les clés que vous avez déjà.

La conclusion asymétrique est celle-ci : la ligne de partage n'est pas de savoir si Claude, GPT ou Gemini est le plus fort, mais si le harness peut traiter le modèle comme un backend interchangeable, et s'encastrer dans votre propre projet TypeScript. Ce qu'il faut faire évoluer, c'est l'entrée (CLI / SDK / RPC), la stratification des credentials et un nœud d'exécution toujours allumé — pas encore un IDE plus lourd. Pour le découpage conceptuel de « qu'est-ce qu'un harness », voir Agent Harness expliqué : comprendre le viral Omnigent (2026) ; cet article ne traite que « comment installer Pi, brancher trois clés, et adapter le tout au dépôt ».

Si vous n'avez qu'une seule facture fournisseur et que vous ne quittez jamais l'éditeur, vous n'avez pas besoin de Pi. Si vous avez déjà deux clés, un Makefile, un runner CI, et l'envie d'écrire la revue comme un script plutôt que comme un chat, alors le prochain IDE ne fera que déplacer le même verrou. Le reste de l'article part de ce constat et descend dans les commandes.

Qu'est-ce que Pi : les quatre entrées d'un harness minimal

On classe d'abord, on parle commandes ensuite. Pi n'est pas encore une fenêtre de chat. C'est quatre façons d'ouvrir la même boucle d'agent. Les dimensions restent l'entrée, l'exécution, le contexte et le public cible. Cette grille évite de comparer Pi à Cursor sur le confort du diff, ou à Claude Code sur la profondeur d'intégration Anthropic — ce ne sont pas les mêmes couches.

Le site le dit sans détour : changez le harness, pas votre workflow. Les extensions sont des modules TypeScript : elles enregistrent des outils, des commandes slash, des raccourcis et des widgets TUI. Les Skills se chargent à la demande, pour éviter d'exploser le prompt cache dès l'ouverture. Les paquets s'installent avec pi install npm:@scope/pkg ou pi install git:host/user/repo. La liste complète des capacités se lit sur pi.dev et sur la fiche npm ; les numéros de version bougent, la forme des commandes est plus stable que « le nom de modèle du 16 septembre ».

Cette architecture a un prix psychologique : Pi a l'air « trop maigre » le premier soir. Pas de plan mode, pas de sous-agents, pas de magie d'éditeur. C'est voulu. Si vous ajoutez ces couches trop tôt, vous recréez le produit fermé que vous veniez de quitter — sauf que cette fois c'est vous qui payez la maintenance. Installez d'abord le CLI, branchez une clé, lancez une tâche print. Ensuite seulement, parlez d'extensions.

Pi vs agents fermés : entrée, exécution, contexte

Si l'évaluation commence par « Claude est-il plus fort que GPT ? », vous ratez la vraie différence. Alignez Pi, les CLI officiels et l'agent IDE dans un même tableau — entrée, exécution, contexte, public cible — et la conclusion s'inverse presque tout de suite. Le format « classement » est traité dans Meilleurs agents de codage IA 2026 : 15 comparés ; ici on ne refait pas les places, on répond seulement à « faut-il extraire les clés du produit ».

Le choix Claude Code vs Codex sur un Mac distant est traité dans Claude Code vs Codex : environnement de développement Mac à distance. Ces pages répondent à « comment choisir le CLI officiel ». Celle-ci répond à « une fois le multi-modèles décidé, et la boucle à encastrer en TypeScript, comment installer le harness ».

Une règle simple pour ne pas se tromper de couche : si votre contrainte n°1 est le confort du diff dans l'éditeur, restez sur l'IDE. Si c'est la profondeur Anthropic ou OpenAI, restez sur le CLI officiel. Si c'est « trois backends, une seule liste blanche d'outils, un script dans le dépôt », alors Pi n'est pas un concurrent de ces produits — c'est la couche en dessous. Payer deux fois (IDE + harness) n'a de sens que si les deux couches font un travail différent. Sinon vous achetez de la redondance.

Installation npm et configuration des clés API

CLI global : d'abord pouvoir parler, ensuite encastrer

L'installation globale officielle passe par --ignore-scripts. L'usage normal de Pi ne dépend pas des scripts de cycle de vie des dépendances ; les sauter réduit les surprises de chaîne d'approvisionnement. La version de Node, c'est votre LTS locale. Le numéro d'engine déclaré par le paquet bouge ; n'écrivez pas le patch d'un billet de blog dans un contrat. Sur un Mac cloud ou un runner auto-hébergé, figez Node dans l'image avant de figer le modèle : un pi --version qui dérive d'une machine à l'autre est plus douloureux qu'un ID de modèle qui a changé dans le catalogue.

npm install -g --ignore-scripts @earendil-works/pi-coding-agent
# ou : pnpm add -g --ignore-scripts @earendil-works/pi-coding-agent
# ou : bun add -g --ignore-scripts @earendil-works/pi-coding-agent
# installeur alternatif : curl -fsSL https://pi.dev/install.sh | sh
pi --version

Après l'install, deux gestes seulement : vérifier que pi est dans le PATH ; vérifier qu'au moins une clé — ou une session /login — est prête pour le fournisseur visé. Sans credentials, la TUI s'ouvre, mais le catalogue des modèles exécutables est vide. C'est le premier piège : on croit que « Pi est cassé », alors que c'est juste une armoire sans clé.

Comment stratifier les clés : variables d'environnement, auth.json, surcharge ponctuelle

L'ordre officiel de résolution des credentials est : --api-key en ligne de commande → ~/.pi/agent/auth.json → variables d'environnement du processus → clé de fournisseur personnalisé dans models.json. En interactif, /login écrit l'OAuth ou la clé API dans auth.json (permissions 0600). auth.json prime sur les variables d'environnement : il convient à « cette machine utilisera longtemps cette clé ». Les variables conviennent au CI et aux essais ponctuels. Dans le SDK, setRuntimeApiKey est une surcharge en mémoire processus, sans écriture disque — tests et hôtes multi-locataires.

export ANTHROPIC_API_KEY=sk-ant-...
export OPENAI_API_KEY=sk-...
export GEMINI_API_KEY=...   # dans auth.json, la clé correspondante s'appelle google

pi
# interactif : /login pour choisir le fournisseur ; /model ou Ctrl+L pour basculer ; Ctrl+S pour enregistrer comme défaut au démarrage

{
  "anthropic": { "type": "api_key", "key": "sk-ant-..." },
  "openai": { "type": "api_key", "key": "sk-..." },
  "google": { "type": "api_key", "key": "..." }
}

Le champ key accepte aussi une interpolation $ENV_VAR, et une lecture par commande du type !op read 'op://…' (cache en mémoire processus). Sur une machine distante ou sans tête, les callbacks navigateur d'OpenRouter et assimilés ne passent pas : le flux officiel demande de coller l'URL de redirection finale ou le code d'autorisation dans l'invite de login — très fréquent sur un Mac cloud en SSH. Le tableau des fournisseurs fait foi dans providers.md.

Sur un nœud partagé, la tentation est de poser un auth.json d'équipe dans le home d'un utilisateur CI. Faites-le uniquement si le fichier est 0600, hors dépôt, hors artefact, et rotaté comme un secret. Une clé « pratique » qui survit six mois dans /Users/shared n'est plus un credential, c'est une dette. Le SDK runtime key ne remplace pas cette hygiène : il évite d'écrire, il n'évite pas de fuiter dans les logs.

Brancher Claude, GPT et Gemini

Pi tient, pour chaque fournisseur intégré, un catalogue de modèles « capables d'outils ». Les catalogues déjà configurés se rafraîchissent tout seuls ; pi update --models force un pull. L'authentification peut être un abonnement (Claude Pro/Max, ChatGPT Plus/Pro Codex, GitHub Copilot) ou une clé API. La bascule se fait avec /model, Ctrl+L ; les modèles fréquents tournent avec Ctrl+P ; /scoped-models fixe la liste de rotation. L'intérêt n'est pas d'avoir trois logos dans le menu. C'est de relancer la même invite, avec la même AGENTS.md, et de voir le backend changer — pas les règles du dépôt.

pi --list-models claude
pi --list-models gpt
pi --list-models gemini

pi --provider anthropic --thinking high "Refactoriser les boucles de src/ en fonctions testables"
pi --model openai/gpt-4o -p "Résumer les modules d'entrée de ce dépôt en trois phrases"
pi --provider google -p "Lecture seule : lister les fichiers de tests non couverts"

# bascule en session, sans réinstaller
# /model   ou Ctrl+L
# Ctrl+P   rotation dans la liste scoped

Les ID de modèles bougent quand le catalogue se rafraîchit. Les exemples officiels ont déjà montré des graphies du type claude-opus-4-5, claude-sonnet-4-5, gpt-4o, gpt-5.1 ; en production, fiez-vous à pi --list-models et à getAvailable() du SDK, pas à l'ID figé d'un billet. Les passerelles maison (Ollama, vLLM, proxy d'entreprise) passent par ~/.pi/agent/models.json, à condition que l'autre côté parle l'une des API OpenAI / Anthropic / Google ; OAuth ou protocole privé : passez par une extension, ne patchez pas le CLI.

Si ce que vous voulez vraiment, c'est « écrire le HTTP, parser le JSON vous-même », vous êtes à la couche Function Calling, pas à la couche harness. Croisez avec Function Calling et API JSON chez OpenAI, Gemini et Claude et API GPT-5.6 : guide, tarifs et modèles : ces deux pages enseignent l'appel direct au fournisseur ; celle-ci enseigne à laisser Pi gérer la boucle d'outils, et à ne changer que le backend.

Mise en pratique dans un projet TypeScript

Le CLI résout « un humain commande dans le terminal ». Le SDK résout « un script du dépôt commande aussi ». Le SDK vit dans le même paquet npm : pas d'install séparée. La boucle minimale est : dépendance locale → les trois clés restent dans l'environnement → ModelRuntime choisit le modèle → createAgentSession envoie une tâche en lecture seule → dispose(). Si vous sautez dispose(), vous laissez des handles et parfois une session ouverte. En CI, c'est un runner qui fuit ; en local, c'est un fichier de session que plus personne ne relit.

npm init -y
npm install @earendil-works/pi-coding-agent
# ajouter "type": "module" dans package.json

import {
  createAgentSession,
  ModelRuntime,
  SessionManager,
} from "@earendil-works/pi-coding-agent";

const runtime = await ModelRuntime.create();

if (process.env.ANTHROPIC_API_KEY) {
  await runtime.setRuntimeApiKey("anthropic", process.env.ANTHROPIC_API_KEY);
}
if (process.env.OPENAI_API_KEY) {
  await runtime.setRuntimeApiKey("openai", process.env.OPENAI_API_KEY);
}
if (process.env.GEMINI_API_KEY) {
  await runtime.setRuntimeApiKey("google", process.env.GEMINI_API_KEY);
}

const preferred =
  runtime.getModel("anthropic", "claude-opus-4-5") ??
  runtime.getModel("openai", "gpt-4o") ??
  (await runtime.getAvailable())[0];

if (!preferred) {
  throw new Error("Aucun modèle disponible : exportez d'abord l'une des trois clés, ou lancez pi --list-models");
}

const { session } = await createAgentSession({
  model: preferred,
  thinkingLevel: "low",
  tools: ["read", "bash"],
  sessionManager: SessionManager.inMemory(),
  modelRuntime: runtime,
});

try {
  session.subscribe((event) => {
    if (
      event.type === "message_update" &&
      event.assistantMessageEvent.type === "text_delta"
    ) {
      process.stdout.write(event.assistantMessageEvent.delta);
    }
  });
  await session.prompt(
    "Lecture seule : lister les fichiers d'entrée TypeScript du répertoire courant, et signaler l'endroit le plus susceptible de manquer de tests. Ne pas modifier de fichiers."
  );
} finally {
  session.dispose();
}

Ce code restreint volontairement les outils à read + bash, et garde la session en mémoire, sans écriture disque. Un script de revue en CI ne doit pas posséder write/edit par défaut. Pour une session persistante, passez à SessionManager.create(process.cwd()) ; pour partager la même clé longue durée que le CLI, n'appelez pas setRuntimeApiKey et laissez le runtime lire ~/.pi/agent/auth.json. Si vous personnalisez le chemin d'auth, pointez authPath / modelsPath vers le répertoire de l'application, pour éviter que plusieurs services se battent pour le même fichier home. La sémantique des événements SDK, du braquage (steer) et de la suite (followUp) est dans sdk.md.

Deux habitudes qui évitent les dérives de version : l'humain utilise le CLI global ; les scripts verrouillent la version du package.json du projet. Les deux peuvent lire le même ~/.pi/agent. Ce qu'il ne faut pas faire, c'est qu'un script de revue écrase en runtime la clé machine dont le TUI a besoin le lendemain. Runtime key = tâche. auth.json = nœud. Secrets CI = pipeline. Trois tiroirs, pas un dotenv unique « pour aller plus vite ».

AGENTS.md : écrire les règles du dépôt pour tous les modèles

Au démarrage, Pi concatène ~/.pi/agent/AGENTS.md, puis les AGENTS.md (ou CLAUDE.md) des répertoires parents et du répertoire courant. Si une couche expose AGENTS.override.md, cette couche ne charge que le fichier d'override. C'est le point d'ancrage de « changer de modèle sans changer de règles » : Claude, GPT et Gemini lisent les mêmes entrées, les mêmes commandes de test et les mêmes lignes rouges. Pour remplacer le prompt système, utilisez .pi/SYSTEM.md ; pour ajouter, APPEND_SYSTEM.md.

# Règles de ce dépôt pour Pi
- Gestionnaire de paquets : npm. Ne pas basculer vers pnpm sans consigne.
- Contrôles : npm test && npm run lint
- Lignes rouges : ne pas committer .env, auth.json, *.pem
- Lecture seule par défaut ; n'utiliser write/edit que si l'utilisateur dit clairement « tu peux modifier les fichiers »

Un CI sans tête n'affichera pas la boîte de dialogue de confiance projet. S'il n'existe pas de décision de trust déjà enregistrée, le mode non interactif suit le defaultProjectTrust global : ask (défaut) et never ignorent les ressources projet .pi/ ; seul always fait confiance. La surcharge ponctuelle passe par --approve / --no-approve. Quand vous glissez Pi dans un runner auto-hébergé, écrivez d'abord la politique de confiance dans l'image machine, ensuite seulement parlez de modèle. La stratification GitHub Actions et runner Mac cloud est dans GitHub Actions : runner macOS auto-hébergé et Mac cloud.

Comment choisir selon le scénario

La vraie question n'est pas « faut-il installer Pi ? ». C'est quelle est la première contrainte : corriger du code en interactif, écrire l'agent comme un script, ou seulement l'expérience clé en main d'un CLI officiel. Si vous répondez « les trois », vous paierez trois couches. Choisissez la contrainte qui casse la semaine en premier.

Le jugement produit « pourquoi le Cloud Mac est la couche d'exécution des agents » est développé dans Pourquoi le Cloud Mac devient le standard iOS en 2026. Cet article complète la couche qui tourne sur le nœud : npm, clés, bascule de modèles et scripts TypeScript.

Combinaisons recommandées

Les outils peuvent se superposer. Pi résout « un harness de codage à modèles interchangeables ». Il ne vous offre pas un Mac qui ne ferme jamais le capot, et il ne paie pas vos trois factures fournisseurs.

• Combinaison quotidienne personnelle : pi global + ANTHROPIC_API_KEY par défaut + les deux autres clés en réserve + AGENTS.md du dépôt. En interactif, Ctrl+L change le modèle, pas les règles.
• Combinaison dépôt TypeScript : CLI global pour l'humain, une seconde copie du SDK en devDependencies pour les scripts. La revue passe par des outils en lecture seule ; la modification de fichiers ouvre une commande à confirmation humaine.
• Combinaison CI : pi -p ou script SDK + Secrets GitHub Actions + runner macOS auto-hébergé. La politique de confiance se fige avec --approve ; les clés ne s'impriment pas dans les logs.
• Combinaison passerelle multi-fournisseurs : OpenRouter / Cloudflare AI Gateway, une clé pour plusieurs modèles ; la bascule reste le /model de Pi. Utile aux équipes qui ne veulent pas éparpiller trois clés d'origine sur chaque machine.
• Combinaison de validation minimale : n'installez que le CLI, n'exportez qu'une clé, lancez pi -p "lister les fichiers ts du répertoire courant". Quatre temps (install → credentials → une tâche → reproductible) avant d'ajouter le deuxième modèle et le SDK.

Une salle de classe multi-agents ou un clone IM n'est pas le terrain de Pi : il y faut orchestration et passerelle, voir OpenMAIC et l'ère de la collaboration multi-agents. Pi convient plutôt à « la même boucle lire-modifier-exécuter, on change le backend et on continue ».

Si vous empilez Pi + OpenClaw + un IDE, dessinez d'abord qui possède la session. Pi possède la boucle d'outils du dépôt. OpenClaw possède le réveil depuis le IM. L'IDE possède le diff humain. Trois propriétaires, un seul auth.json machine, une seule politique de trust. Dès que deux produits écrivent la même session, vous déboguerez des fantômes, pas des modèles.

Erreurs courantes

• Comprendre Pi comme un clone gratuit de Claude Code. Il refuse volontairement le sub-agent et le plan mode. Les fonctions dont vous avez besoin s'ajoutent en extension ou en Package ; ne vous plaignez pas que « le cœur est trop maigre » pour retourner attendre le prochain IDE.
• Fourrer trois clés dans le même dotenv qui finira dans git. Machine de dev : profil shell ou 1Password ; CI : Secrets ; machine partagée : auth.json en 0600. La runtime key du SDK n'écrit pas sur disque, elle ne remplace pas le credential machine.
• Figer dans la production l'ID de modèle d'un billet de blog. Le catalogue se rafraîchit. Un script doit passer par getAvailable() ou --list-models, puis se rattraper sur un préfixe de fournisseur stable.
• Donner à l'agent write/edit par défaut en CI. Revue et inspection : liste blanche en lecture seule ; modification de fichiers : un verrou humain à part.
• Espérer une boîte de trust en mode sans tête. Réglez d'abord defaultProjectTrust ou passez --approve, sinon les Skills projet ne se chargent tout simplement pas.
• Lancer une longue tâche SDK sur un portable qui s'endort. L'arbre de sessions peut reprendre, mais les effets de bord d'un bash coupé par la veille ne se rollbackent pas tout seuls. Les tâches longues vont sur un nœud toujours allumé.

Une septième erreur, plus discrète : juger Pi à la longueur de la première réponse TUI. Le critère d'acceptation du premier soir, c'est « la même invite, deux fois, même résultat visible » — PATH, clé, print. La longueur du texte, le style du modèle, le confort du thème terminal, tout ça se discute après. Si vous optimisez le thème avant d'avoir une tâche reproductible, vous êtes encore en train de choisir un IDE.

Étapes de mise en œuvre

1. Écrivez les non-négociables : interactif seulement, scripts seulement, ou les deux ; faut-il brancher les trois modèles dès la première semaine ; le CI a-t-il le droit d'écrire sur disque.
2. Installez le CLI et faites un essai à vide : npm install -g --ignore-scripts @earendil-works/pi-coding-agent, pi --version, confirmez le PATH.
3. Branchez une seule clé : export ou /login, puis pi -p "lister le répertoire courant". Le critère d'acceptation est « reproductible », pas « réponse plus longue ».
4. Branchez la deuxième, puis la troisième : ajoutez OPENAI_API_KEY / GEMINI_API_KEY, relancez la même invite via /model ou --provider, et vérifiez que les règles viennent de AGENTS.md, pas de l'humeur du modèle.
5. Écrivez le SDK dans le dépôt : dépendance projet + un scripts/pi-review.ts en lecture seule. La liste blanche d'outils est figée dans le code.
6. Choisissez l'environnement d'exécution : le local suffit pour apprendre ; CI et tâches longues vont sur un Mac cloud toujours allumé ou un runner auto-hébergé, logs désensibilisés, clés hors artefacts.
7. Ajoutez ensuite extensions et observabilité : plan mode / MCP / portes de permissions ne s'installent qu'en Package, et seulement si besoin. Mesurez d'abord usage, repli sur échec et reprise humaine, avant d'élargir les capacités.

Si l'étape 3 échoue, ne sautez pas à l'étape 5. Un SDK qui « ne trouve aucun modèle » est presque toujours un problème de PATH, de variable non exportée dans le job CI, ou de trust projet — rarement un bug de TypeScript. Gardez un pi --list-models dans les logs de bootstrap du runner. C'est moins glamour qu'un agent qui refactorise, et c'est ce qui vous évite une nuit à blâmer Gemini.

FAQ

Quel est le lien entre Pi Coding Agent et Claude Code ?

Claude Code est le workflow de codage officiel d'Anthropic : modèle et entrée sont liés. Pi est un harness minimal tiers : il peut utiliser une clé Anthropic ou un abonnement Claude, et brancher en même temps OpenAI et Gemini. Il ne remplace pas « l'intégration officielle en profondeur ». Il remplace « changer de modèle, c'est changer toute la boîte à outils ».

Faut-il configurer Claude, GPT et Gemini en même temps ?

Non. Une seule clé suffit à valider l'installation. Le sens de la deuxième clé, c'est : la même AGENTS.md, la même liste blanche d'outils, un backend qui change selon la tâche. Sans deuxième facture, n'élargissez pas la surface d'exploitation « pour le multi-modèles ».

L'install npm globale et le SDK du projet se marchent-ils dessus ?

Ils ne se disputent pas la même commande, mais les versions peuvent dériver. La convention : l'humain utilise le CLI global, les scripts verrouillent la version du package.json du projet. Quand les deux lisent le même ~/.pi/agent, évitez qu'un script écrase avec une runtime key la clé longue durée de la machine.

Pourquoi la variable Gemini n'est-elle pas GOOGLE_API_KEY ?

Le tableau officiel nomme la clé Gemini GEMINI_API_KEY, alors que la clé dans auth.json s'appelle google. Vertex passe par ADC et des variables de projet / région, ce n'est pas le même chemin que la clé Gemini d'AI Studio. Fiez-vous à providers.md, ne devinez pas les noms de clés « par bon sens ».

Peut-on installer sur Windows / un Mac cloud sans tête ?

Oui. Le paquet npm global est multiplateforme ; le site propose aussi install.sh et un installeur PowerShell. Sur une machine sans tête, utilisez pi -p, RPC ou le SDK, pas la TUI. Un OAuth type OpenRouter en SSH demande de coller le callback. Sur un Mac cloud, figez d'abord la version de Node, le PATH et les permissions de auth.json.

Pourquoi un Mac cloud ? npm en local ne suffit-il pas ?

Le local suffit pour apprendre les commandes. Il ne suffit pas pour une revue de nuit, un correctif long après la fermeture du capot, ni pour un CI qui partage l'environnement Xcode / signature. Pi a découplé les modèles, mais bash et les outils fichiers restent attachés à la machine qui exécute le processus.

Conclusion

Le tutoriel d'installation de Pi Coding Agent, en surface, c'est npm, des variables d'environnement et trois ID de modèles. Ce qu'il faut vraiment faire tenir, c'est une stratification : harness et modèle séparés, clés et dépôt séparés, entrée interactive et entrée script séparées. L'usage qui tient en septembre 2026, c'est le CLI global pour l'humain, le SDK pour le dépôt, AGENTS.md pour tous les backends, un nœud toujours allumé pour les tâches longues.

La conclusion asymétrique tient toujours : la ligne de partage n'est pas de savoir si Claude, GPT ou Gemini est le plus fort, mais si vous pouvez traiter le modèle comme un backend interchangeable. Faites d'abord tenir un pi -p avec une seule clé, puis ajoutez le deuxième modèle et le script TypeScript ; quand il faudra une surface d'exécution, déplacez le processus du portable qui s'endort vers un Mac cloud. Ce qu'il faut faire évoluer, c'est l'entrée, les credentials et le nœud — pas encore un IDE Agent.