Fornecedores de IA e definições dos agentes

O Singularity não contacta diretamente as API dos fornecedores. Prepara o ticket, abre um processo local e controla o CLI do fornecedor selecionado. Instala primeiro esse CLI com o método recomendado pelo respetivo fabricante, abre um terminal, executa-o uma primeira vez e conclui a autenticação.

O teste mais simples consiste em pedir uma resposta ao CLI a partir da pasta de um projeto. Se pedir um início de sessão, a aprovação de uma pasta ou uma atualização, resolve isso antes de lançar um ticket no Singularity.

Instala o Claude Code, executa claude e segue o início de sessão interativo da Anthropic. A lista de modelos (Auto e os modelos Claude disponíveis para a tua conta) é carregada a partir do catálogo do fornecedor, pelo que pode mudar sem que esta página seja atualizada.

O separador permite definir o modo de permissões, o esforço, o raciocínio alargado ou adaptativo, o modo rápido reservado ao Opus, a cache de prompts, o contexto alargado, a memória, os limites de raciocínio e de saída, bem como as equipas de agentes.

Instala o CLI do Codex, executa codex e liga a tua conta OpenAI através do fluxo proposto. Os modelos apresentados são os do catálogo do Codex disponível no computador, juntamente com a opção Auto.

O separador disponibiliza a personalidade, a política de aprovação, a sandbox, o esforço e o resumo do raciocínio, bem como o editor utilizado para abrir as referências. As opções de segurança alteram efetivamente as permissões concedidas ao processo: prefere o acesso ao espaço de trabalho, salvo necessidade explícita.

Instala o CLI do GitHub Copilot, executa copilot e autentica-te no GitHub. A tua conta e a tua organização têm de permitir o Copilot. São então propostos o Auto e os modelos devolvidos pelo Copilot.

O separador define o modo de aprovação (sugestão, edição automática ou autonomia total), a pesquisa web, o modo plano e a delegação. Começa no modo sugestão num repositório sensível.

Instala o Cursor e o respetivo agente CLI e, depois, executa agent para concluir o início de sessão. O Auto e os modelos publicados pelo Cursor alimentam o seletor. Também é possível introduzir uma chave no separador; o campo está oculto.

As definições abrangem as permissões (force, shell ou plan), as confirmações do modo shell, a pesquisa web e a conservação do histórico de sessão.

Instala o Gemini CLI, executa gemini e escolhe o início de sessão Google proposto. O Auto e os modelos Gemini autorizados são descobertos através do catálogo.

É o separador mais detalhado: aprovações, número de tentativas e de turnos, compressão e retenção das sessões, deteção de ciclos, encaminhamento dos planos, estratégia de excesso de utilização, formato de texto ou JSON, sandbox, modo Vim, atualização automática, notificações e integração com o IDE.

Instala o CLI Mistral Vibe e verifica se arranca a partir de um terminal. Em seguida, configura um perfil ou uma chave Mistral no campo oculto do separador. São propostos o Auto e os modelos devolvidos pelo fornecedor.

Podes ativar os modelos offline, escolher entre YOLO, ask e plan para as permissões e, depois, definir a pesquisa web e a persistência do histórico.

Instala o Ollama, inicia o respetivo daemon local e verifica ollama list. Por predefinição, o Singularity utiliza o endpoint local http://127.0.0.1:11434 e aponta o Claude Code para esse servidor. O separador permite pesquisar, descarregar, eliminar e atualizar modelos; também recomenda os adequados à RAM e ao processador através de llmfit ou de uma estimativa.

Descarrega o modelo antes de o selecionar. Um modelo pequeno quantizado responde mais depressa e consome menos memória, mas segue pior as instruções longas e as refatorações complexas. Em CPU, conta com uma geração bastante mais lenta; numa máquina sem RAM ou memória de GPU suficientes, o modelo pode tornar-se inutilizável. Mantém um fornecedor remoto para as tarefas difíceis.

