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을 만듭니다. 성공 여부는 출력된 파일 경로로 확인할 수 있으며, TUI에서는 보통 파일도 열립니다.

이 HTML은 민감한 디버깅 자료로 다뤄야 합니다. 자동 비밀정보 제거 또는 암호화가 적용되지 않고 원본 컨텍스트, 이미지, extension payload가 포함될 수 있습니다.

3. 짧은 handoff 작성

저장소에 임시 OMP-HANDOFF.md를 만들고 다음을 적습니다.

• 현재 목표와 완료한 작업
• 변경한 파일
• 실행한 검증과 결과
• 다음에 할 일
• 정확한 오류 전문, model, provider, API route

새 세션에 수십 개의 채팅 turn을 복사할 필요는 없습니다. 프로젝트 지침, 관련 파일, 이 handoff를 읽히는 방식이 더 통제하기 쉽습니다.

기록 위험에 따라 명령 선택

상황	권장 경로	보존되는 것	주요 주의점
동일 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 또는 서버 세션만 멈춤	/fresh	보이는 대화와 model-facing 대화 모두 유지	비호환 기록은 제거하지 않음

경로 1: 기록이 호환되면 같은 세션에서 /model

Oh My Pi README는 /model로 세션 중간에 active model을 바꿀 수 있다고 명시합니다. 기존 컨텍스트가 필요하고, 대상 공급자가 이전 tool calls, reasoning blocks, multimodal content를 거부할 이유가 없을 때 사용합니다.

다음 순서로 진행합니다.

1. 현재 응답이 끝날 때까지 기다리거나 중단합니다. 도구 실행 중에는 전환하지 않습니다.
2. /model을 열고 대상 provider/model을 선택해 active role에 할당합니다.
3. Oh My Pi picker 또는 status에 표시된 provider/model을 확인합니다. 모델의 자기소개를 검증 수단으로 쓰지 않습니다.
4. 알려진 파일 하나를 읽고 확인 가능한 사실 두 개를 반환하는 식의 읽기 전용 작업을 보냅니다.
5. 작은 tool task를 하나 실행합니다. Tool call, 결과, 다음 turn이 모두 정상일 때만 긴 작업을 재개합니다.

첫 request부터 HTTP 400이 나오면 같은 기록으로 반복하지 마십시오. 오류와 export를 보존한 다음 fork-and-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로 대상 모델을 선택합니다.
4. 프로젝트 지침과 OMP-HANDOFF.md를 읽힙니다.
5. 쓰기를 허용하기 전에 읽기 전용 작업으로 검증합니다.

/clear는 live/model conversation context를 지우지만 session ID, title, working directory, model settings, transcript file은 유지합니다. reset_boundary를 추가하고, persisted JSONL과 full export에는 이전 기록이 남습니다. 증거는 보존하면서 새 모델에 과거 컨텍스트를 보내지 않을 수 있습니다.

/fork가 거부되면 streaming이 끝날 때까지 기다리고 세션이 persistent인지 확인합니다. 전체 세션 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로 대상 모델을 선택합니다.
4. 프로젝트 지침, 관련 파일, OMP-HANDOFF.md를 읽힙니다.
5. 읽기 전용 검증부터 시작한 뒤 최소한의 쓰기를 수행합니다.
6. 결과를 전환 전 Git checkpoint와 기존 검증 결과에 비교합니다.

기록 replay가 이미 요청을 망가뜨린다면 반복 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이 모두 남습니다.

따라서:

• 멈춘 stream, stale prompt cache, 어긋난 server-side conversation ID에는 /fresh
• 새 provider가 받지 못하는 오래된 tool-call ID, reasoning signature, 이미지 제거 용도로는 사용하지 않음
• Issue의 “start a fresh session”은 일반 영어 표현일 수 있으며 /fresh 명령을 뜻하지 않을 수 있음. 빈 기록은 /new, 원본 보존과 컨텍스트 차단은 /fork 후 /clear

실제 400 사례 두 개가 알려 주는 점

첫 번째 실패 방식은 공급자 간 tool-call ID입니다. Oh My Pi issue #15056에서 reporter와 maintainer는 Vertex/Gemini의 signed tool-call ID가 OpenAI-compatible Chat Completions 대상으로 replay되는 현상을 재현했습니다. ID가 대상의 64자 제한을 넘었고 요청은 HTTP 400으로 실패했으며 잘못된 값이 기록에 남았습니다.

2026년 10월 10일 기준 issue는 open이고 제안된 수정 PR #15059도 open입니다. 댓글의 “fix is up”만으로 설치 버전에 수정이 포함됐다고 볼 수 없습니다. 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로 닫혔습니다.

유용한 결론은 “Google 전환은 모두 고장났다”가 아닙니다. 같은 400도 client-side history conversion 또는 intermediary gateway에서 생길 수 있습니다. Clean session, client update, proxy fix 중 무엇이 필요한지 결정하기 전에 실제 provider, model, api, endpoint, 전체 error, history path를 기록합니다.

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, 다음으로 읽기 전용 tool request를 시험합니다. 실제 API Key는 보호된 credential configuration에 두고 chat, export, public log에 남기지 않습니다.

Base URL이나 provider를 바꾼다고 session history에 이미 포함된 400이 복구되지는 않습니다. 기록을 먼저 격리하고 새 endpoint는 별도로 검증합니다.

긴 작업을 재개하기 전 최종 확인

다음 결과가 모두 보일 때만 계속합니다.

• /export가 통제된 위치에 파일을 만들었다
• 작업 트리에 전환 전으로 돌아갈 수 있는 checkpoint가 있다
• 선택한 경로가 목표와 맞다: 같은 session, 되돌릴 수 있는 fork, cleared context, new session
• Oh My Pi가 의도한 provider/model을 표시한다
• 읽기 전용 tool task가 성공하고 결과가 다음 turn에 전달된다
• 원래 세션을 /resume으로 찾을 수 있거나 더 이상 쓰지 않기로 명확히 결정했다
• 400 뒤에 error, version, provider, model, api, endpoint를 기록했고 retry로 증거를 덮지 않았다

판단 기준은 간단합니다. 기록의 가치가 높고 호환성이 명확할수록 /model이 적합합니다. 공급자를 넘는 위험이 클수록 원본 세션을 보존하고 clean context로 이어 가는 것이 중요합니다.