Administração da instância

Usar a administração da instância

Administrar a instância é diferente de ser proprietário de um projeto. ADMIN_EMAILS lista as contas confirmadas autorizadas no servidor; app_metadata.role=admin assinado também é uma fonte válida. São exigidos aal2, MFA verificada e verificações atuais de conta e sessão. Se elas falham, o acesso é negado. Entre, complete TOTP e abra /admin. Não altere papéis no banco para contornar MFA. O console e as APIs privadas continuam noindex.

Visão geral mostra os indicadores agregados da instância. Finanças não aparece neste perfil de demonstração porque não há chave gerenciada do OpenRouter configurada.

Modelos configura padrões e usos específicos. A captura mostra a configuração existente; nenhum modelo ou provedor foi alterado.

Usar os controles disponíveis

O console inclui Visão geral, Usuários, Modelos e, quando disponível, Finanças. Finanças fica oculto sem OpenRouter gerenciado; a atribuição de plano depende da cobrança habilitada ou de um override já existente. Abrir o console não acrescenta cobrança Cloud a uma instância própria sem provedores comerciais. Usuários encontra uma conta apenas pelo endereço de e-mail exato; abra-a para ver o status de confirmação do e-mail, consultar ou redefinir o orçamento de uso de IA, oferecer um plano na condição acima ou marcá-la como conta interna, o que a exclui de todas as estatísticas. O painel não mostra a atividade da conta nem seu conteúdo pessoal; abra uma conta somente para uma tarefa de suporte ou de cobrança. Confira modelos, padrões, usuários e quotas na versão instalada antes de alterar. As mudanças afetam toda a instância: valide com uma conta de demonstração.

Escolher o modelo de decisão de IA

Em Modelos, seção Automações, Modelo de decisão define o único modelo de decisão que responde a todas as decisões de IA da instância: Smart Fill, Smart Assign e a revisão de feedback. Não há escolha por projeto, por usuário ou por recurso. O seletor só lista modelos do OpenRouter que publicam a capacidade de decisão; modelos de chat, embedding e transcrição nunca aparecem. Ao salvar, o candidato é testado com uma decisão representativa. Um modelo que não é de decisão, recusa a solicitação, devolve uma resposta inválida ou leva mais de 5 segundos é recusado, e o modelo atual continua em uso. Quando o catálogo não pode ser carregado, toda alteração é recusada. Instâncias auto-hospedadas sem IA gerenciada não têm catálogo da plataforma e mantêm o padrão, Jev.

Novas decisões usam o modelo salvo em cerca de um minuto em cada processo do servidor. Quando o modelo falha ou responde abaixo do limite de confiança, a decisão recorre ao modelo LLM próprio do recurso, como antes. O limite foi calibrado no Jev e outros modelos de decisão distribuem a confiança de outra forma: após uma troca, confira a concordância por modelo na visão de banco de dados ai_decision_evaluations_weekly. As linhas de uso registram o modelo que respondeu.

Configurar as relações do Smart Fill

Depois que um problema é salvo, o Smart Fill pode indexá-lo e vinculá-lo a problemas relacionados. Dois campos em Modelos, seção Automações, controlam esse trabalho:

• Embeddings de problemas escolhe o modelo que transforma o título e a descrição dos problemas em vetores. O padrão é openai/text-embedding-3-small. Trocá-lo inicia uma nova versão do índice: vetores antigos e novos nunca são comparados. A tarefa de hora em hora /api/cron/issue-index indexa então os problemas existentes, 100 por execução, cobrando o proprietário de cada projeto; ela nunca cria relações. O mesmo modelo transforma em vetor cada consulta da busca pelo sentido, com as configurações do provedor de IA do membro que busca, e as consultas só são comparadas com vetores da versão atual do índice. Até que um problema seja indexado de novo, a busca de problemas relacionados e a busca pelo sentido só o encontram pelas palavras. A mesma tarefa converte em vetores criptografados os salvos sem criptografia assim que o projeto deles passa a criptografar.
• Modelo de decisão de relações é o modelo LLM de reserva que responde às decisões de relação quando o modelo de decisão falha ou não tem certeza, como o modelo LLM próprio de cada recurso. O padrão é deepseek/deepseek-v4-flash.

Os campos de embedding e de transcrição recusam ao salvar um modelo da família errada, por exemplo um modelo de chat em um campo de embeddings, e o modelo atual continua em uso. Essa verificação precisa do catálogo da plataforma: quando ele não pode ser carregado, como em uma instância auto-hospedada sem IA gerenciada, a escolha não pode ser verificada e é aceita. Para membros que executam automações com a própria chave, os padrões por provedor incluem issue_embedding_model: text-embedding-3-small para OpenAI e gemini-embedding-001 para Google.

Manter responsabilidades operacionais

Privilégios mínimos, recuperação MFA, segredos, backup, retenção, incidentes e custos continuam sob sua responsabilidade. O console não substitui a restauração de banco e Storage nem a configuração SMTP. Se o acesso for recusado, confira email confirmado, allowlist, MFA e sessão antes de mudar a configuração. Uma sessão revogada ou conta bloqueada não conserva privilégios por ainda ter um JWT válido. Evite capturas com dados privados de outras pessoas, fatores MFA ou detalhes financeiros.