Modelos por agente
Política multiproveedor vigente
El arnés selecciona modelos por agente y por tarea, no por fidelidad a un proveedor. Trabaja solo con suscripciones: Claude (plan Max), OpenAI (plan Plus) y Kimi Code. No hay vías de pago por token. Claude se usa únicamente a través de su herramienta oficial de línea de comandos; OpenAI y Kimi Code, a través del runner de OpenCode, sin añadir código al motor. El motor conserva un contrato común para los agentes y delega la ejecución en runners intercambiables.
Desde el 2026-09-20 los ocho agentes comparten exactamente la misma cadena: el mismo modelo principal para todos y el mismo respaldo para todos. No hay reparto por rol ni por etapa. La configuración es declarativa: cambiar la cadena de un agente es un cambio de política revisable, no una reescritura de su contrato ni del núcleo del motor.
La composición de la cadena se revisa según la disponibilidad real de cada suscripción: una vía cuyo cupo esté consumido no aporta respaldo, y permanece fuera hasta que vuelve a estar disponible. La tabla de abajo refleja siempre la configuración en vigor.
El orden de la cadena sigue la capacidad de cada vía. Primero va Claude, que hace casi todo el trabajo. Después va OpenAI, cuyo modelo tiene una capacidad comparable. Kimi Code va en último lugar, como red final. Dentro de OpenAI se usa el modelo que más veces termina dentro del plazo en este arnés y no el que encabeza los rankings por unas décimas, porque el respaldo entra justo cuando algo ya ha fallado y en ese momento importa más cerrar el turno a tiempo.
Regla de degradación
Un agente solo puede caer a un modelo de clase inferior si alguien verifica su salida antes de un sello del ciclo. La regla no impide ampliar la red de respaldo: una vía adicional que mantenga o eleve la clase del modelo es una escalada, no una degradación.
Con la cadena vigente la regla queda satisfecha por construcción, porque todos los agentes parten del mismo modelo: no hay ningún rol trabajando con una clase inferior a la de otro, ni en criterio ni en implementación.
Por qué una sola cadena para todos
La política anterior repartía a los agentes entre proveedores para que dos roles de una misma etapa no consumieran a la vez la misma capacidad. Ese reparto se retiró al comprobar, sobre el histórico de ejecución del arnés, que el coste real no está donde se suponía.
Lo caro no es cambiar de vía, sino una vía que acepta el encargo y no lo cierra dentro del plazo: entonces se consume la ventana completa a cambio de nada. Y ahí aparecieron dos lecciones que han moldeado la política vigente.
La primera es que la fiabilidad depende del rol y del plazo, no del proveedor. Una media agregada por proveedor puede ser cierta y a la vez llevar a la decisión contraria a la correcta: un modelo que rinde mal en un rol con plazo corto puede ser el mejor en otro de plazo largo. Desde entonces, ninguna asignación se decide con un promedio: se desagrega por rol antes de mover nada.
La segunda es que un modelo que parece más económico puede no serlo. El que tiene más capacidad suele resolver la misma tarea en menos vueltas, y menos vueltas significan menos tiempo y menos consumo. Medido en el arnés, el modelo de mayor capacidad gastaba cuatro veces menos por turno que el intermedio, además de cerrar antes. De ahí que los ocho agentes partan hoy del mismo modelo, el de arriba, y no de uno repartido por perfiles.
Los plazos son techos, no duraciones
Cada agente tiene un plazo máximo por turno. Es un techo: un turno que termina en ocho minutos termina en ocho minutos aunque su plazo sea de cuarenta y cinco. Un plazo holgado no ralentiza el ciclo; lo único que hace es impedir que se tire trabajo casi terminado cuando una tarea resulta más larga de lo previsto. Los roles de implementación, que son los de turnos más largos, trabajan con los plazos más amplios.
Tabla vigente por agente
| Agente | Perfil | Defecto | Respaldo | Tercera vía | Si se agota |
|---|---|---|---|---|---|
| Director | criterio fino | Claude Opus · Claude | GPT-5.6 Terra · OpenAI | Kimi K3-256K · Kimi Code | Para y avisa |
| PO | criterio fino | Claude Opus · Claude | GPT-5.6 Terra · OpenAI | Kimi K3-256K · Kimi Code | Para y avisa |
| Arquitecto | criterio fino | Claude Opus · Claude | GPT-5.6 Terra · OpenAI | Kimi K3-256K · Kimi Code | Para y avisa |
| QA | criterio fino | Claude Opus · Claude | GPT-5.6 Terra · OpenAI | Kimi K3-256K · Kimi Code | Para y avisa |
| Backend | implementación | Claude Opus · Claude | GPT-5.6 Terra · OpenAI | Kimi K3-256K · Kimi Code | Para y avisa |
| Frontend | implementación | Claude Opus · Claude | GPT-5.6 Terra · OpenAI | Kimi K3-256K · Kimi Code | Para y avisa |
| UX | creativo | Claude Opus · Claude | GPT-5.6 Terra · OpenAI | Kimi K3-256K · Kimi Code | Para y avisa |
| SRE | operativo | Claude Opus · Claude | GPT-5.6 Terra · OpenAI | Kimi K3-256K · Kimi Code | Para y avisa |
Todos los agentes disponen de las mismas vías, incluida la Dirección, que hasta el 2026-09-20 se detenía tras el respaldo y era el único punto capaz de parar el ciclo entero por agotamiento. Si la cadena se agota entera, el encargo no se degrada ni se inventa un resultado: el ciclo espera, lo reintenta con la misma cadena y solo tras varios intentos se detiene y avisa a una persona. La tabla refleja la configuración vigente del arnés y queda trazada en el manifest, la web y los ficheros para LLM del manual.