Modell in Oh My Pi wechseln, ohne Fortschritt zu verlieren: /model, /fork oder /new

Ein Modellwechsel in einer langen Oh-My-Pi-Sitzung betrifft nicht nur die Antwortqualität. Im Verlauf können providerspezifische Tool-Call-IDs, Reasoning-Signaturen, Bildblöcke oder andere Felder liegen, die die Ziel-API nicht akzeptiert.

Die sicherste Regel lautet: Sichern Sie Codefortschritt und Sitzungsnachweis getrennt und übernehmen Sie nur so viel Verlauf, wie das neue Modell wirklich braucht. Nutzen Sie /model, wenn der Verlauf wahrscheinlich kompatibel ist, /fork für einen reversiblen Versuch und /fork mit /clear oder eine saubere Sitzung über /new, wenn der alte Verlauf bereits verdächtig ist.

Vor dem Wechsel zwei Checkpoints sichern

Ein Sitzungstranskript ersetzt keinen Git-Checkpoint, und Git bewahrt nicht den Arbeitsweg des Agenten. Sichern Sie beides.

1. Arbeitsbaum festhalten

Prüfen Sie zuerst genau, was geändert wurde:

git status --short
git diff --stat

Erstellen Sie danach einen lokalen Commit, Patch oder einen anderen im Team akzeptierten Wiederherstellungspunkt. Es geht nicht darum, unfertige Arbeit zu veröffentlichen, sondern den Zustand vor dem Wechsel zuverlässig wiederherstellen zu können.

2. Sitzung exportieren

Führen Sie /export aus. Laut offizieller Referenz zu Sitzungsoperationen entsteht dabei eine HTML-Datei, ohne die Sitzung zu verändern. Das sichtbare Erfolgssignal ist der ausgegebene Pfad; die TUI öffnet die Datei normalerweise zusätzlich.

Behandeln Sie den Export als sensible Datei. Er wird weder automatisch von Geheimnissen bereinigt noch verschlüsselt und kann Rohkontext, Bilder und Extension-Payloads enthalten.

3. Kurze Übergabe schreiben

Legen Sie vorübergehend eine OMP-HANDOFF.md im Repository an und notieren Sie:

• aktuelles Ziel und abgeschlossene Arbeit;
• geänderte Dateien;
• ausgeführte Prüfungen und Ergebnisse;
• den nächsten vorgesehenen Schritt;
• vollständigen Fehlertext sowie Modell, Provider und API-Route.

Eine saubere Sitzung braucht nicht Dutzende kopierte Chat-Turns. Projektanweisungen, relevante Dateien und diese Übergabe sind meist kontrollierbarer.

Den Befehl nach dem Verlaufsrisiko wählen

Situation	Empfohlener Weg	Was erhalten bleibt	Wichtigste Einschränkung
Gleicher Provider oder nahes Modell, keine Protokollfehler	/model	Aktuelle Sitzung und Verlauf	Das Ziel erhält den alten Verlauf
Anderes Modell testen und Original unverändert behalten	/fork → /model	Original plus Fork mit Verlauf	Inkompatibler Verlauf wird ebenfalls kopiert
Originalnachweis behalten, alten Modellkontext aber nicht senden	/fork → /clear → /model	Original bleibt vollständig; Fork behält Audit-Spur nach der Reset-Grenze	Aufgabe muss aus der Übergabe wiederaufgenommen werden
Verlauf erzeugt bereits 400 oder Provider/API-Familie wechselt	/new → /model	Arbeitsbaum und alte Sitzung bleiben; neue Unterhaltung ist leer	Todo, Checkpoint und Tool-Zustand werden nicht automatisch übertragen
Nur Stream oder serverseitige Unterhaltung hängt	/fresh	Sichtbarer und model-facing Verlauf bleiben	Inkompatibler Verlauf wird nicht entfernt

Weg 1: /model bei kompatiblem Verlauf

Das Oh-My-Pi-README sagt ausdrücklich, dass /model das aktive Modell während einer Sitzung wechselt. Dieser Weg passt, wenn der vorhandene Kontext gebraucht wird und nichts darauf hindeutet, dass der Ziel-Provider alte Tool Calls, Reasoning-Blöcke oder multimodale Inhalte ablehnt.

Gehen Sie so vor:

