Modelos por fase

La idea: no todas las fases necesitan el mismo cerebro. Un análisis técnico flojo se paga en todas las fases siguientes; unas pruebas mecánicas no necesitan el modelo más caro. kbspec lo vuelve configuración del equipo — y después mide si se cumplió.

Clases, no nombres

Los nombres de modelo caducan cada pocos meses; las clases no. kbspec razona con tres:

Clase	Para qué	Fases
razonamiento	Sacar lo que el usuario no dijo, criterios, arquitectura	1–4 (captura → plan)
equilibrado	Ejecutar contra un plan ya escrito; clasificar hallazgos	5, 7, 8
rapido	Lo mecánico y verificable — si sale mal, sale mal ruidosamente	6 (pruebas)

El porqué de cada fase está escrito en aplicaciones/MODELOS.md, editable por el equipo. kb modelo 3 te lo cuenta para una fase puntual.

Mapear los modelos reales

El framework no controla el selector de VS Code, así que recomienda, avisa y mide — y desde 3.150 hace las dos cosas que VS Code sí permite: abre cada chat nuevo con el modelo de la fase y lo escribe en los botones «siguiente paso» de los agentes. Los nombres exactos los ves en el selector de modelo de VS Code; para el nombre canónico están las páginas oficiales de GitHub Copilot y Anthropic. Y la tabla se llena sin editar markdown:

kb modelo --mapear razonamiento --copilot "Claude Opus 5" --claude "Opus"

En cuanto la tabla tiene tus modelos, kb update regenera los agentes de fase con el modelo ya elegido. La skill /kb-modelo guía todo esto desde el chat.

Y con qué llenar las clases hoy —qué modelos, cuánto cuesta cada uno por millón de tokens y cuántos créditos consume un requerimiento con cada opción— está en Modelos recomendados y su costo.

Y cambiarlo, cuando la fase lo pida

kbspec fija el modelo de cada fase al abrirla y lo propone siempre al empezarla: la línea «Modelo» de kb estado y el agente, que lo dice en una línea al arrancar. Pero el selector es del developer, y cambiarlo está permitido —una fase puede necesitar uno más fuerte para razonar, o uno más económico para ejecutar—. Con otro modelo, kbspec lo avisa una vez por sesión, lo deja en el rastro con el modelo recomendado y el usado, y no frena nada. Eso es lo que un supervisor pregunta —con qué modelo se hizo cada fase y si cambió—, respondido sin bloquear a nadie.

Si un equipo o el área de TI quieren impedir el cambio, existe modelo_por_fase: exigir en aplicaciones/IA.md (o ModeloPorFase en la política de la máquina): con otro modelo no se escribe. Es una decisión explícita, no viene de fábrica, y el motivo de la negación dice cómo dejar de frenar.

Declarado vs. medido — la distinción que importa

Hay dos fuentes, y kbspec no las mezcla:

• Declarado: el agente anota con qué modelo cerró cada fase. Es su palabra.
• Medido: el consumo registra, desde la telemetría real, qué modelo corrió de verdad en cada fase. Es el dato.

kb modelo --revisar cruza lo medido contra lo recomendado:

✗ 3. Análisis técnico   usó rapido, pero esta fase recomienda RAZONAMIENTO
      el resultado puede estar flojo; revisalo o rehacelo con un modelo de esa clase

Los cuatro estados de la revisión

Estado	Significa	Qué hacer
ok	Al menos una corrida de la fase usó la clase recomendada (o superior)	Nada
por-debajo	La fase corrió solo con clases inferiores — sale con código 2	Revisar o rehacer la fase con la clase que pide
sin-clasificar	Se usó un modelo que no está en MODELOS.md	Mapearlo, y usar la clase recomendada
sin-medición	No hay consumo para esa fase — no se puede detectar	El comando recomienda qué clase elegir

Donde no puede detectar, no adivina: recomienda. Ese es el contrato.

Y el lazo se cierra con datos propios

kb metricas cruza el modelo de cada fase contra los defectos que salieron. A los pocos meses la recomendación deja de venir de un benchmark ajeno: si en la fase 5 el modelo barato no genera más defectos, se baja la recomendación y se ahorra de verdad; si sale caro, queda probado. La tabla de MODELOS.md es un punto de partida, no una verdad.

Validado al iniciar

Reportado desde un cliente: los nombres de MODELOS.md no existían en su Copilot y nadie lo supo hasta que el agente corrió con otro modelo. Desde 3.151, kb init valida antes de crear nada:

1. Trae las tarifas y el catálogo publicados por GitHub una vez por día (es la tarifa y, a la vez, la lista de modelos válidos). Solo entran filas nuevas en PRECIOS.md; lo que el equipo ya tenía no se pisa. Sin red, sigue con lo que hay y lo dice.
2. Valida cada nombre de MODELOS.md contra ese catálogo y contra lo que VS Code ofrece en la máquina (la extensión deja la lista real en ~/.kb/modelos-copilot.json; una política de la organización puede apagar modelos que la tabla sí tiene).
3. Si una clase queda sin ningún modelo válido, no inicia y sugiere el nombre parecido:

✗ equilibrado   Claude Sonnet 5.1   no está en el catálogo de Copilot — ¿quisiste decir «Claude Sonnet 4.5»?
✗ no inicio: la clase equilibrado no tiene ningún modelo válido para Copilot …

Un nombre inválido entre varios avisa y sigue; la tabla de ejemplo avisa que los agentes no fijan modelo; kb abrir avisa y nunca frena. kb modelo --validar corre lo mismo a demanda y kb check tiene la fila modelos.

El modelo de la fase, puesto por la extensión

VS Code no deja que un agente cambie el modelo de una conversación, pero sí permite abrir un chat con un modelo dado y declararlo en los handoffs. kbspec usa las dos vías: el chat nuevo que abre al cerrar una tarea o una fase lleva el modelo que MODELOS.md pide para esa fase (elegido entre los que VS Code ofrece; si no está, no se inventa y queda el del selector), y los botones «siguiente paso» de cada agente llevan model: 'Nombre (copilot)' de la fase destino. Y si de todas formas se trabaja con una clase más cara de la que la fase pide, kb estado, kb tarea --iniciar y kb pruebas lo dicen con cuánto más cuesta.