Как сменить модель в Oh My Pi и не потерять прогресс: /model, /fork или /new

В длинной сессии Oh My Pi смена модели — это не только вопрос качества ответа. В истории могут остаться provider-specific ID вызовов инструментов, reasoning signatures, изображения и другие поля, которые новый API не принимает.

Надёжный принцип такой: отдельно сохраните состояние репозитория и доказуемую историю сессии, а новой модели передайте только нужный объём контекста. Если история совместима, достаточно /model. Для обратимого эксперимента лучше начать с /fork. Если история уже вызывает 400, используйте /fork → /clear либо чистую сессию через /new.

Перед переключением сохраните две контрольные точки

История чата не заменяет Git, а Git не сохраняет ход работы агента. Нужны обе опоры.

1. Зафиксируйте состояние рабочей копии

Сначала посмотрите, какие файлы изменены и каков объём diff:

git status --short
git diff --stat

Затем сделайте локальный commit, patch или другой принятый в команде checkpoint. Смысл не в том, чтобы публиковать незавершённую работу, а в возможности точно вернуться к состоянию до смены модели.

2. Экспортируйте сессию

Выполните /export. В официальном описании операций с сессиями указано, что команда создаёт HTML и не меняет сессию. Успешный результат виден сразу: Oh My Pi печатает путь к файлу, а TUI обычно открывает его.

Храните экспорт как чувствительный отладочный файл. Он не проходит автоматическое удаление секретов и не шифруется; внутри могут быть исходный контекст, изображения и данные extensions.

3. Подготовьте короткий handoff

Создайте временный OMP-HANDOFF.md и запишите:

• текущую цель и уже выполненную часть;
• изменённые файлы;
• выполненные проверки и результаты;
• ближайший следующий шаг;
• полный текст ошибки, model, provider и API route, на котором она возникла.

Новой сессии обычно не нужен многословный пересказ десятков сообщений. Ей достаточно перечитать инструкции проекта, нужные файлы и этот handoff.

Выберите команду по риску истории

Ситуация	Рекомендуемый путь	Что сохранится	Главное ограничение
Меняется модель внутри того же provider, протокольных ошибок нет	/model	Текущая сессия и весь контекст	Новая модель получает старую историю
Нужен эксперимент с возможностью вернуться к оригиналу	/fork → /model	Исходная сессия и отдельная ветка с историей	Несовместимая история тоже копируется
Исходная запись нужна, но старый контекст нельзя отправлять новой модели	/fork → /clear → /model	Оригинал остаётся целым; в fork сохраняется audit trail	Цель задачи надо восстановить из handoff
История уже даёт 400 или меняется provider/API family	/new → /model	Рабочая копия и старая сессия остаются; новый чат пуст	todo, checkpoint и tool state не переносятся автоматически
Завис только provider stream или server-side conversation	/fresh	Видимая и model-facing история остаются	Несовместимую историю команда не удаляет

Вариант 1: /model в той же сессии

README Oh My Pi прямо говорит, что /model меняет активную модель посреди сессии. Этот вариант подходит, когда старый контекст нужен и нет признаков того, что новый provider отвергнет прежние tool calls, reasoning blocks или мультимедийные части.

Порядок действий:

1. Дождитесь окончания текущего ответа либо остановите его. Не переключайтесь во время работы инструментов.
2. Введите /model, выберите provider/model и назначьте модель активной роли.
3. Проверьте model и provider в picker или статусе Oh My Pi. Не используйте самопрезентацию модели как доказательство маршрута.
4. Дайте read-only задачу: например, прочитать известный файл и назвать два проверяемых факта.
5. Запустите один небольшой tool-вызов. Продолжайте долгую работу только после того, как вызов, tool result и следующий ответ прошли нормально.

Если первый запрос возвращает HTTP 400, не повторяйте его в той же истории. Сохраните ошибку и экспорт, затем переходите к fork с очисткой или к новой сессии.

Вариант 2: /fork для обратимого эксперимента

/fork создаёт новый файл сессии из текущего и переключает активную identity на него. Официальная документация говорит, что полный fork сохраняет разговор и attribution использования, а каталог artifacts копируется best effort. Оригинальная сессия остаётся доступной, поэтому этот путь удобен для сравнения моделей и разбора результата.

Но полный fork переносит всю историю. Если проблема находится в ней, один /fork лишь воспроизведёт ошибку.

Безопасная последовательность:

1. Выполните /fork и убедитесь, что активна новая identity.
2. В fork выполните /clear.
3. Затем вызовите /model и выберите целевую модель.
4. Попросите модель прочитать инструкции проекта и OMP-HANDOFF.md.
5. Начните с read-only проверки и только потом разрешайте запись.

/clear удаляет live/model context, но сохраняет session ID, заголовок, cwd, настройки модели и transcript file. Команда добавляет reset_boundary; предыдущая история остаётся в persisted JSONL и полном экспорте. Так исходные данные можно проверить позже, а новая модель не получает контекст до границы.

