Anatomía de un AI router de cuatro tiers

El 60% de los mensajes a tu chatbot son "gracias", "ok", "perfecto"

Si mides los mensajes reales que llegan a un chatbot de producción, vas a encontrar una distribución brutal: el 60% es acknowledgment trivial, el 30% es pregunta de bajo contexto, el 8% requiere razonamiento real, y el 2% son los casos críticos donde un error sale caro. Pagar Opus 4.7 (~$15/MTok output según la documentación oficial de precios de Anthropic) para responder "de nada" a alguien que dijo "gracias" es indefendible. Y sin embargo lo hace la mayoría de los chatbots que usan "un solo modelo bueno".

¿Cómo saber si tu arquitectura necesita un router de modelos o basta con uno solo?

Necesitas un router de modelos si tu sistema supera los 3,000 mensajes diarios y el costo de inferencia impacta el margen unitario, o bien cuando la latencia en interacciones triviales degrada la retención del usuario. Si tu tráfico es menor o estrictamente uniforme, la sobrecarga de mantener múltiples integraciones superará el ahorro económico obtenido.

En operaciones empresariales en América Latina, este umbral se vuelve aún más sensible. Dado que la facturación de las APIs de modelos de lenguaje se liquida en dólares estadounidenses mientras que los ingresos de los negocios suelen estar denominados en monedas locales sujetas a volatilidad cambiaria, reducir el consumo innecesario de tokens no es una optimización marginal: es la diferencia entre la viabilidad financiera o el cierre de un canal conversacional automatizado.

El router de cuatro tiers

El patrón que SCRAM corre en producción tiene cuatro niveles, cada uno con un modelo distinto calibrado para un equilibrio específico entre costo, velocidad y capacidad cognitiva:

• Tier 0 — Gemini 3 Flash: acknowledgments, despedidas, "ok/gracias/perfecto". $0.075/MTok input (fuente: Google Cloud Pricing). Latencia p50 ~300ms según registros de telemetría de SCRAM.
• Tier 1 — gpt-4o-mini: clasificación intent, extracción de slots, FAQ con RAG simple. $0.15/MTok input (fuente: OpenAI Pricing). ~600ms.
• Tier 2 — Claude Sonnet 4.6: conversación útil, SPIN selling, manejo de objeciones, RAG complejo. $3/MTok input (fuente: Anthropic Pricing). ~1.2s.
• Tier 3 — Claude Opus 4.7: razonamiento crítico, debugging técnico, planning multi-step, casos donde un error cuesta más que el modelo. $15/MTok input (fuente: Anthropic Pricing). ~2.5s.

Comparativa operativa de tiers para ruteo dinámico

Tier	Modelo asignado	Costo Input (USD/MTok)	Latencia p50	Criterio de activación	Caso de uso principal
Tier 0	Gemini 3 Flash	$0.075	~300ms	<= 2 palabras o regex de cortesía	Agradecimientos, confirmaciones, despedidas
Tier 1	gpt-4o-mini	$0.15	~600ms	<= 12 palabras sin objeciones en contexto	Extracción de entidades, navegación y FAQs
Tier 2	Claude Sonnet 4.6	$3.00	~1.2s	Default para consultas abiertas complejas	Manejo de objeciones de venta y síntesis RAG
Tier 3	Claude Opus 4.7	$15.00	~2.5s	Deal alto valor en CRM o falla crítica detectada	Negociaciones avanzadas y soporte técnico raíz

determineTier: la función que decide

type Tier = 0 | 1 | 2 | 3;

function determineTier(message: string, ctx: Context): Tier {
  const trimmed = message.trim().toLowerCase();
  const wordCount = trimmed.split(/\s+/).length;

  // Tier 0: acknowledgment puro
  const ackPatterns = /^(gracias|ok|listo|perfecto|sale|va|si|no|excelente)[.!]?$/;
  if (ackPatterns.test(trimmed) || wordCount <= 2) return 0;

  // Tier 3: señales de criticidad
  if (ctx.isHighValueDeal || ctx.isEscalated) return 3;
  if (/error|stack trace|no funciona|urgente|critic/i.test(message) && wordCount > 15) return 3;

  // Tier 1: preguntas cortas con baja complejidad
  if (wordCount < 12 && !ctx.hasOpenObjection) return 1;

  // Tier 2: default productivo
  return 2;
}

