Cómo cambiar de modelo en Oh My Pi sin perder el progreso: /model, /fork o /new

Cambiar de modelo en una sesión larga de Oh My Pi no afecta solo a la calidad de las respuestas. El historial puede contener identificadores de herramientas, firmas de razonamiento, bloques de imagen u otros campos propios del proveedor anterior que la API de destino no pueda aceptar.

La regla más segura es: guarda por separado el progreso del código y la evidencia de la sesión, y lleva al nuevo modelo solo el historial que realmente necesite. Usa /model cuando el historial parezca compatible, /fork cuando necesites un experimento reversible y /fork seguido de /clear, o una sesión limpia con /new, cuando el historial anterior ya sea sospechoso.

Guarda dos puntos de control antes de cambiar

El transcript de la sesión no sustituye a Git, y Git no conserva el recorrido del agente. Protege ambas cosas.

1. Registra el estado del repositorio

Comprueba primero qué ha cambiado:

git status --short
git diff --stat

Crea un commit local, un parche u otro punto de recuperación aceptado por tu equipo. No se trata de publicar trabajo incompleto, sino de poder volver con precisión al estado anterior al cambio si el siguiente modelo toca archivos equivocados.

2. Exporta la sesión

Ejecuta /export. La referencia oficial de operaciones de sesión indica que la orden genera un archivo HTML sin modificar la sesión. La señal de éxito es la ruta que Oh My Pi imprime; la TUI normalmente también abre el archivo.

Trátalo como material sensible. La exportación HTML no está anonimizada ni cifrada y puede contener contexto completo, imágenes y datos de extensiones.

3. Prepara un traspaso breve

Añade temporalmente un OMP-HANDOFF.md al repositorio con:

• el objetivo actual y lo que ya está terminado;
• los archivos modificados;
• las verificaciones ejecutadas y sus resultados;
• el siguiente paso previsto;
• el error exacto, junto con el modelo, proveedor y ruta API afectados.

Una sesión limpia no necesita decenas de turnos copiados. Leer las instrucciones del proyecto y este resumen suele ser más fiable.

Elige la orden según el riesgo del historial

Situación	Ruta recomendada	Qué conserva	Principal límite
Mismo proveedor o modelo cercano, sin errores de protocolo	/model	Sesión e historial actuales	El destino recibe todo el historial anterior
Probar otro modelo y mantener intacto el original	/fork → /model	Sesión original y una rama con el historial	También copia cualquier incompatibilidad
Conservar el registro original sin reenviar el contexto antiguo	/fork → /clear → /model	Original intacto; la rama conserva trazabilidad tras el límite de reinicio	Hay que recuperar el objetivo desde el handoff
El historial ya produce 400 o el cambio cruza protocolos	/new → /model	El repositorio y la sesión antigua permanecen; la conversación nueva está vacía	No transfiere automáticamente todo, checkpoints ni estado de herramientas
Solo está bloqueado el stream o la conversación del servidor	/fresh	Conserva la conversación visible y la que recibe el modelo	No elimina historial incompatible

Ruta 1: /model cuando el historial es compatible

El README de Oh My Pi afirma expresamente que /model cambia el modelo activo en mitad de la sesión. Es la opción adecuada cuando necesitas el contexto existente y no hay señales de que el proveedor de destino vaya a rechazar llamadas a herramientas, bloques de razonamiento o contenido multimodal anteriores.

Sigue este orden:

1. Espera a que termine la respuesta actual o cancélala. No cambies mientras haya herramientas ejecutándose.
2. Escribe /model, selecciona el proveedor y el modelo de destino y asígnalo al rol activo.
3. Confirma el proveedor/modelo que muestra el selector o el estado de Oh My Pi. No uses la identidad que declara el propio modelo como prueba.
4. Envía una tarea de solo lectura, por ejemplo leer un archivo conocido y devolver dos datos verificables.
5. Ejecuta una tarea pequeña con herramientas. Continúa el trabajo largo solo si funcionan la llamada, su resultado y el turno siguiente.

Si la primera solicitud devuelve HTTP 400, deja de repetir el mismo historial. Conserva el error y la exportación, y pasa a una rama limpiada o a una sesión nueva.

Ruta 2: /fork para un experimento reversible

/fork crea un archivo de sesión nuevo a partir del actual y cambia la identidad activa. La documentación oficial explica que un fork completo conserva la conversación y la atribución de uso, e intenta copiar el directorio de artefactos. La sesión original sigue disponible, por lo que es una buena base para comparar modelos sin perder la referencia.

Sin embargo, un fork completo copia también todo el historial. Si el problema está en ese historial, /fork por sí solo lo reproduce.

Utiliza entonces esta secuencia:

1. Ejecuta /fork y comprueba que la nueva identidad de sesión está activa.
2. Dentro del fork, ejecuta /clear.
3. Ejecuta /model y elige el modelo de destino.
4. Pide al modelo que lea las instrucciones del proyecto y OMP-HANDOFF.md.
5. Valídalo con una tarea de solo lectura antes de permitir escrituras.

/clear elimina el contexto vivo y el que se envía al modelo, pero conserva el ID, el título, el directorio de trabajo, la configuración del modelo y el archivo transcript. Añade un reset_boundary; el JSONL persistente y una exportación completa siguen incluyendo el historial anterior. Así puedes conservar la evidencia sin reenviarla al modelo nuevo.

