Escolha o modelo de IA por trás das edições no shell

O SeedSpindle no Windows precisa de um modelo de IA para planejar e escrever cada alteração. Você pode conectar um provedor de IA em nuvem, um modelo rodando no seu PC ou o modelo embutido. A escolha define para onde seus prompts vão e quão grande pode ser a tarefa que o agente consegue lidar.

Escolha a origem do seu modelo

Provedor de IA em nuvem

Um provedor de IA em nuvem se conecta por meio de um endpoint de API padrão que você insere nas configurações. O agente envia seu prompt para esse provedor, incluindo o texto de qualquer arquivo que ele lê, como o seu ~/.bashrc. Planeje seu uso com base nisso. A privacidade depende, portanto, do provedor que você escolher, e um arquivo de shell com segredos não deve ser enviado a um serviço em quem você não confia. Um modelo em nuvem é adequado para tarefas grandes que um modelo local pequeno não consegue lidar, e você pode alterar o endpoint quando quiser. As chaves de API ficam no seu PC, e os prompts vão apenas para o endpoint que você escolheu.

Modelo local no seu PC

Um modelo executado localmente no seu PC responde na mesma máquina onde o SeedSpindle está rodando. Com um modelo local, nada sai da máquina, porque o prompt e todos os arquivos que o agente lê permanecem no seu PC. Isso o torna uma boa opção para arquivos de shell que contêm caminhos, nomes de host ou outros detalhes que você prefere manter em privado. O hardware importa. Um modelo pequeno pode ser mais lento ou menos capaz em tarefas longas, então revise cada diff com cuidado extra, e você pode enviar uma etapa difícil para um modelo maior se decidir fazer isso.

Modelo embutido

O modelo embutido está pronto para uso sem seu próprio endpoint, o que o torna a maneira mais rápida de começar. Você instala o SeedSpindle para Windows, abre um chat e dá ao agente uma primeira tarefa, como adicionar um alias ll. Nenhuma configuração de API é necessária. Experimente primeiro. Se uma tarefa parecer muito difícil, você pode conectar um provedor de IA em nuvem ou um modelo local mais tarde e continuar trabalhando na mesma janela de chat, com os mesmos modos de aprovação e a mesma revisão de diff.

Teste sua conexão

O botão Testar verifica o endpoint que você inseriu e mostra o tempo de resposta e a janela de contexto do modelo. Execute-o logo após adicionar um novo provedor ou um novo endereço local, porque uma chave errada ou um endereço incorreto aparecerão ali antes de você iniciar o trabalho real. A janela de contexto indica quanto texto o modelo pode processar em uma única solicitação, o que é importante quando o ~/.bashrc e o histórico do chat são longos. Verifique uma vez. Se o tempo de resposta parecer lento, tente um modelo menor para edições pequenas e mantenha o maior para etapas mais difíceis. O teste não altera arquivos.

Escolha o modelo certo para sua tarefa

Use um modelo maior para refatorações e lógica complexa, e um menor para edições pequenas, como adicionar um alias. Um modelo maior custa mais para executar ou exige hardware mais potente, então faz sentido reservá-lo para as etapas que realmente precisam dele. A ferramenta run_on_model envia uma etapa difícil para um modelo maior enquanto o restante do chat continua com sua escolha habitual. Pense no tamanho. Uma única linha de alias precisa de muito pouco raciocínio, mas uma organização de um arquivo longo com várias funções e muitos aliases se beneficia de ajuda mais capaz, e você pode comparar os diffs propostos por cada modelo.

A qualidade do modelo varia entre provedores e configurações locais, então leia o diff antes de aceitar qualquer coisa. Ask first pausa antes de ações que alteram algo, o que lhe dá a chance de rejeitar uma linha que pareça errada. Plan only mostra o plano sem tocar em um arquivo. Confie no diff, não no modelo. Um modelo pode escrever um alias plausível que não faz o que você pretendia, e apenas sua revisão e um teste em um novo shell dirão se funciona.