Saltar al contenido
Studeia Docs
AI-assisted translation — last updated 2026-05-31. For original (pt-BR or en-US), use the language switcher.

IA multi-proveedor: elige el modelo, sin vendor lock-in

Studeia es multi-proveedor: el admin elige el modelo por tarea (Claude, GPT, Grok, Gemini) vía TenantTaskModelConfig, con fallback chain, circuit breaker, BYO keys y metering

Por Equipo Studeia 2026-05-31 6 min
Resposta curta

Studeia es multi-proveedor por defecto: tu institución elige entre Claude, GPT, Grok y Gemini por tipo de tarea y puede usar su propia API key — el costo de IA va a tu cuenta, sin margen incorporado. Una cadena de fallback con circuit breaker mantiene el servicio en pie si un proveedor cae, y cada llamada es medida. El resultado es control de costos, resiliencia y cero vendor lock-in de IA.

Cómo funciona la selección de modelo

El LLM Router (packages/core/src/ai/router.ts) resuelve el proveedor y el modelo de cada llamada a partir del TenantTaskModelConfig, por tipo de tarea:

Tipo de tareaDefault típico
chat_tutorclase Sonnet
chat_evaluation / summarization / supervisorclase Haiku
content_generationclase Haiku
course_review / course_agent / gamification_agentclase Sonnet

El admin institucional puede sobreescribir cualquier tarea hacia otro proveedor/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 (medido).
  • generate() — agentes con tools (medido); las tools se convierten de JSON Schema al formato AI SDK, por lo que funcionan en cualquier proveedor.
  • generateDirect() — llamadas background fire-and-forget (evaluation, content, summarizer, supervisor) que se ejecutan en el after() 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 se comparte entre instancias, por lo que un breaker abierto salta el proveedor problemático sin timeout. Los incidentes se registran para observabilidad.

BYO keys + metering

  • Las claves por tenant (TenantApiKey) están cifradas con AES-256-GCM. Orden de resolución: clave del tenant → clave global del proveedor → variable de entorno.
  • Cada 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.

Ver también

FAQ

¿Studeia tiene lock-in con un único proveedor de IA?

No. Toda feature con LLM pasa por un LLM Router interno que selecciona el proveedor y el modelo por tipo de tarea. El admin puede cambiar una tarea de Anthropic Claude a OpenAI GPT, xAI Grok o Google Gemini sin romper ningún agente — el tool calling funciona en cualquier proveedor vía Vercel AI SDK. Si el proveedor primario falla, una fallback chain automática toma el control.

¿Una institución puede usar sus propias API keys?

Sí. Cada tenant puede guardar sus propias claves (TenantApiKey, cifradas con AES-256-GCM). Cuando el tenant trae su propia clave, el costo de IA va directamente a su cuenta en el proveedor — Studeia no aplica margen de IA y nunca usa process.env (lo que podría filtrarse entre tenants); la clave se pasa por request.

¿Qué impide que una caída de proveedor derribe el tutor?

Un circuit breaker (estado en Redis, compartido entre instancias) se abre tras fallos repetidos y salta directamente al siguiente proveedor de la fallback chain, por lo que la caída de un proveedor degrada de forma gradual en lugar de fallar el request. Cada fallback se registra como incidente de proveedor.

Veja tambem

IA multi-proveedor: elige el modelo, sin vendor lock-in