Oh My Piでモデルを切り替えても進捗を失わない方法：/model・/fork・/new

長時間動かしてきたOh My Piのセッションでモデルを変えるとき、問題になるのは回答品質だけではありません。以前のプロバイダー固有のtool-call ID、reasoning signature、画像ブロックなどが履歴から再送され、切り替え先APIに拒否されることがあります。

安全な原則は明快です。コードの進捗とセッションの証拠を別々に保存し、新しいモデルには必要な履歴だけを渡します。 履歴に互換性がありそうなら/model、元の記録を残して比較したいなら/fork、すでに履歴が400エラーを起こしているなら/fork後の/clear、または/newを選びます。

切り替え前に二つのチェックポイントを作る

セッションのtranscriptはGitの代わりではなく、Gitもエージェントの作業経路を保存しません。両方を保護します。

1. ワークツリーの状態を記録する

まず変更内容を確認します。

git status --short
git diff --stat

その後、ローカルcommit、patch、またはチームで認められた復旧ポイントを作ります。未完成の変更を共有履歴へ押し込むことが目的ではありません。次のモデルが誤ったファイルを変更しても、切り替え前へ戻れる状態にするためです。

2. セッションをexportする

/exportを実行します。Oh My Piの公式セッション操作リファレンスによれば、このコマンドはセッションを変更せずにHTMLを生成します。成功したかどうかは、表示されたexport先のパスで確認できます。TUIでは通常、そのファイルも開かれます。

HTMLには注意が必要です。自動的な秘密情報の削除や暗号化はなく、生のコンテキスト、画像、extension payloadが含まれる可能性があります。公開issueへそのまま添付しないでください。

3. 短い引き継ぎファイルを作る

一時的なOMP-HANDOFF.mdをリポジトリに置き、次を記録します。

• 現在の目的と完了済みの作業
• 変更したファイル
• 実行済みの検証と結果
• 次に行う操作
• 正確なエラー全文、model、provider、API route

新しいセッションに数十ターン分の会話を貼り付ける必要はありません。プロジェクト指示、必要なファイル、この引き継ぎを読ませる方が管理しやすくなります。

履歴のリスクでコマンドを選ぶ

状況	推奨パス	残るもの	主な注意点
同じprovider内の近いモデルで、protocol errorがない	/model	現在のセッションと履歴	古い履歴は切り替え先にも送られる
元のセッションを残して別モデルを試したい	/fork → /model	元セッションと履歴付きの分岐	非互換履歴もコピーされる
元記録は残し、古いmodel contextは送信したくない	/fork → /clear → /model	元セッションは完全に残り、forkにはreset後の監査経路が残る	目的はhandoffから復元する必要がある
履歴がすでに400を返す、またはprovider/protocolをまたぐ	/new → /model	ワークツリーと旧セッションは残り、新しい会話は空	todo、checkpoint、tool stateは自動移行しない
provider streamやserver-side conversationだけが詰まった	/fresh	見えている会話とmodel-facing conversationを保持	非互換履歴は削除しない

パス1：互換性があるなら同じセッションで/model

Oh My PiのREADMEには、/modelでセッション途中のactive modelを切り替えられると明記されています。既存コンテキストが必要で、過去のtool calls、reasoning blocks、multimodal contentが切り替え先に拒否される兆候がない場合に使います。

手順は次のとおりです。

1. 現在の応答が終わるのを待つか、明示的に中止します。ツール実行中に切り替えないでください。
2. /modelを開き、target provider/modelを選び、active roleへ割り当てます。
3. Oh My Piのpickerまたはstatusで実際のprovider/modelを確認します。モデル自身の名乗りは検証になりません。
4. 既知のファイルを読み、確認可能な事実を二つ返すようなread-only taskを送ります。
5. 小さなtool taskを一つ実行します。tool call、結果、次のturnがすべて正常な場合だけ本作業へ戻ります。

最初のrequestでHTTP 400が出たら、同じ履歴を繰り返しretryしないでください。エラーとexportを保存し、fork後にclearするか、新しいセッションへ移ります。

パス2：戻せる実験には/fork

/forkは現在のセッションから新しいsession fileを作り、active identityを切り替えます。公式ドキュメントでは、full forkが会話とusage attributionを保持し、artifact directoryをbest effortでコピーすると説明されています。元セッションは残るため、モデル比較や検証に向いています。

ただし、full forkは履歴全体もコピーします。問題が履歴にある場合、/forkだけでは同じエラーを再現します。

より安全な順序は次のとおりです。

1. /forkを実行し、新しいsession identityへ移ったことを確認します。
2. fork内で/clearを実行します。
3. /modelでtarget modelを選びます。
4. プロジェクト指示とOMP-HANDOFF.mdを読ませます。
5. 書き込みを許可する前にread-only taskで検証します。

/clearはlive/model conversation contextを削除しますが、session ID、title、working directory、model settings、transcript fileは保持します。さらにreset_boundaryを追加し、persisted JSONLと完全exportには以前の履歴が残ります。証拠を残しつつ、新モデルへの再送だけを止められます。