A definição do fornecedor determina o modelo predefinido para os novos agentes do espaço de trabalho. Auto — pick based on context (Auto — escolher consoante o contexto) deixa a pré-qualificação selecionar um modelo elegível consoante a tarefa.

Ao nível de um ticket, o seletor de agente pode substituir esta escolha para essa execução: útil para reservar um modelo potente para uma migração ou escolher um modelo rápido para uma correção mecânica. A definição do ticket prevalece sobre a predefinição do espaço, sem a alterar.

Em «Models for automatic selection» (Modelos para a seleção automática), desmarca um modelo para impedir que o Auto o escolha. Continua disponível para seleção manual. Utiliza esta exclusão para evitar um modelo demasiado caro, demasiado lento, descontinuado ou inadequado ao teu repositório.

Quando o fornecedor disponibiliza uma profundidade de raciocínio, também podes retirar alguns níveis dos seletores de ticket. Isto evita, por exemplo, um raciocínio mínimo em código crítico ou um nível máximo em tarefas curtas. Estas exclusões reduzem as escolhas automáticas; não desinstalam nada.

Para medir o custo de um lote de tickets, regista o consumo do mesmo âmbito antes e depois da execução e, depois, separa despesas variáveis, subscrições e tempo humano. Um contador de tokens ou uma estimativa de sessão não prova o montante faturado. Não é garantido qualquer custo por ticket nem qualquer poupança.

1. Definir a tarefa de controlo. Escolhe uma pequena correção representativa, com o commit de partida, o mesmo conjunto de dados, os critérios de aceitação e os testes. Enumera os tickets do lote, incluindo os que falham. Para comparar dois fluxos de trabalho, parte do mesmo estado e mantém os mesmos critérios.
2. Fixar o contexto. Anota o fornecedor, a versão do CLI, o modelo efetivamente utilizado (e cada mudança, se o Auto estiver ativo), o esforço, o número de agentes e o modo subscrição ou API. Identifica a conta/o projeto de faturação sem copiar qualquer chave ou dado confidencial.
3. Registar antes. Regista a data e hora com o fuso horário e guarda a fonte do contador, o período, a moeda, os tokens por modelo e os valores de cache, se disponíveis. Isola o lote das restantes utilizações da conta ou declara a medição como não atribuível. Com o Claude Code interativo, consulta /usage na sessão em causa; para um lote orquestrado sem acesso a essa sessão, utiliza o registo do fornecedor do âmbito isolado, e não uma nova sessão vazia do CLI.
4. Executar e registar. Guarda todas as tentativas, erros, relançamentos, subagentes e correções após a revisão. Cronometra separadamente a preparação, a espera da máquina, a revisão humana e a integração. A duração real de uma sessão não é tempo de trabalho humano.
5. Registar depois. Espera que os agentes terminem e que os contadores sejam atualizados; guarda a hora da captura e a janela abrangida. Utiliza exatamente a mesma fonte e o mesmo âmbito. Arquiva cada sessão antes de ser reposta a zero; uma diferença negativa ou uma mudança de período invalida a subtração.
6. Reconciliar e publicar os limites. Calcula depois menos antes, na mesma unidade. Para a API, reconcilia a estimativa com os montantes do fornecedor quando estiverem disponíveis. Soma apenas períodos disjuntos: não contes duas vezes um total pai e os respetivos subagentes. Indica os tickets tentados, aceites e rejeitados, a qualidade obtida e o tempo de revisão. Uma média por ticket aceite aplica-se apenas a este lote, com as falhas incluídas no numerador.

Como medir o consumo do Claude Code?

A documentação oficial de custos do Claude Code, consultada a 11 de outubro de 2026, descreve /usage: o bloco Session estima o custo dos tokens; as barras de subscrição acompanham os limites do plano. O montante da sessão não é a fatura de uma subscrição Pro ou Max. Para a API, consulta a vista Usage da Claude Console da conta faturada (requer início de sessão). Verifica o comando disponível na tua versão do CLI e a atualidade do registo.

