Changer de modèle dans Oh My Pi sans perdre sa progression : /model, /fork ou /new

Changer de modèle au milieu d’une longue session Oh My Pi ne modifie pas seulement la qualité des réponses. L’historique peut contenir des identifiants d’appels d’outils, des signatures de raisonnement, des images ou d’autres champs propres à l’ancien fournisseur que l’API cible refuse.

La règle la plus sûre est la suivante : sauvegardez séparément l’état du code et la preuve de la session, puis ne transmettez au nouveau modèle que l’historique utile. Utilisez /model si cet historique paraît compatible, /fork pour une expérience réversible, et /fork suivi de /clear, ou une session propre avec /new, si l’ancien historique est déjà suspect.

Créez deux points de contrôle avant le changement

La transcription de la session ne remplace pas Git, et Git ne conserve pas le cheminement de l’agent. Protégez les deux.

1. Notez l’état du dépôt

Commencez par voir précisément ce qui a changé :

git status --short
git diff --stat

Créez ensuite un commit local, un patch ou un autre point de restauration accepté par l’équipe. L’objectif n’est pas de publier un travail inachevé, mais de pouvoir revenir à l’état antérieur si le modèle suivant modifie les mauvais fichiers.

2. Exportez la session

Lancez /export. La référence officielle des opérations de session indique que cette commande crée un fichier HTML sans modifier la session. Le signe de réussite est le chemin affiché ; la TUI ouvre généralement aussi le fichier.

Traitez cet export comme une donnée sensible. Il n’est ni expurgé de ses secrets ni chiffré et peut contenir le contexte brut, des images et des payloads d’extensions.

3. Rédigez un handoff minimal

Ajoutez temporairement un fichier OMP-HANDOFF.md au dépôt avec :

• l’objectif actuel et ce qui est déjà terminé ;
• les fichiers modifiés ;
• les vérifications exécutées et leurs résultats ;
• la prochaine étape prévue ;
• l’erreur exacte, le modèle, le fournisseur et la route API concernés.

Une session propre n’a pas besoin de dizaines de tours copiés. Relire les instructions du projet et ce handoff est généralement plus maîtrisable.

Choisissez la commande en fonction du risque historique

Situation	Chemin recommandé	Ce qui est conservé	Limite principale
Même fournisseur ou modèle proche, sans erreur de protocole	/model	Session et historique actuels	La cible reçoit encore tout l’ancien historique
Tester un autre modèle tout en gardant l’original intact	/fork → /model	Session originale et branche avec historique	Les incompatibilités sont copiées elles aussi
Garder la trace originale sans rejouer l’ancien contexte	/fork → /clear → /model	Original intact ; le fork garde une piste d’audit après la limite de réinitialisation	Il faut reprendre l’objectif depuis le handoff
L’historique provoque déjà des 400 ou le changement traverse les protocoles	/new → /model	Dépôt et ancienne session restent ; la nouvelle conversation est vide	Todo, checkpoints et état des outils ne sont pas transférés automatiquement
Seul le stream ou l’état de conversation distant est bloqué	/fresh	Conversations visible et model-facing conservées	Aucun historique incompatible n’est supprimé

Chemin 1 : /model lorsque l’historique est compatible

Le README d’Oh My Pi précise que /model change le modèle actif en cours de session. C’est le bon choix lorsque le contexte existant est nécessaire et qu’aucun signe ne laisse penser que le fournisseur cible rejettera d’anciens appels d’outils, blocs de raisonnement ou contenus multimodaux.

Procédez dans cet ordre :

1. Attendez la fin de la réponse en cours ou interrompez-la. Ne changez pas de modèle pendant l’exécution d’outils.
2. Saisissez /model, choisissez le fournisseur et le modèle cibles, puis affectez-les au rôle actif.
3. Vérifiez le fournisseur/modèle affiché dans le sélecteur ou l’état d’Oh My Pi. Ne prenez pas l’auto-identification du modèle comme preuve.
4. Envoyez une tâche en lecture seule, par exemple lire un fichier connu et donner deux faits vérifiables.
5. Lancez une petite tâche avec outil. Ne reprenez la longue mission que si l’appel, son résultat et le tour suivant fonctionnent.

Si la première requête renvoie HTTP 400, ne répétez pas le même historique. Conservez l’erreur et l’export, puis passez à un fork nettoyé ou à une nouvelle session.

Chemin 2 : /fork pour une expérience réversible

/fork crée un nouveau fichier de session à partir de la session courante et bascule l’identité active. La documentation officielle explique qu’un fork complet conserve la conversation et l’attribution d’usage et copie le dossier d’artefacts au mieux. La session originale reste disponible, ce qui convient à une comparaison vérifiable.

Un fork complet copie toutefois tout l’historique. Si l’erreur s’y trouve, /fork seul la reproduit.

Utilisez plutôt cette séquence :

1. Lancez /fork et confirmez la nouvelle identité de session.
2. Dans le fork, lancez /clear.
3. Lancez /model et choisissez la cible.
4. Demandez au modèle de lire les instructions du projet et OMP-HANDOFF.md.
5. Validez par une tâche en lecture seule avant toute écriture.

/clear supprime le contexte vivant et le contexte envoyé au modèle, mais conserve l’ID de session, le titre, le répertoire de travail, les paramètres du modèle et le fichier transcript. Il ajoute un reset_boundary ; le JSONL persistant et l’export complet gardent l’historique antérieur. Vous conservez donc la preuve sans la renvoyer au nouveau modèle.

