Pular para o conteúdo

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

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

2026-05-31 6 min
Resposta curta

O Studeia e multi-provider por padrao. Toda feature com LLM passa por um LLM Router interno que seleciona provider+modelo por tarefa via TenantTaskModelConfig — o admin troca entre Claude, GPT, Grok e Gemini sem quebrar nenhum agente (tool calling funciona em qualquer provider via Vercel AI SDK). Uma fallback chain com circuit breaker no Redis trata quedas, tenants podem trazer as proprias chaves cifradas (custo vai para a conta deles, sem margem de IA), e toda chamada passa por metering.

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 | Studeia Docs