Imagina una taller mecánico. No usas una llave de impacto neumática para apretar un tornillo de gafas, ni un destornillador para sacar la rueda de un camión. Cada trabajo tiene la herramienta adecuada, y usar una demasiado costosa es un desperdicio; usar una demasiado débil implica volver a trabajar. Con una flota de subagentes es lo mismo: el rol del agente decide el modelo. Quien escanea 200 archivos requieren velocidad y bajo costo; quien razona sobre una decisión irreversible quieres el motor más potente. El mapa de abajo es el corazón de este módulo: una matriz función × modelo.
↑ La matriz rol × modelo: cada rol va en la columna del motor adecuado. La píldora destacada = opción predeterminada recomendada; línea discontinua = segunda opinión de otro proveedor.
Contenido detallado
🪜 Opus, Sonnet y Haiku — una escalera de roles
La familia Claude viene en tres tamaños, y cada uno tiene su punto ideal. Haiku es el operario veloz: escanea, busca, resume y lee documentación. Sonnet es el profesional del día a día: escribe código y revisa. Opus es el arquitecto: razona sobre decisiones difíciles, analiza la seguridad y piensa a fondo. No es «Opus es mejor, así que uso Opus para todo», sino «el rol requiere tal motor».
🔧 La regla del taller
El motor adecuado es el más barato que todavía cumple la función. Cambiar a un modelo superior sin necesidad es desperdiciar dinero y tiempo; bajar demasiado implica recibir un trabajo deficiente. Piensa en tres niveles:
- •Haiku — roles mecánicos y de gran volumen: recorrer, hacer grep, listar, resumir documentación extensa.
- •Sonnet — roles de oficio: escribir código, refactorizar, revisar un diff, generar pruebas.
- •Opus — roles de evaluación: arquitectura, seguridad, decisiones irreversibles, planes complejos.
Los tres niveles de la familia Claude organizados por rol, no preguntes "cuál es el mejor". Cada nivel intercambia costo y latencia por profundidad de razonamiento.
Toda la flota en Opus excede el presupuesto y se vuelve lenta; toda la flota en Haiku entrega un análisis superficial cuando hace falta criterio. La escalera evita ambos extremos.
Rol × motor · "lo más barato que cumple" · escalera Haiku → Sonnet → Opus.
🔀 GPT y Codex — el segundo proveedor
La flota no tiene que ser de una sola familia. Los modelos GPT y el entorno Codex (CLI de OpenAI, visto en el módulo 4.2) entran como un una segunda opinión: un revisor que piensa distinto del constructor. Las familias distintas cometen errores distintos, así que un hallazgo que dos los proveedores confirman que es mucho más confiable.
você > O Sonnet acabou de escrever este módulo de auth.
Peça a um revisor em GPT/Codex pra refutar:
onde isso quebra? Só os furos, sem reescrever.
# construtor (Sonnet) e revisor (outra família) erram
# de formas diferentes — a divergência é o valor.
# o que os DOIS apontam é o que merece atenção.🛰️ Por qué mezclar proveedores
Uno sesgo compartido es el enemigo: si el constructor y el revisor son el mismo modelo, tienden a «estar de acuerdo con su propio error». Cambiar de familia para el rol de revisor es la forma barata de conseguir independencia: el tema de verificación adversarial del módulo 4.1.
🌐 Otros proveedores — pensar en capacidades, no en marcas
Además de Anthropic y OpenAI, hay todo un mercado: Google (Gemini), modelos abiertos que se ejecutan localmente y proveedores especializados. El error es memorizar nombres; lo correcto es pensar en capacidad. Para tu matriz, todo modelo cae en una de tres clases, y asigna el rol a la categoría, no a la marca de la semana.
Clase «rápido y económico»
Haiku · modelos pequeños/locales
Alto volumen y poca necesidad de criterio: escanear, clasificar, extraer, resumir.
Clase «equilibrio»
Sonnet · GPT de uso general · Gemini Pro
El caballo de batalla: construir, revisar y resolver la mayoría de las tareas prácticas.
Clase «razonamiento profundo»
Opus · GPT de razonamiento · Gemini de vanguardia
Decisiones costosas e irreversibles: arquitectura, seguridad, planes largos.
📌 Piensa en espacios, no en nombres
Salen modelos nuevos todo el tiempo. Si tu matriz es por clase (rápido / equilibrio / razonamiento), cambiar el modelo de una celda solo requiere sustituir al ocupante del slot; la arquitectura de la flota no cambia. Eso es lo que mantiene vivo el sistema durante meses, no días.
⚖️ Razonamiento profundo × barato y rápido
Aquí está la tensión central. Modelo potente piensa más a fondo, pero cuesta más y tarda más. Un modelo ligero es barato e instantáneo, pero superficial. No hay almuerzo gratis: tú eliges dónde invertir profundidad. La pregunta operativa es sencilla: ¿es alto el costo de equivocarse en este rol? Si es así, sube. Si no, baja.
↑ Sube el modelo cuando…
- ↑El error es costoso o irreversible (seguridad, dinero, arquitectura)
- ↑La tarea requiere criterio y síntesis, no solo ejecución
- ↑El contexto es ambiguo y necesita una interpretación precisa
- ↑Es un único paso decisivo, no 200 repeticiones
↓ Baja el modelo cuando…
- ↓La tarea es mecánica y está bien definida (grep, listar, extraer)
- ↓El volumen es alto y cada paso es fácil de verificar
- ↓La latencia importa (esperas el resultado ahora)
- ↓Es fácil detectar y corregir los errores después
🔁 Cuándo cambiar de modelo o proveedor según el rol
Cambiar de modelo tiene un costo oculto: cada subagente empieza desde cero y necesita reunir el contexto de nuevo. Por eso el cambio compensa en tareas grandes, no en mensajes de 30 segundos. Y hay dos ejes de intercambio: cambiar de nivel (Haiku↔Sonnet↔Opus) por profundidad, y cambiar de proveedor (Claude↔GPT) por independencia.
El rol cambió de naturaleza
Pasar de ejecutar a decidir (o viceversa).
El agente que recorría ahora necesita completar qué camino seguir. Pasaste de "ejecución" a "criterio" → sube el modelo.
Quieres una mirada independiente
Revisar lo que construyó otro modelo.
El constructor es Claude; el revisor pasa a ser GPT/Codex. Cambio de proveedor en el rol de revisor para evitar el sesgo compartido.
El costo o la latencia se volvieron un problema
La cuenta subió o la espera te incomoda.
¿Ese papel voluminoso que se ejecuta en Sonnet podría estar en Haiku? Si es fácil comprobar el error, baja de modelo y ahorra, sin dudarlo.
⚠️ La trampa de «el subagente empieza en blanco»
Cada subagente reúne el contexto desde cero. Cambiar a un modelo costoso en un rol pequeño hace que el costo de «reunir contexto» se coma la ganancia. Cambiar de modelo da resultado cuando la tarea es lo suficientemente grande para amortizar ese arranque en frío; de lo contrario, es un desperdicio disfrazado de cuidado.
🚁 Flota heterogénea — el triángulo costo · latencia · calidad
El destino es una flota heterogénea: varios subagentes apuntando a modelos diferentes, cada uno en su rol. No es un sistema homogéneo de "todo Opus" ni "todo Haiku": es una mezcla diseñada. Y toda mezcla está sometida a tres fuerzas que tiran en direcciones opuestas: costo, latencia e calidad. No puedes maximizar las tres; las equilibra por rol.
| Papel | Modelo típico | Costo | Latencia | Calidad requerida |
|---|---|---|---|---|
| 🔍 escanear | haiku | bajo | bajísima | basta con un análisis superficial |
| 🧭 buscar | haiku | bajo | baja | basta con un análisis superficial |
| 🔨 construir | sonnet | medio | media | de oficio |
| 🔎 revisar | sonnet / GPT | medio | media | crítica |
| 🧠 razonamiento | opus | alto | alta | máxima |
| 🛡️ seguridad | opus + GPT | alto | alta | máxima |
↑ La misma matriz, ahora con el trade-off explícito en cada fila. Fíjate: cuando aumenta la calidad exigida, también aumentan el costo y la latencia, y eso solo se justifica en los roles críticos.
💡 "Elige 2 de 3" — por función
No es posible tener bajo costo, baja latencia y máxima calidad al mismo tiempo. Un rol de exploración acepta "barato + rápido" y renuncia a la profundidad; un rol de seguridad acepta "caro + lento" para obtener calidad. Una flota heterogénea consiste precisamente en tomar esta decisión rol por rol, en lugar de una única opción para todo.
Ejemplo real: una flota heterogénea en archivos
Una flota heterogénea no es un solo archivo: es un conjunto de subagentes, cada uno con su campo
model que apunta al motor de su función. A continuación, cuatro
.md recortados uno al lado del otro: fíjate cómo el rol
(en la description) e o modelo van juntos.
# ── file-scanner.md ─ papel: ESCANEAR (volumoso, raso) ──
name: file-scanner
description: Varre o repo e lista arquivos/símbolos
relevantes. Use para mapear antes de qualquer leitura.
tools: Grep, Glob # só localizar
model: haiku # barato + rápido
# ── builder.md ─ papel: CONSTRUIR (de ofício) ──────────
name: builder
description: Implementa a mudança descrita no plano.
tools: Read, Edit, Write, Bash
model: sonnet # equilíbrio
# ── arch-thinker.md ─ papel: RACIOCÍNIO (juízo) ────────
name: arch-thinker
description: Decide a arquitetura e os trade-offs de
uma mudança grande. Use ANTES de construir.
tools: Read, Grep
model: opus # raciocínio profundo
# ── cross-reviewer.md ─ papel: REVISAR (2º olhar) ──────
name: cross-reviewer
description: Refuta o trabalho do builder buscando
furos. Use após qualquer mudança sensível.
tools: Read, Grep
model: gpt-codex # OUTRA família = independência🧩 Qué cambia de un archivo a otro
- description — declara el papel (escanear / construir / razonar / revisar).
- model — sigue el rol: rol sencillo → haiku, evaluación → opus.
- tools — los roles de evaluación/revisión quedan en modo de solo lectura (Read, Grep).
- proveedor — el revisor cambia de familia a propósito.
🎯 Por qué esto es "heterogéneo"
- Cuatro agentes, tres motores diferentes + un proveedor externo.
- El costo total baja: el trabajo voluminoso se ejecuta en haiku.
- La calidad mejora donde importa: Opus para el razonamiento.
- La revisión es independiente: otra familia comete errores diferentes.
Prompts listos (copia y pega)
Tres prompts para el maestro distribuir modelos según el rol. El patrón es siempre nombrar el rol y justificar el motor: económico cuando se pueda, potente cuando haga falta, independiente durante la revisión.
Para este job, monte uma frota por papel: use Haiku pra
escanear e buscar, Sonnet pra construir e revisar, e Opus
só pro raciocínio de arquitetura. Justifique cada escolha
em uma linha (custo/latência/qualidade).O builder (Sonnet) terminou. Agora rode um revisor em
outro provedor (GPT/Codex) só pra refutar: liste os furos
que um modelo da MESMA família talvez não veja. Não
reescreva — só aponte.Revise minha frota: que papéis hoje em Sonnet poderiam
cair pra Haiku sem risco (erro barato de checar)? E que
papéis merecem subir pra Opus porque o erro seria caro?
Devolva só a matriz papel → modelo ajustada.Pantalla simulada: la flota heterogénea en ejecución
Así es como aparece la flota heterogénea en la terminal: cada subagente se ejecuta en el modelo de tu función, y la columna del medio muestra qué motor está usando cada uno. Fíjate en el costo relativo a la derecha: los roles con mucho volumen en Haiku cuestan casi nada; solo el razonamiento en Opus pesa en el costo.
↑ Recreación ilustrativa del terminal (no es una captura de pantalla real). Cada subagente usa el motor adecuado para su rol; el costo se concentra solo en el Opus del razonamiento.
Ejercicio — arma tu matriz función × modelo
Toma una trabajo real tuyo (un proyecto, una investigación, una migración) y diseña la flota: para cada uno de los seis roles — escanear, buscar, construir, revisar, razonar, seguridad — elige uno modelo y justifica la decisión con el triángulo costo · latencia · calidad.
Cómo hacerlo
- Lista los seis roles (usa la matriz de arriba como guía inicial).
- Para cada rol, elige el modelo:
haiku,sonnet,opuso con otro proveedor. - Escribe una línea por rol justificando: ¿el error aquí es costoso? ¿el volumen es alto? ¿importa la latencia?
- Marca al menos un rol que se beneficia de una 2.ª revisión de otro proveedor (y di por qué).
| Papel | Tu modelo | Justificación (1 línea) |
|---|---|---|
| 🔍 escanear | ______ | _______________________________ |
| 🧭 buscar | ______ | _______________________________ |
| 🔨 construir | ______ | _______________________________ |
| 🔎 revisar | ______ | _______________________________ |
| 🧠 razonamiento | ______ | _______________________________ |
| 🛡️ seguridad | ______ | _______________________________ |
✅ Criterio de verificación — cómo saber si acertaste
Tu matriz está bien diseñada si pasa estas cuatro pruebas:
- →No es homogénea: aparecen al menos dos modelos diferentes (si todo terminó siendo Opus o todo Haiku, vuelve a hacerlo).
- →Los roles críticos suben: el razonamiento y la seguridad usan el motor más potente de tu matriz.
- →Los roles de gran volumen bajan: escanear y buscar usan el motor más económico y rápido.
- →Hay una segunda opinión: al menos un rol de revisión/seguridad usa un proveedor diferente al del constructor.
Cada justificación debe citar al menos uno vértice del triángulo (costo, latencia o calidad). La justificación "porque es mejor" no cuenta.
Ejemplo resuelto (una línea)
Rol: 🛡️ seguridad · Modelo: opus + segunda mirada en GPT/Codex. Justificación: el error de seguridad es costoso e irreversible (la máxima calidad justifica un costo y una latencia altos); el 2.º proveedor ofrece independencia frente al sesgo compartido. Pasa las cuatro pruebas.
✅ Resumen del módulo
Próximo módulo:
4.4 — Seguridad. Descargar .md de terceros, prompt injection y el subagente verificador de solo lectura.