Switch Models in Oh My Pi Without Losing Progress: /model, /fork, or /new

Switching models in a long-running Oh My Pi session is not only a question of response quality. Old provider-specific tool-call IDs, reasoning signatures, image blocks, or other history fields may be replayed to a target API that cannot accept them.

The safest rule is simple: save code progress and session evidence separately, then carry only as much history as the target model needs. Use /model when the history is likely compatible, /fork when you need a reversible experiment, and /fork plus /clear or a clean /new session when the old history is already suspect.

Save two checkpoints before switching

A session transcript is not a Git checkpoint, and a Git checkpoint does not preserve the reasoning trail. Protect both.

1. Record the working tree

Start by seeing exactly what has changed:

git status --short
git diff --stat

Create a local commit, patch, or other team-approved recovery point. The goal is not to force unfinished work into shared history. It is to make the pre-switch state recoverable if the next model edits the wrong files.

2. Export the session

Run /export. Oh My Pi’s session operations reference says this produces an HTML file without mutating the session. The observable success signal is the printed export path; the TUI normally opens the file as well.

Treat that file as sensitive. The official reference warns that HTML export is not secret-redacted or encrypted and may contain raw context, images, and extension payloads.

3. Write a small handoff file

Add a temporary OMP-HANDOFF.md to the repository with:

• the current objective and completed work;
• files changed;
• checks already run and their results;
• the next intended step;
• the exact error, plus the model, provider, and API route involved.

A clean session does not need dozens of pasted chat turns. Reading project instructions and this short handoff is usually more controllable.

Choose the command from the history risk

Situation	Recommended path	What it preserves	Main caveat
Same provider or closely related model, no protocol errors	/model	Current session and history	The target still receives old history
Try another model while keeping the original session intact	/fork → /model	Original session plus a history-bearing branch	Incompatible history is copied too
Keep the original record but stop replaying old model context	/fork → /clear → /model	Original session; fork retains an audit trail after a reset boundary	Restore task intent from the handoff
History already produces 400s, or provider/protocol risk is high	/new → /model	Working tree and old session file remain; new conversation is empty	Todo, checkpoint, and tool state do not transfer automatically
Only the provider stream or server-side conversation state is wedged	/fresh	Visible and model-facing conversation stay intact	It does not remove incompatible history

Path 1: use /model when the history is compatible

The Oh My Pi README explicitly says that /model swaps the active model mid-session. Use it when you need the existing context and have no reason to expect the target provider to reject prior tool calls, reasoning blocks, or multimodal content.

Follow this order:

1. Let the current response finish, or abort it. Do not switch while tools are still running.
2. Enter /model, choose the target provider and model, and assign it to the active role.
3. Confirm the provider/model shown by Oh My Pi’s picker or status. Do not rely on the model’s self-reported identity.
4. Send a read-only task, such as reading one known file and returning two verifiable facts.
5. Run one small tool task. Continue the long job only if the tool call, tool result, and next model turn all work.

If the first request returns HTTP 400, stop retrying the same history. Preserve the error and export, then move to a fork-and-clear or new-session path.

Path 2: use /fork for a reversible experiment

/fork creates a new session file from the current session and switches the active identity to it. The official session reference says a full fork preserves the conversation and usage attribution and copies the artifact directory on a best-effort basis. The original session remains available, which makes this the right default for an auditable model comparison.

A full fork also copies the full history. If the history itself is incompatible, fork alone will reproduce the problem.

Use this safer sequence instead:

1. Run /fork and confirm that a new session identity is active.
2. Run /clear inside the fork.
3. Run /model and select the target model.
4. Have the model read project instructions and OMP-HANDOFF.md.
5. Validate with a read-only task before permitting writes.

/clear removes the live/model conversation context in place, while retaining the session ID, title, working directory, model settings, and transcript file. It appends a reset_boundary; persisted JSONL and full-transcript exports still retain the earlier history. That combination keeps the original evidence while preventing the target model from receiving the pre-boundary context.

If /fork is rejected, wait for streaming to stop and ensure the session is persistent. A whole-session fork is unavailable for a purely in-memory session.

Path 3: use /new when the old history is already unsafe

