Cómo funciona la selección de modelo
El LLM Router (packages/core/src/ai/router.ts) resuelve el provider y el modelo de cada llamada a partir del TenantTaskModelConfig, por tipo de tarea:
| Tipo de tarea | Default típico |
|---|---|
| chat_tutor | clase Sonnet |
| chat_evaluation / summarization / supervisor | clase Haiku |
| content_generation | clase Haiku |
| course_review / course_agent / gamification_agent | clase Sonnet |
El admin institucional puede sobrescribir cualquier tarea para otro provider/modelo. Ningún model ID está hardcoded en los agentes — el router es el único punto de decisión.
Métodos del router
stream()— chat con streaming (metered).generate()— agentes con tools (metered); las tools se convierten de JSON Schema al formato AI SDK, por lo que funcionan en cualquier provider.generateDirect()— llamadas background fire-and-forget (evaluation, content, summarizer, supervisor) que se ejecutan en elafter()de Next.js sin el pipeline completo de metering.
Fallback chain + circuit breaker
Por tier: Claude → GPT → Grok → Gemini (LLMs); Voyage → OpenAI → Cohere (embeddings). Un circuit breaker en Redis se abre tras un límite de fallos y es compartido entre instancias, de modo que un breaker abierto omite el provider problemático sin timeout. Los incidentes se registran para observabilidad.
BYO keys + metering
- Las claves por tenant (
TenantApiKey) se cifran con AES-256-GCM. Orden de resolución: clave del tenant → clave global del provider → variable de entorno. - Toda llamada LLM pasa por el metering middleware (rate limit → credit check → cálculo de costo), registrando tokens de input y output por separado. Los precios vienen de una tabla en la base de datos, nunca hardcoded.
Por qué importa
No apuestas la plataforma al precio, latencia o disponibilidad de un único laboratorio. A medida que los modelos mejoran, cambias un dropdown — no tu código.