1. Warten Sie auf das Ende der aktuellen Antwort oder brechen Sie sie ab. Wechseln Sie nicht, solange Tools laufen.
2. Geben Sie /model ein, wählen Sie Ziel-Provider und Zielmodell und weisen Sie es der aktiven Rolle zu.
3. Prüfen Sie Provider/Modell im Picker oder Status von Oh My Pi. Verlassen Sie sich nicht auf die Selbstauskunft des Modells.
4. Senden Sie eine reine Leseaufgabe, etwa eine bekannte Datei zu lesen und zwei überprüfbare Fakten zu nennen.
5. Führen Sie eine kleine Tool-Aufgabe aus. Setzen Sie die Langzeitaufgabe erst fort, wenn Tool Call, Tool-Ergebnis und der nächste Turn funktionieren.

Kommt schon beim ersten Request HTTP 400 zurück, wiederholen Sie nicht denselben Verlauf. Bewahren Sie Fehler und Export auf und wechseln Sie zu Fork plus Clear oder zu einer neuen Sitzung.

Weg 2: /fork für einen reversiblen Versuch

/fork erzeugt aus der aktuellen Sitzung eine neue Sitzungsdatei und wechselt zur neuen Identität. Die offizielle Dokumentation erklärt, dass ein vollständiger Fork Unterhaltung und Nutzungszuordnung erhält und das Artefaktverzeichnis bestmöglich kopiert. Die ursprüngliche Sitzung bleibt verfügbar und eignet sich damit als Referenz.

Ein vollständiger Fork kopiert jedoch den gesamten Verlauf. Liegt der Fehler im Verlauf, reproduziert /fork ihn allein nur erneut.

Nutzen Sie dann diese sicherere Reihenfolge:

1. /fork ausführen und die neue Sitzungsidentität bestätigen.
2. Im Fork /clear ausführen.
3. /model ausführen und das Zielmodell wählen.
4. Das Modell Projektanweisungen und OMP-HANDOFF.md lesen lassen.
5. Vor Schreibzugriffen mit einer Leseaufgabe prüfen.

/clear entfernt den Live- und Modellkontext, behält aber Sitzungs-ID, Titel, Arbeitsverzeichnis, Modelleinstellungen und Transcript-Datei. Es fügt ein reset_boundary hinzu; persistiertes JSONL und vollständige Exporte enthalten weiterhin den früheren Verlauf. So bleibt der Nachweis erhalten, ohne ihn an das neue Modell zu senden.

Wird /fork abgelehnt, warten Sie bis zum Ende des Streamings und prüfen Sie, ob die Sitzung persistent ist. Ein vollständiger Fork ist in einer rein speicherinternen Sitzung nicht verfügbar.

Weg 3: /new, wenn der alte Verlauf nicht mehr sicher ist

/new erstellt eine neue Identität und eine leere Unterhaltung. Die offizielle Referenz sagt, dass aktuelles Modell und Einstellungen bleiben, während Conversation Queues, Todo, Checkpoint, Tool-Zustand, geerbte Cache-Identität und Teile des Memory-Kontexts gelöscht werden. Soll auch das Modell wechseln, lautet die übliche Reihenfolge daher /new, dann /model.

Empfohlener Ablauf:

1. Sicherstellen, dass Export und Arbeitsbaum-Checkpoint vorhanden sind.
2. /new ausführen.
3. /model ausführen und Zielmodell wählen.
4. Projektanweisungen, relevante Dateien und OMP-HANDOFF.md lesen lassen.
5. Mit einer Leseprüfung beginnen, danach nur eine minimale Schreibänderung zulassen.
6. Ergebnis mit dem Git-Checkpoint und den früheren Prüfungen vergleichen.

Wenn das Wiederabspielen des Verlaufs Requests bereits zerstört, ist dieser Weg meist schneller als weitere Versuche. Verloren geht der automatische Chatkontext, nicht das Repository. Wichtige Fakten gehören in Code, Tests, Dokumentation und Übergabe.

/fresh bedeutet nicht „Verlauf entfernen“

Der Name ist missverständlich. Laut offizieller Referenz setzt /fresh den providerseitigen Stream-Zustand, zwischengespeicherte Session-Handles und Prompt-Cache-Zustand zurück, ohne das lokale Transcript zu verändern. Der nächste Turn wird aus der lokalen Unterhaltung rekonstruiert; sichtbare und model-facing Unterhaltung bleiben erhalten.

Daraus folgt:

• /fresh eignet sich für einen hängenden Stream, veralteten Prompt Cache oder eine abgewichene serverseitige Conversation-ID;
• alte Tool-Call-IDs, Reasoning-Signaturen oder Bilder, die der neue Provider nicht akzeptiert, werden nicht entfernt;
• „start a fresh session“ in einem Issue kann normales Englisch und nicht der Befehl /fresh sein. Für leeren Verlauf verwenden Sie /new; zum Erhalten des Originals bei abgeschnittenem Kontext /fork plus /clear.

Was zwei reale 400-Berichte zeigen

Ein Fehlerbild betrifft providerübergreifende Tool-Call-IDs. In Oh My Pi Issue #15056 reproduzierten Autor und Maintainer, dass eine signierte Vertex/Gemini-ID an ein OpenAI-kompatibles Chat-Completions-Ziel wiedergegeben wurde. Die ID überschritt dessen 64-Zeichen-Limit, der Request endete mit HTTP 400 und der ungültige Wert blieb im Verlauf.

Am 10. Oktober 2026 ist das Issue weiterhin offen; auch der vorgeschlagene Fix in PR #15059 ist offen. Der Kommentar „fix is up“ beweist nicht, dass die installierte Version den Fix enthält. Prüfen Sie Version oder Changelog; andernfalls stellen Sie mit sauberem Verlauf wieder her.

Issue #15015 beschrieb einen anderen Google-400-Fehler über einen HAI-Proxy und führte ihn auf ein historisches thoughtSignature zurück. Ein Maintainer erklärte, dass skip_thought_signature_validator absichtlich für unsignierte functionCall-Teile verwendet und von Googles öffentlicher API benötigt wird, während dieser Proxy den Wert schon vor Google ablehnte. Das Issue wurde mit wontfix geschlossen.

Die sinnvolle Schlussfolgerung ist nicht, dass jeder Wechsel zu Google scheitert. Derselbe 400 kann aus der Verlaufsumwandlung im Client oder aus einem zwischengeschalteten Gateway kommen. Erfassen Sie Provider, Modell, api, Endpoint, vollständigen Fehler und Herkunft des Verlaufs, bevor Sie zwischen sauberer Sitzung, Client-Update oder Proxy-Fix wählen.

Dasselbe Verfahren für einen eigenen OpenAI-kompatiblen Provider

Oh My Pi unterstützt eigene Provider in ~/.omp/agent/models.yml, auch mit api: openai-completions. Das README empfiehlt omp models <provider> zur Discovery-Prüfung, bevor das Modell über /model ausgewählt wird.

Die offizielle BetterToken-Chat-Completions-Dokumentation nennt beispielsweise https://www.bettertoken.ai/v1 als OpenAI-kompatible Base URL und https://www.bettertoken.ai/v1/chat/completions als vollständige Request-URL. Authentifiziert wird mit dem eigenen Bearer API Key; als Modell ist die aktuelle vollständige Model ID des Dienstes zu verwenden.

Betrachten Sie sie als protokollseitig passende Konfigurationsoption, nicht als Garantie für jedes Modell, jeden Tool Call oder alten Verlauf. Testen Sie in /new: zuerst einen kurzen Request ohne Tools, danach eine Leseaufgabe mit Tool. Der echte API Key gehört in eine geschützte Credential-Konfiguration, nicht in Chat, Export oder öffentliche Logs.

Der Wechsel von Base URL oder Provider behebt keinen 400, der bereits im Verlauf steckt. Isolieren Sie zuerst den Verlauf und testen Sie den neuen Endpoint separat.

Abschlussprüfung vor der langen Aufgabe

Machen Sie erst weiter, wenn alle Ergebnisse sichtbar sind:

• /export hat eine Datei an einem kontrollierten Ort erzeugt;
• der Arbeitsbaum besitzt einen wiederherstellbaren Checkpoint vor dem Wechsel;
• der gewählte Weg passt zum Ziel: gleiche Sitzung, reversibler Fork, bereinigter Kontext oder neue Sitzung;
• Oh My Pi zeigt den beabsichtigten Provider und das Modell;
• eine reine Lese-Tool-Aufgabe funktioniert und ihr Ergebnis erreicht den nächsten Turn;
• die Originalsession ist über /resume auffindbar oder bewusst verworfen worden;
• nach einem 400 sind Fehler, Version, Provider, Modell, api und Endpoint dokumentiert, statt unter Wiederholungen zu verschwinden.

Die Entscheidung ist einfach: Je wertvoller und eindeutig kompatibler der Verlauf ist, desto besser passt /model. Je größer das providerübergreifende Risiko, desto wichtiger ist es, die Originalsession zu erhalten und mit sauberem Kontext weiterzuarbeiten.