Si /fork est refusé, attendez la fin du streaming et vérifiez que la session est persistante. Un fork complet n’est pas disponible dans une session uniquement en mémoire.

Chemin 3 : /new lorsque l’ancien historique n’est plus sûr

/new crée une nouvelle identité et une conversation vide. D’après la référence officielle, le modèle et les réglages actuels restent en place, mais les files de conversation, todo, checkpoint, état des outils, identité de cache héritée et une partie de la mémoire promue sont effacés. Pour changer aussi de modèle, l’ordre habituel est donc /new, puis /model.

Flux recommandé :

1. Vérifiez l’existence de l’export et du point de restauration Git.
2. Lancez /new.
3. Lancez /model et choisissez le modèle cible.
4. Faites-lui lire les instructions du projet, les fichiers utiles et OMP-HANDOFF.md.
5. Commencez par une vérification en lecture seule, puis une écriture minimale.
6. Comparez le résultat au checkpoint Git et aux tests effectués avant le changement.

Lorsque le replay de l’historique casse déjà les requêtes, ce chemin est souvent plus rapide que des tentatives répétées. Vous perdez le contexte automatique du chat, pas les fichiers du projet. Les faits essentiels doivent vivre dans le code, les tests, la documentation et le handoff.

/fresh ne signifie pas « supprimer l’historique »

Le nom prête à confusion. Selon la référence officielle, /fresh réinitialise le stream côté fournisseur, les handles de session distante et l’état lié au prompt cache sans toucher au transcript local. Le tour suivant est reconstruit depuis la conversation locale ; les conversations visible et model-facing restent présentes.

En pratique :

• utilisez /fresh pour un stream bloqué, un prompt cache obsolète ou un ID de conversation distante qui a dérivé ;
• n’attendez pas qu’il supprime d’anciens tool-call IDs, signatures de raisonnement ou images incompatibles ;
• la phrase « start a fresh session » dans un issue peut être de l’anglais courant, pas la commande /fresh. Pour un historique vide, utilisez /new ; pour garder l’original tout en coupant le contexte, utilisez /fork puis /clear.

Ce que montrent deux erreurs 400 réelles

Un mode d’échec concerne les identifiants d’outils entre fournisseurs. Dans l’issue #15056, l’auteur et un mainteneur ont reproduit le replay d’un ID signé Vertex/Gemini vers une cible Chat Completions OpenAI-compatible. L’ID dépassait la limite de 64 caractères, la requête renvoyait HTTP 400 et la valeur invalide restait dans l’historique.

Au 10 octobre 2026, l’issue est toujours ouverte et la correction proposée dans la PR #15059 l’est aussi. Un commentaire indiquant « fix is up » ne prouve pas que votre version l’intègre. Vérifiez la version ou le changelog ; sinon, récupérez avec un historique propre.

L’issue #15015 décrit un autre Google 400 via un proxy HAI et l’attribue à un ancien thoughtSignature. Un mainteneur a précisé que skip_thought_signature_validator est utilisé volontairement pour les parties functionCall non signées et requis par l’API publique de Google, tandis que ce proxy le rejetait avant que la requête atteigne Google. L’issue a été fermée avec le label wontfix.

La conclusion utile n’est pas que tout changement vers Google échoue. Le même 400 peut venir de la conversion d’historique côté client ou d’une passerelle intermédiaire. Relevez le fournisseur réel, le modèle, api, l’endpoint, l’erreur complète et l’origine de l’historique avant de choisir une session propre, une mise à jour du client ou une correction du proxy.

Appliquer cette méthode à un fournisseur OpenAI-compatible personnalisé

Oh My Pi accepte les fournisseurs personnalisés dans ~/.omp/agent/models.yml, notamment avec api: openai-completions. Le README conseille d’exécuter omp models <provider> pour vérifier la découverte avant de choisir le modèle avec /model.

Par exemple, la documentation officielle BetterToken Chat Completions donne https://www.bettertoken.ai/v1 comme Base URL OpenAI-compatible et https://www.bettertoken.ai/v1/chat/completions comme URL complète. L’authentification utilise le Bearer API Key de l’utilisateur et le modèle doit être le Model ID complet et actuel du service.

Considérez-la comme une candidate compatible au niveau du protocole, pas comme une garantie pour tous les modèles, outils ou anciens historiques. Testez-la dans /new : d’abord une requête courte sans outil, puis une tâche en lecture seule. Conservez la vraie clé dans une configuration de credentials protégée, jamais dans le chat, l’export ou un log public.

Changer de Base URL ou de fournisseur ne corrige pas un 400 déjà présent dans l’historique. Isolez d’abord l’historique, puis testez séparément le nouvel endpoint.

Vérifications finales avant de reprendre la longue tâche

Ne continuez que lorsque tous ces résultats sont visibles :

• /export a produit un fichier dans un emplacement contrôlé ;
• le dépôt possède un checkpoint récupérable antérieur au changement ;
• le chemin choisi correspond à l’objectif : même session, fork réversible, contexte nettoyé ou nouvelle session ;
• Oh My Pi affiche le fournisseur/modèle attendu ;
• une tâche d’outil en lecture seule réussit et son résultat atteint le tour suivant ;
• la session originale reste retrouvable avec /resume, ou vous avez choisi de ne plus l’utiliser ;
• après un 400, erreur, version, fournisseur, modèle, api et endpoint ont été consignés au lieu d’être noyés sous les tentatives.

La règle de décision est simple : plus l’historique est précieux et manifestement compatible, plus /model est approprié. Plus le risque entre fournisseurs est élevé, plus il faut conserver la session originale et repartir avec un contexte propre.