Если /fork отклонён, дождитесь завершения streaming и проверьте, что сессия сохраняется на диск. Полный fork недоступен для чисто in-memory session.

Вариант 3: /new, если история уже небезопасна

/new создаёт новую identity и пустой разговор. По официальному описанию текущая модель и настройки сохраняются, но очищаются conversation queues, todo, checkpoint, tool state, inherited cache identity и часть memory context. Поэтому при переходе на другую модель обычно нужен порядок /new, затем /model.

Рабочая схема восстановления:

1. Проверьте, что экспорт и checkpoint рабочей копии уже существуют.
2. Выполните /new.
3. Через /model выберите целевую модель.
4. Дайте ей прочитать инструкции проекта, нужные файлы и OMP-HANDOFF.md.
5. Сначала проведите read-only проверку, затем одну минимальную запись.
6. Сравните результат с Git-состоянием и тестами до переключения.

Когда replay истории уже ломает запросы, это обычно быстрее бесконечных повторов. Вы теряете автоматически передаваемый чат, а не файлы проекта. Существенные факты должны быть в коде, тестах, документации и handoff.

/fresh не очищает историю

Название легко понять неправильно. Согласно официальному описанию, /fresh сбрасывает provider-facing stream state, cached session handles и связанные prompt-cache данные, не трогая локальный transcript. Следующий запрос снова строится из локального разговора; видимый и model-facing context сохраняются.

Практическая граница:

• /fresh полезен при зависшем stream, stale prompt cache или сбившемся server-side conversation ID;
• команда не удалит старые tool-call ID, reasoning signatures или изображения, несовместимые с новым provider;
• фраза “start a fresh session” в issue — обычный английский текст, а не обязательно команда /fresh. Для пустой истории используйте /new; чтобы сохранить оригинал и отсечь контекст, примените /fork и /clear.

Что показывают два реальных отчёта об ошибке 400

Первая проблема связана с ID вызовов инструментов. В Oh My Pi issue #15056 автор и maintainer воспроизвели replay подписанного Vertex/Gemini tool-call ID в OpenAI-compatible Chat Completions. ID оказался длиннее лимита цели в 64 символа, запрос вернул HTTP 400, а некорректное значение осталось в истории.

На 10 октября 2026 года issue остаётся open, а исправление в PR #15059 тоже ещё open. Фраза “fix is up” в комментарии не означает, что исправление уже есть в установленной версии. Проверьте version/changelog; при сомнении восстанавливайтесь на чистой истории.

Во втором случае, issue #15015, Google 400 возникал через HAI proxy. Maintainer объяснил, что skip_thought_signature_validator намеренно используется для unsigned functionCall и требуется публичному Google API, а конкретный proxy отклонял значение до отправки запроса в Google. Issue закрыли с label wontfix.

Вывод: одинаковый 400 может появиться из-за преобразования истории в клиенте или из-за промежуточного gateway. Перед лечением запишите фактические provider, model, api, endpoint, полный текст ошибки и путь истории.

Та же схема для custom OpenAI-compatible provider

Oh My Pi позволяет объявлять custom provider в ~/.omp/agent/models.yml, в том числе с api: openai-completions. README рекомендует сначала выполнить omp models <provider> и проверить discovery, а затем выбирать модель через /model.

Например, официальная документация BetterToken Chat Completions указывает OpenAI-compatible Base URL https://www.bettertoken.ai/v1 и полный адрес https://www.bettertoken.ai/v1/chat/completions. Для авторизации используется собственный Bearer API Key пользователя, а model должен быть полным актуальным Model ID сервиса.

Это конфигурация, совместимая по заявленному протоколу, а не обещание совместимости каждого model, tool call и старой истории. Проверяйте её в /new: сначала короткий запрос без инструментов, затем read-only tool request. Реальный API Key храните в защищённой credential configuration, а не в чате, экспорте или публичном логе.

Смена Base URL или provider не исправляет 400, уже записанный в истории. Сначала изолируйте историю, затем отдельно проверяйте новый endpoint.

Финальная проверка перед продолжением

Продолжайте длинную задачу только когда видны все результаты:

• /export создал файл, и он хранится в контролируемом месте;
• рабочая копия имеет восстанавливаемый checkpoint до переключения;
• выбранный путь соответствует цели: та же сессия, обратимый fork, очищенный context или новая session;
• Oh My Pi показывает нужный provider/model;
• один read-only tool request прошёл, а его результат попал в следующий ответ;
• исходную сессию можно найти через /resume, либо вы осознанно отказались от неё;
• после 400 сохранены error, version, provider, model, api и endpoint, а не только серия повторных попыток.

Правило выбора короткое: чем ценнее и понятнее совместимость истории, тем уместнее /model. Чем выше риск смены provider, тем важнее оставить оригинальную сессию и продолжить с чистым контекстом.