Un modelo por fase: cambio automático de modelo en pi

Un modelo para todo tipo de trabajo es la concesión que dejaste de notar. Explorar pide un cerebro distinto que construir. El harness debería cambiarlo por ti, no obligarte a acordarte.

Eliges un modelo al empezar la sesión y después lo usas para todo. Lo usas para explorar un código que no conoces, para planificar un cambio, para escribir el código, para revisar el diff, para arreglar lo que encontró la review. Son cinco trabajos distintos, y se los diste todos a un solo modelo, con una configuración que elegiste antes de saber cómo iba a ser el trabajo.

Eso es una concesión, y te cuesta por los dos lados. En las fases fáciles pagas de más, corriendo un modelo fuerte y caro para una exploración que uno barato resuelve bien. En las fases difíciles piensas de menos, corriendo el último modelo que seleccionaste en vez del modelo cuidadoso que el trabajo merece. Me cansé de pagar ese impuesto, así que metí el cambio dentro del harness. Así es como lo hice, y por qué pertenece ahí.

Un modelo para todo es una concesión

Piensa en lo que realmente pide cada fase.

Explorar pide un modelo barato, con una atención amplia y dispersa y bastante presupuesto de razonamiento. Va a leer mucho y no se va a comprometer con nada. Construir pide lo contrario: un modelo de código preciso que toma un plan aprobado y lo ejecuta con poca ceremonia y poco overhead de razonamiento. Revisar pide un modelo escéptico con esfuerzo alto, buscando lo que se va a romper. Arreglar vuelve a pedir precisión, con un alcance acotado.

Corre un solo modelo en las cinco y no le queda bien a ninguna. No es una ineficiencia menor. A lo largo de una semana de trabajo real, es la diferencia entre una cuenta que te molesta y una que olvidas, y entre una review que atrapa el bug y una que lo deja pasar.

✗

Un modelo, todas las fases

1. 01Pagas de más corriendo un modelo fuerte en la exploración
2. 02Piensas de menos cuando la fase difícil recibe tu modelo por defecto
3. 03Te olvidas de cambiarlo, así que el modelo casi nunca encaja con el trabajo
4. 04El presupuesto de razonamiento falla para los dos lados

✓

Un modelo por fase

1. 01Un modelo barato recorre el código mientras exploras
2. 02Un modelo preciso ejecuta la construcción
3. 03Un modelo cuidadoso con esfuerzo alto hace la review
4. 04El cambio ocurre solo, siempre

OpenCode lo resolvió bien con los modes

La herramienta que me enseñó esto fue OpenCode. Su valor real no está en los modelos que trae, sino en la idea de los modes. Defines un conjunto de agentes con nombre, y cada uno tiene su propio modelo, su propia temperatura, su propio tope de pasos, sus propios permisos. Cambias de mode y toda la configuración cambia con él.

Esta es la forma de mi propio setup, recortada a lo esencial:

Modes, cada uno con su modelo

Explore lee y no puede editar. Build recibe un modelo de código con temperatura baja y puede escribir. El mode es la unidad, y cambiarlo lo cambia todo.

Mode	Modelo	Temp	¿Puede editar?
explore	glm-5.1	0.7	no
plan	deepseek-v4-pro	0.2	no
build	kimi-k2.6	0.1	sí
review	glm-5.1	0.0	no
fix	deepseek-v4-pro	0.1	sí

El mode es la unidad de trabajo. Cámbialo y obtienes el modelo correcto, la creatividad correcta y los permisos correctos en un solo movimiento. Te impide explorar con tu modelo de build y dejar que tu modelo de exploración lleve código a producción. La configuración completa, y por qué terminé volviendo a Claude Code, está en OpenCode vs Claude Code.

pi no tiene nada de esto. pi es un loop y un comando /model que manejas a mano. Uso pi como mi agente de todos los días exactamente por las razones de la guía de pi: es mínimo y puedes verlo entero. Pero mínimo significaba que no tenía modes, y manejar /model a mano significaba que me olvidaba, todo el tiempo. Así que construí la pieza que faltaba.

Así que conecté los cambios en pi

pi-skill-model-handoff es un paquete chico para pi. Lee dos campos de cualquier skill que cargues y los aplica en el instante en que la skill se activa: el modelo y el nivel de razonamiento.

La idea clave es que el trabajo ya se anuncia a través de una skill. Cuando empiezas a revisar, cargas tu skill de review. Cuando empiezas a construir, cargas tu skill de build. La skill ya sabe qué tipo de trabajo es, así que el modelo y el esfuerzo de razonamiento le corresponden a la skill. Ponlos ahí una vez y el harness hace el cambio automáticamente cada vez que la skill se carga. Dejas de tratar la elección de modelo como una tarea aparte.

Configúralo en tres pasos

• ✓Obligatorio:
  Instala el paqueteCorre pi install npm:@felipefontoura/pi-skill-model-handoff y después /reload o reinicia pi.
• ✓Obligatorio:
  Agrega model y thinking a cada skillDos campos opcionales en el frontmatter del SKILL.md de la skill. Apunta cada fase al modelo y al presupuesto de razonamiento que se merece.
• ✓Obligatorio:
  Carga una skill y mira el cambiopi imprime handoff active: <skill> en el momento en que cambia. El cambio es visible, no magia a tus espaldas.

