Pular para o conteúdo
Studeia Docs

IA multi-provider: escolha o modelo, sem vendor lock-in

Studeia é multi-provider: admin escolhe modelo por tarefa (Claude, GPT, Grok, Gemini) via TenantTaskModelConfig, com fallback chain, circuit breaker, BYO keys e metering

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

A Studeia é multi-provider por padrão: a sua instituição escolhe entre Claude, GPT, Grok e Gemini por tipo de tarefa e pode usar a própria chave de API — o custo de IA vai para a sua conta, sem margem embutida. Uma cadeia de fallback com circuit breaker mantém o serviço de pé se um provedor cair, e toda chamada é metrificada. O resultado é controle de custo, resiliência e zero vendor lock-in de IA.

Como a selecao de modelo funciona

O LLM Router (packages/core/src/ai/router.ts) resolve o provider e o modelo de cada chamada a partir do TenantTaskModelConfig, por tipo de tarefa:

Tipo de tarefaDefault tipico
chat_tutorclasse Sonnet
chat_evaluation / summarization / supervisorclasse Haiku
content_generationclasse Haiku
course_review / course_agent / gamification_agentclasse Sonnet

O admin institucional pode sobrepor qualquer tarefa para outro provider/modelo. Nenhum model ID e hardcoded nos agentes — o router e o unico ponto de decisao.

Metodos do router

  • stream() — chat com streaming (metered).
  • generate() — agentes com tools (metered); as tools sao convertidas de JSON Schema para o formato AI SDK, entao funcionam em qualquer provider.
  • generateDirect() — chamadas background fire-and-forget (evaluation, content, summarizer, supervisor) que rodam no after() do Next.js sem o pipeline completo de metering.

Fallback chain + circuit breaker

Por tier: Claude → GPT → Grok → Gemini (LLMs); Voyage → OpenAI → Cohere (embeddings). Um circuit breaker no Redis abre apos um limite de falhas e e compartilhado entre instancias, entao um breaker aberto pula o provider problematico sem timeout. Incidentes sao registrados para observabilidade.

BYO keys + metering

  • Chaves por tenant (TenantApiKey) sao cifradas AES-256-GCM. Ordem de resolucao: chave do tenant → chave global do provider → variavel de ambiente.
  • Toda chamada LLM passa pelo metering middleware (rate limit → credit check → calculo de custo), registrando tokens de input e output separadamente. Precos vem de uma tabela no banco, nunca hardcoded.

Por que importa

Voce nao aposta a plataforma no preco, latencia ou disponibilidade de um unico laboratorio. Conforme os modelos melhoram, voce troca um dropdown — nao o seu codigo.

Veja tambem

FAQ

O Studeia tem lock-in com um unico fornecedor de IA?

Nao. Toda feature com LLM passa por um LLM Router interno que seleciona provider+modelo por tipo de tarefa. O admin pode trocar uma tarefa de Anthropic Claude para OpenAI GPT, xAI Grok ou Google Gemini sem quebrar nenhum agente — tool calling funciona em qualquer provider via Vercel AI SDK. Se o provider primario falha, uma fallback chain automatica assume.

Uma instituicao pode usar as proprias API keys?

Sim. Cada tenant pode guardar as proprias chaves (TenantApiKey, cifradas AES-256-GCM). Quando o tenant traz a propria chave, o custo de IA vai direto para a conta dele no provider — o Studeia nao aplica margem de IA e nunca seta process.env (que vazaria entre tenants); a chave e passada por request.

O que impede uma queda de provider de derrubar o tutor?

Um circuit breaker (estado no Redis, compartilhado entre instancias) abre apos falhas repetidas e pula direto para o proximo provider da fallback chain, entao a queda de um fornecedor degrada graciosamente em vez de falhar o request. Todo fallback e registrado como incidente de provider.

Veja tambem

IA multi-provider: escolha o modelo, sem vendor lock-in