Si /fork es rechazado, espera a que termine el streaming y comprueba que la sesión es persistente. Un fork completo no está disponible en una sesión puramente en memoria.

Ruta 3: /new cuando el historial ya no es seguro

/new crea una identidad nueva con una conversación vacía. La referencia oficial indica que mantiene el modelo y la configuración actuales, pero borra las colas de conversación, todo, checkpoint, estado de herramientas, identidad de caché heredada y parte de la memoria promovida. Si también vas a cambiar de modelo, el orden habitual es /new y después /model.

Flujo recomendado:

1. Verifica que existen la exportación y el punto de control del repositorio.
2. Ejecuta /new.
3. Ejecuta /model y selecciona el modelo de destino.
4. Haz que lea las instrucciones del proyecto, los archivos pertinentes y OMP-HANDOFF.md.
5. Empieza con una comprobación de solo lectura y luego una escritura mínima.
6. Compara el resultado con el estado Git y las verificaciones anteriores al cambio.

Cuando la reproducción del historial ya rompe las solicitudes, este camino suele ser más rápido que insistir. Pierdes el contexto automático del chat, no los archivos del proyecto. Los hechos importantes deberían estar en el código, las pruebas, la documentación y el handoff.

/fresh no significa “eliminar el historial”

El nombre se presta a confusión. Según la referencia oficial, /fresh reinicia el estado del stream del proveedor, los manejadores de sesión remota y el estado relacionado con prompt cache sin tocar el transcript local. El turno siguiente se reconstruye desde la conversación local; se conservan tanto la conversación visible como la que recibe el modelo.

Por tanto:

• usa /fresh para un stream bloqueado, una caché obsoleta o un ID de conversación remota desviado;
• no esperes que elimine tool-call IDs, firmas de razonamiento o imágenes que el nuevo proveedor no admite;
• cuando un issue dice “start a fresh session”, puede estar usando inglés corriente, no la orden /fresh. Para historial vacío usa /new; para conservar el original y cortar el contexto usa /fork más /clear.

Qué demuestran dos errores 400 reales

Un modo de fallo afecta a los identificadores de llamadas a herramientas entre proveedores. En el issue #15056, el autor y un mantenedor reprodujeron cómo un ID firmado de Vertex/Gemini se reenviaba a un endpoint OpenAI-compatible de Chat Completions. El ID superaba el límite de 64 caracteres del destino, la solicitud devolvía HTTP 400 y el valor inválido seguía en el historial.

A fecha de 10 de octubre de 2026, el issue continúa abierto y la corrección propuesta en el PR #15059 también está abierta. Que un comentario diga “fix is up” no demuestra que tu versión instalada ya la incluya. Comprueba la versión o el changelog; de lo contrario, recupera con historial limpio.

El issue #15015 describió otro 400 de Google a través de un proxy HAI y lo atribuyó a un thoughtSignature histórico. Un mantenedor aclaró que skip_thought_signature_validator se usa deliberadamente para partes functionCall sin firma y que la API pública de Google lo necesita, mientras que aquel proxy lo rechazaba antes de llegar a Google. El issue se cerró con la etiqueta wontfix.

La conclusión útil no es que todos los cambios a Google fallen. Es que un mismo 400 puede proceder de la conversión del historial en el cliente o de una pasarela intermedia. Registra proveedor, modelo, api, endpoint, error completo y procedencia del historial antes de decidir entre sesión limpia, actualización del cliente o arreglo del proxy.

Aplicar el mismo método a un proveedor OpenAI-compatible personalizado

Oh My Pi admite proveedores personalizados en ~/.omp/agent/models.yml, incluido el tipo openai-completions. El README recomienda ejecutar omp models <provider> para verificar el descubrimiento antes de seleccionar el modelo con /model.

Por ejemplo, la documentación oficial de Chat Completions de BetterToken indica https://www.bettertoken.ai/v1 como Base URL OpenAI-compatible y https://www.bettertoken.ai/v1/chat/completions como URL completa. La autenticación usa el Bearer API Key del usuario y el modelo debe ser el Model ID completo y vigente del servicio.

Considérala una configuración compatible a nivel de protocolo, no una garantía para todos los modelos, herramientas o conversiones históricas. Pruébala en /new: primero una solicitud corta sin herramientas y después una tarea de solo lectura. Guarda la clave real en una configuración de credenciales protegida, no en el chat, la exportación o un log público.

Cambiar la Base URL o el proveedor no corrige un 400 que ya está incrustado en el historial. Aísla primero el historial y valida después el endpoint nuevo.

Comprobación final antes de retomar la tarea larga

No continúes hasta observar todo lo siguiente:

• /export ha producido un archivo guardado en una ubicación controlada;
• el repositorio tiene un punto de recuperación anterior al cambio;
• la ruta elegida corresponde al objetivo: misma sesión, fork reversible, contexto limpio o sesión nueva;
• Oh My Pi muestra el proveedor/modelo esperado;
• una tarea de solo lectura funciona y su resultado llega al siguiente turno;
• la sesión original sigue localizable con /resume, o has decidido expresamente no conservarla;
• después de un 400 se han registrado error, versión, proveedor, modelo, api y endpoint en vez de ocultarlos bajo reintentos.

La regla final es sencilla: cuanto más valioso y claramente compatible sea el historial, más sentido tiene /model. Cuanto mayor sea el riesgo entre proveedores, más importante es conservar la sesión original y continuar con contexto limpio.