Escolha o modelo de IA que guia suas sessões de depuração

O StatusRivet precisa de um modelo para raciocinar, e você decide onde ele fica: um provedor de IA em nuvem via endpoint de API padrão, um modelo rodando no seu PC ou o modelo integrado. Esta página explica as três opções e como testar a conexão.

Três opções de execução para o modelo

Provedor de IA em nuvem

Um provedor de IA em nuvem é ideal para grandes bases de código e logs extensos. Insira um endpoint de API padrão e sua chave. A chave permanece local. Cada prompt é enviado ao provedor escolhido, incluindo o texto de qualquer arquivo ou log lido pelo agente nessa etapa, então leia a política do provedor antes de enviar código-fonte que não seja público. Mantenha o trabalho restrito ao software que você escreveu ou tem autorização para depurar. O provedor pode cobrar pelo uso conforme seus próprios termos, e o StatusRivet é independente de todos os provedores. Escolha esta opção quando seus logs e arquivos de origem precisarem de uma janela de contexto grande.

Modelo no seu PC

Um modelo rodando no seu PC é ideal para código que você não pode enviar para nenhum lugar. Seu PC faz o trabalho. Aponte o StatusRivet para o endpoint local e os prompts vão para sua própria máquina, então nada sai dela. A contrapartida é o hardware: a velocidade e a janela de contexto dependem do que seu PC consegue executar, e um log longo pode não caber. Use o botão Testar para ver a janela antes de uma sessão longa. Atualizar ou trocar o modelo é sua responsabilidade. Funciona bem em máquinas de laboratório e drivers não publicados, desde que você aceite essas limitações.

Modelo integrado

O modelo integrado está pronto para uso sem necessidade de um endpoint, sendo o caminho mais curto da instalação até o primeiro chat. Nenhum endpoint é necessário. Use-o para experimentar os modos de aprovação, ler um log curto e ver como parece um cartão de diff antes de configurar qualquer outra coisa. Quando uma tarefa exigir mais, conecte um provedor de IA em nuvem ou um modelo no seu PC e execute o mesmo chat novamente para comparar as respostas. Revise cada diff da mesma forma, independentemente de qual modelo o gerou.

Teste a conexão antes de uma sessão longa

Pressione o botão Testar ao lado de um endpoint para verificar a conexão. O resultado mostra o tempo de resposta e a janela de contexto desse modelo. O tempo de resposta indica se o endpoint responde em um ritmo com o qual você pode trabalhar. A janela de contexto informa quanto de um log ou arquivo de fonte cabe em uma única solicitação, o que é importante quando uma pilha de chamadas longa faz parte do prompt. Execute o teste novamente após alterar o endpoint ou o modelo. Um teste falho indica um problema na conexão, não no seu código. Corrija isso primeiro.

Escolha o tamanho do modelo para a tarefa

Use um modelo maior para raciocínio complexo, como rastrear uma falha através de vários módulos ou revisar uma alteração maior, e um menor para edições pequenas, como adicionar uma verificação nula. A habilidade run_on_model permite que o agente envie uma etapa difícil para um modelo maior enquanto o restante da sessão permanece no modelo menor. Isso mantém as etapas rotineiras no modelo menor, enquanto a etapa difícil recebe mais capacidade. Escolha pela tarefa, não por hábito, e use o botão Testar para comparar janelas de contexto antes de inserir um log de falha longo. Encaixe o log primeiro.

A qualidade do modelo varia entre provedores e versões, então trate cada resposta como um rascunho. Rascunhos precisam de revisão. Leia o diff, reconstrua com seu comando de build e execute seu comando de teste antes de manter uma alteração. Ask first pausa antes de ações que alteram algo, o que dá a você um lugar para parar e ler. Plan only grava um plano e não executa nada, o que ajuda quando você quer ver as etapas antes de alternar para Auto-run ou Ask first. O agente trabalha com saída de texto, então um resultado é tão bom quanto os logs que você fornece.