Exemplo ilustrativo: três tickets, não um benchmark

Valores fictícios, não medidos. Num âmbito de API isolado, um registo cumulativo do fornecedor de 11/10/2026 às 10:00 UTC indica 12,00 USD e o das 10:40 UTC indica 13,80 USD, para o mesmo período e a mesma moeda: diferença ilustrativa de 1,80 USD. O registo fictício conta três tickets tentados, dois aceites, um rejeitado, quatro tentativas e 18 minutos de revisão. O modelo exato e a versão do CLI teriam de ser anotados num registo real; este exemplo não executou qualquer modelo.

Se os registos forem completos e exclusivos do lote, 1,80 / 2 = 0,90 USD por ticket aceite, apenas para este exemplo, incluindo a falha. Não se trata de um preço anunciado nem de uma previsão. Com uma subscrição, anota antes a evolução da quota e os eventuais excessos efetivamente faturados: não convertas uma percentagem de quota em euros. Uma quota-parte de subscrição é uma convenção contabilística a explicitar, não um custo marginal observado.

Ficha de registo para copiar

Lote / tickets / commit de partida:
Critérios / testes / dados:
Fornecedor / versão do CLI / modelo(s) / esforço / agentes:
Modo subscrição ou API / âmbito de faturação:
Fonte / período / fuso horário / moeda / impostos:
Antes: data e hora, montante ou quota, tokens/cache disponíveis
Depois: data e hora, montante ou quota, tokens/cache disponíveis
Tentativas / erros / relançamentos / tickets aceites e rejeitados:
Minutos de preparação / espera / revisão / integração:
Diferença observada / reconciliação com a fatura / provas anonimizadas:
Limites: utilizações simultâneas, atrasos, reposições, cache, custos excluídos

A cache, os preços contratuais, as moedas, os impostos, os créditos e outros dispositivos podem impedir uma atribuição exata. Se faltar um contador, indica «indisponível», nunca zero. Mantém a licença do Singularity, as subscrições dos fornecedores, os excessos, a execução remota e o tempo humano em linhas separadas; não voltes a contar um consumo já incluído. Consulta os preços e custos dos fornecedores e aplica esta ficha ao protocolo comparativo do Claude Code.

O Singularity não carrega, por iniciativa própria, o teu código para um fornecedor de IA. Apenas os CLI que instalaste e configuraste comunicam com os respetivos serviços externos, de acordo com as suas próprias condições, definições e políticas de conservação. Os prompts, excertos de ficheiros e resultados de ferramentas necessários ao agente podem, portanto, passar pelo fornecedor escolhido.

Com o Ollama no endereço local e um modelo executado localmente, a inferência fica no computador; no entanto, o descarregamento inicial de um modelo contacta o registo do Ollama. Um endpoint Ollama remoto ou um modelo na nuvem deixa de ser local. Consulta a tabela das políticas das sete integrações. Verifica sempre o URL configurado e as permissões do agente antes de tratar um repositório confidencial.

A conservação depende do fornecedor, do plano e da conta efetivamente utilizada pelo CLI. Este levantamento da documentação dos fabricantes, consultada a 11 de outubro de 2026, permite encontrar a regra aplicável; não constitui um compromisso do Singularity nem uma verificação do teu contrato.

Antes de tratar um repositório confidencial, verifica a autenticação, o endpoint, o modelo, as opções de partilha e as regras da tua organização. Ausência de treino, ausência de conservação e histórico local são três temas distintos. Não se deduz aqui nenhum prazo universal: as exceções legais e antiabuso, o feedback voluntário e os serviços com estado devem ser consultados nas fontes. As ferramentas web, as extensões/MCP, os registos e os históricos do CLI podem ter os seus próprios destinos e prazos, mesmo com inferência local.