/new creates a new conversation identity and an empty conversation. The official reference says it keeps the current model and settings but clears conversation queues, todo/checkpoint/tool state, inherited cache identity, and some promoted memory context. If the target model is different, the usual sequence is therefore /new followed by /model.

A reliable recovery flow is:

1. Confirm that the export and working-tree checkpoint exist.
2. Run /new.
3. Run /model and choose the target model.
4. Ask it to read project instructions, the relevant files, and OMP-HANDOFF.md.
5. Start with a read-only check, then one minimal write.
6. Compare the result with the pre-switch Git checkpoint and previous verification output.

This is usually the fastest recovery once replayed history is causing failures. You lose automatic chat context, not the repository. Important facts should already live in code, tests, project documentation, and the handoff file.

/fresh does not mean “remove the history”

The name is easy to misread. According to the official session reference, /fresh resets provider-facing stream state, cached provider-session handles, and related prompt-cache state without touching the local transcript. The next turn rebuilds from the local conversation, and both the visible and model-facing conversation remain.

That makes the boundaries clear:

• Try /fresh for a wedged stream, stale prompt cache, or drifted server-side conversation ID.
• Do not expect it to remove old tool-call IDs, reasoning signatures, or image content that a new provider cannot accept.
• An issue saying “start a fresh session” in ordinary English does not necessarily mean the /fresh command. For empty history, use /new; to keep the original record while cutting model context, use /fork and /clear.

What two real 400 reports actually show

One failure mode involves cross-provider tool-call IDs. In Oh My Pi issue #15056, the reporter and a maintainer reproduced a Vertex/Gemini signed tool-call ID being replayed to an OpenAI-compatible Chat Completions target. The ID exceeded the target’s 64-character limit, so the request returned HTTP 400, and the invalid value stayed in history.

As of October 10, 2026, the issue remains open and the proposed fix in PR #15059 is also open. A comment saying “fix is up” does not prove that the fix is in the version you run. Check the installed version or changelog; otherwise recover with clean history.

A second report, issue #15015, described a Google 400 through an HAI proxy and blamed a historical thoughtSignature. A maintainer clarified that skip_thought_signature_validator is deliberately used for unsigned functionCall parts and is required by Google’s public API, while that particular proxy rejected it before the request reached Google. The issue was closed with a wontfix label.

The useful conclusion is not “Google switching is broken.” It is that the same 400 can come from client-side history conversion or from an intermediary gateway. Capture the real provider, model, api, endpoint, full error, and history path before choosing between a clean session, a client update, or a proxy fix.

Applying the same workflow to a custom OpenAI-compatible provider

Oh My Pi supports custom providers in ~/.omp/agent/models.yml, including the openai-completions API type. Its README recommends running omp models <provider> to verify discovery before selecting the model through /model.

For example, BetterToken’s official Chat Completions documentation lists https://www.bettertoken.ai/v1 as the OpenAI-compatible Base URL and https://www.bettertoken.ai/v1/chat/completions as the full request URL. Authentication uses the user’s Bearer API Key, and the model must be the current full Model ID shown by the service.

Treat it as a protocol-matching configuration candidate, not a promise that every model, tool call, or historical conversion will work. Test it in /new: first a short request with no tools, then a read-only tool request. Keep the real API key in protected credential configuration, not in chat, exports, or public logs.

Changing a Base URL or provider does not repair a 400 already encoded in session history. Isolate the history first, then validate the new endpoint independently.

Final checks before resuming the long task

Do not continue until these results are observable:

• /export produced a file stored in a controlled location;
• the working tree has a recoverable pre-switch checkpoint;
• the chosen path matches the goal: same session, reversible branch, cleared context, or new session;
• Oh My Pi displays the intended provider/model rather than only receiving a self-identification from the model;
• one read-only tool task succeeds and its result reaches the next model turn;
• the original session can still be found through /resume, or you deliberately chose not to keep using it;
• after a 400, the error, version, provider, model, api, and endpoint are recorded instead of being buried under retries.

The decision rule is straightforward: the more valuable and clearly compatible the history is, the more sense /model makes. The higher the cross-provider risk, the more important it is to preserve the original session and continue with clean context.