La configuración vive en el frontmatter de la skill. Dos campos, ambos opcionales:

---
name: review
description: Review code changes.
model: openai/gpt-5.5
thinking: high
---

model es cualquier modelo con prefijo de proveedor al que pi pueda llegar. thinking es uno de off, minimal, low, medium, high, xhigh. Esa es toda la interfaz. Ningún archivo de configuración que mantener, ningún router que entender. La skill que ibas a cargar de todos modos ahora trae su propio modelo y su propio esfuerzo.

Qué pasa cuando se carga una skill

Entrada

Cargas la skill para el trabajo que tienes enfrente

↓

1. READLeer los dos campos

   El paquete lee model y thinking del frontmatter de la skill mientras se activa.

   ↓
2. SWITCHAplicar modelo y esfuerzo

   Define el modelo activo y el presupuesto de razonamiento para los turnos que siguen. No cambia nada más.

   ↓
3. CONFIRMImprimir el cambio

   pi muestra handoff active: <skill>, para que veas que el cambio ocurrió y a qué.

↓

Salida

El modelo sigue al trabajo y no vuelves a tocar /model

Este es el mapa de cambios que uso, las mismas fases que OpenCode te da como modes, expresadas como skills:

Un ejemplo de mapa de cambios

Los modelos los eliges tú. El punto es que la fase los lleva consigo, así que explorar barato y construir con precisión dejan de ser una decisión que te olvidas de tomar.

Skill / fase	Modelo	Esfuerzo
explore	opencode-go/glm-5.1	high
plan	anthropic/claude-sonnet-4-5	high
build	anthropic/claude-sonnet-4-5	minimal
review	openai/gpt-5.5	high
fix	openai/gpt-5.5	medium

Atarlo a skills y no a modes, a propósito

Un mode es un concepto en el que tienes que acordarte de entrar. Es una cosa más que gestionar al lado del trabajo real. Una skill no. Cargas una skill porque el trabajo la pidió, así que colgar el modelo y el esfuerzo de la skill hace que el ruteo venga incluido. No hay un interruptor aparte para activar y olvidar.

Es una perilla menos, y una perilla menos es toda la filosofía de diseño sobre la que está construido pi. El mejor control es el que no tienes que acordarte de usar.

Siendo honesto sobre lo que no hace

Si quieres un sistema que lea tu mensaje y elija la skill solo, esto no es eso, y yo desconfiaría de la versión que sí lo es. En el momento en que un harness empieza a adivinar en qué fase estás, vuelves a depurar una caja negra que decidió algo por ti. Prefiero cargar la skill yo mismo y saber exactamente en qué se va a convertir el modelo.

Esto es harness engineering, no un truco de plugin

El paquete es chico. El punto no es el paquete. El ruteo de modelos es un mecanismo de control, una de las partes que componen un harness, y lo agregué como unas pocas líneas que puedo leer en vez de esperar a que un proveedor meta modes en una herramienta que no controlo. Ese es todo el argumento de harness engineering: el modelo es un commodity, y la ventaja está en el código que pones a su alrededor.

También hay un dividendo en costos. Rutea un modelo barato para explorar y uno fuerte solo para construir, y los turnos de exploración dejan de cobrarte tarifa premium por trabajo que nunca la necesitó. Es la misma pelea que el resto de la cuenta de tokens, dada en la capa de ruteo. Un harness mínimo no perdió contra el lleno de features. Me dejó agregar el único control que quería y saltarme los veinte que no.

Cambio de modelo, respuestas rápidas

¿Qué hace pi-skill-model-handoff?+

Es un paquete de pi que cambia automáticamente el modelo activo y el esfuerzo de razonamiento cuando cargas una skill. Cada skill declara un modelo y un nivel de thinking en el frontmatter de su SKILL.md, y el paquete los aplica en el momento en que la skill se activa, imprimiendo handoff active: <skill> para que el cambio sea visible.

¿Cómo lo instalo?+

Corre pi install npm:@felipefontoura/pi-skill-model-handoff y después /reload o reinicia pi. Luego agrega los campos opcionales model y thinking al frontmatter de cualquier skill y el cambio ocurre al cargarla.

¿Qué valores puedo usar para el nivel de thinking?+

Uno de off, minimal, low, medium, high o xhigh. Combina un nivel alto con las fases de exploración y review, donde el razonamiento rinde, y un nivel low o minimal con la construcción, donde el plan ya está hecho y quieres una ejecución rápida y precisa.

¿Elige la skill por mí según mi prompt?+

No, y es a propósito. El paquete es pasivo. pi sigue decidiendo qué skill se carga; el paquete solo aplica el modelo y el esfuerzo después de que se selecciona la skill.

Un ruteo que lee tu prompt y adivina la fase volvería a meter una caja negra en el loop. Tú eliges la fase, el harness se encarga del cambio mecánico.

¿En qué se diferencia de los modes de OpenCode?+

OpenCode tiene modes como concepto integrado: agentes con nombre que llevan cada uno un modelo, una temperatura y permisos. pi no tiene modes. Este paquete te da el mismo ruteo de modelo por fase, pero atado a las skills que ya cargas, como un paquete open source chico que puedes leer y modificar, en vez de una feature que esperas que lance un proveedor.