/forkが拒否された場合は、streaming終了を待ち、セッションがpersistentか確認します。完全なsession forkは純粋なin-memory sessionでは使えません。

パス3：古い履歴が危険なら/new

/newは新しいidentityと空の会話を作ります。公式リファレンスでは、現在のmodelとsettingsは維持されますが、conversation queues、todo、checkpoint、tool state、inherited cache identity、promoted memory contextの一部は消去されると説明されています。モデルも変える場合は、通常/newの後に/modelを実行します。

復旧手順は次のとおりです。

1. exportとワークツリーのcheckpointが存在することを確認します。
2. /newを実行します。
3. /modelでtarget modelを選びます。
4. プロジェクト指示、必要なファイル、OMP-HANDOFF.mdを読ませます。
5. 最初にread-only check、その後に最小の書き込みを行わせます。
6. 結果を切り替え前のGit checkpointと検証結果に照らして確認します。

履歴のreplayがすでにrequestを壊しているなら、retryを続けるよりこの方法が速いことが多いです。失うのは自動で渡されるchat contextであり、リポジトリではありません。重要な事実はコード、tests、docs、handoffに残します。

/freshは「履歴を消す」コマンドではない

名前から誤解しやすい点です。公式リファレンスによれば、/freshはprovider-facing stream state、cached provider-session handles、prompt-cache stateをリセットしますが、local transcriptには触れません。次のturnはローカル会話から再構築され、visible conversationとmodel-facing conversationの両方が残ります。

したがって、次のように使い分けます。

• wedged stream、stale prompt cache、ずれたserver-side conversation IDには/fresh
• 新providerが受け付けない古いtool-call ID、reasoning signature、画像を消す目的には使わない
• issue内の“start a fresh session”は一般的な英語であり、/freshコマンドを意味するとは限らない。空履歴なら/new、元記録を残してcontextを切るなら/forkと/clear

二つの実在する400エラーから分かること

一つ目はproviderをまたぐtool-call IDです。Oh My Piのissue #15056では、Vertex/Geminiのsigned tool-call IDがOpenAI-compatible Chat Completionsへreplayされる現象を報告者とmaintainerが再現しました。IDは切り替え先の64文字上限を超え、HTTP 400になり、無効値が履歴に残りました。

2026年10月10日時点でissueはopenで、提案修正のPR #15059もopenです。コメントに“fix is up”とあっても、使用中のversionへ取り込まれた証拠にはなりません。versionまたはchangelogを確認し、不明ならclean historyで復旧してください。

二つ目のissue #15015は、HAI proxy経由のGoogle 400を古いthoughtSignatureに関連付けていました。Maintainerは、skip_thought_signature_validatorがunsigned functionCall partsに意図的に使われ、Googleのpublic APIでは必要であり、そのproxyがGoogle到達前に拒否していたと説明しました。Issueはwontfix label付きでcloseされています。

結論は「Googleへの切り替えはすべて壊れる」ではありません。同じ400でも、client側のhistory conversionと中間gatewayのどちらからも起こり得ます。 実際のprovider、model、api、endpoint、完全なerror、history pathを記録してから、clean session、client update、proxy fixのどれが必要か判断します。

Custom OpenAI-compatible providerでも同じ考え方を使う

Oh My Piは~/.omp/agent/models.ymlでcustom providerを定義でき、api: openai-completionsも使用できます。READMEは、/modelで選ぶ前にomp models <provider>でdiscoveryを確認するよう案内しています。

例えばBetterTokenの公式Chat Completionsドキュメントは、OpenAI-compatible Base URLをhttps://www.bettertoken.ai/v1、完全なrequest URLをhttps://www.bettertoken.ai/v1/chat/completionsとしています。認証にはユーザー自身のBearer API Keyを使い、modelにはサービスで現在表示される完全なModel IDを指定します。

Protocol上設定可能な候補として扱い、すべてのmodel、tool call、古いhistoryへの互換性を保証しないでください。/newで、最初はtoolなしの短いrequest、次にread-only tool requestを試します。実際のAPI Keyは保護されたcredential configurationへ置き、chat、export、公開logには残しません。

Base URLやproviderを変えても、session historyにすでに埋め込まれた400は直りません。先にhistoryを隔離し、新endpointは別に検証します。

長い作業へ戻る前の最終確認

次の結果がすべて確認できるまで本作業へ戻らないでください。

• /exportが管理された場所にファイルを作成した
• ワークツリーに切り替え前へ戻れるcheckpointがある
• 選択したパスが目的に合う：同じsession、戻せるfork、clean context、新しいsession
• Oh My Piに意図したprovider/modelが表示される
• read-only tool taskが成功し、その結果が次のturnへ届く
• 元セッションが/resumeで見つかる、または保存しないことを明確に決めた
• 400発生時にerror、version、provider、model、api、endpointを記録し、retryで証拠を埋めていない

判断基準は単純です。履歴の価値が高く、互換性が明確なほど/modelが適します。Providerをまたぐリスクが高いほど、元セッションを保存し、clean contextで続けることが重要です。