Las señales que importan en producción: longitud del mensaje, presencia de keywords técnicos, valor del deal en el CRM, etapa del funnel. No te compliques con clasificadores ML: una función pura con heurísticas explícitas es 5ms, debugeable y la puedes ajustar viendo logs.

Métricas reales de ahorro

En un chatbot con 12,000 mensajes/día y 60% acknowledgments antes del router (mediciones tomadas en infraestructura de clientes de SCRAM AI Lab):

• Sin router (todo a Sonnet 4.6): ~$48/día en inferencia.
• Con router de 4 tiers: ~$14/día. Ahorro 70%.
• Con router + prompt caching en tier 2/3: ~$9/día. Ahorro 81%.

La sorpresa: la calidad percibida sube, no baja. Los mensajes de tier 0 responden en 300ms en lugar de 2s, lo que da al usuario sensación de fluidez. Los de tier 3 reciben razonamiento real en lugar del compromiso mediocre de un modelo "para todo".

Fallbacks entre tiers

Cada tier tiene fallback al siguiente superior si: (a) el provider devuelve 429/529, (b) latencia rebasa SLO, (c) el modelo expresó duda ("no estoy seguro" en la respuesta, detectable con un patrón corto). El fallback no es retry; es escalar. Y se loguea: si el 15% de los tier 1 escala a tier 2, tu clasificación está mal calibrada.

Por qué no usar Opus para todo

Aparte del costo, hay un tema de latencia. Opus 4.7 a ~2.5s de TTFT es genial para razonamiento, pero para "¿cuál es su horario?" se siente lento. La percepción de inteligencia en un chatbot está dominada por fluidez en lo trivial y profundidad en lo importante. Un router te da las dos. Un solo modelo te da una a costa de la otra.

Particularidades de implementación en canales conversacionales de LATAM

En el mercado hispanohablante, más del 80% de las interacciones automatizadas ocurren a través de canales como WhatsApp Business API o mensajería web móvil. Este entorno introduce dos factores clave que alteran el comportamiento del router:

• Micro-mensajería fragmentada: el usuario promedio envía ideas divididas en tres o cuatro mensajes sucesivos de una o dos palabras (por ejemplo: "hola", "tienen stock?", "de la roja"). Si el router evalúa de forma aislada cada entrada, enviará el primer mensaje a Tier 0, el segundo a Tier 1 y perderá el hilo contextual. La solución técnica es implementar un debouncer en el backend que acumule ráfagas de mensajes durante 1,500 milisegundos antes de invocar a determineTier.
• Sensibilidad a la latencia en red móvil: las redes 4G variables provocan que tiempos de respuesta superiores a 3 segundos provoquen doble envío de mensajes por parte del usuario o abandono de la sesión. Al despachar el 90% del volumen combinado (Tiers 0 y 1) con latencias bajo los 600ms, se compensa la degradación de red inherente a la infraestructura regional.

Lo que se rompe en producción

• Drift de clasificación: con el tiempo los usuarios usan vocabulario que tu router no anticipó. Revisa logs semanales.
• Personalidades distintas por tier: Sonnet y gpt-4o-mini tienen tonos diferentes; un usuario que pase de tier 1 a tier 2 nota el cambio. Mantén system prompts consistentes en voz.
• Métricas separadas: latencia y costo POR TIER, no agregadas. El agregado oculta dónde está el problema.
• Sobrecarga por rate limits en picos de tráfico: si concentras todo el Tier 0 en una sola clave API sin cuotas elevadas, un pico de cortesías puede tirar el servicio completo; ten siempre un modelo de respaldo idéntico o mantén un pool de proveedores.

¿Cuántos de los mensajes de tu chatbot del último mes eran "gracias"? Si no lo sabes, ese es el primer dato que vale la pena medir antes de discutir routers.