Agentes de IA auto-hospedados no Cursor: o que muda

A mudança anunciada pelo Cursor em 2 de setembro de 2026 desloca, ao mesmo tempo, o perímetro de segurança e a conta de infraestrutura: com agentes de IA auto-hospedados, a equipe mantém a execução das ferramentas em máquinas sob seu controle, mas passa a responder por esses workers. O modelo, o planejamento e o loop do agente continuam rodando na nuvem do Cursor.

Agentes de IA auto-hospedados funcionam em um runtime dividido

Um Cursor Cloud Agent tem duas metades. O loop do agente decide o próximo passo e chama o modelo. A execução de ferramentas é a parte que edita arquivos, executa comandos no terminal, abre o navegador, conversa com um servidor MCP local e acessa serviços internos.

Cursor Self-Hosted Machines separa essas duas metades. O Cursor continua responsável pelo loop, pela inferência, pelo planejamento, pela interface e pela orquestração da sessão. Um worker administrado pela sua equipe executa as ferramentas.

Esse worker pode ser um laptop, uma VM, um Mac, um pod do Kubernetes ou um sandbox fornecido por um parceiro de integração. Ele abre uma conexão HTTPS de saída com o Cursor, recebe chamadas de ferramentas, executa-as localmente e devolve os resultados. O Cursor não precisa de uma porta de entrada nem de um IP público no worker.

Na prática, a divisão operacional fica assim:

O Cursor oferece dois formatos de worker. My Machines vincula uma máquina à conta de uma pessoa e atende bem a uma devbox ou a um fluxo pessoal restrito. Team Pools são filas nomeadas para equipes Enterprise. Cada solicitação aguarda no pool até que um worker disponível a assuma, e cada worker do pool processa uma sessão do Cloud Agent por vez.

Isso não transforma o Cursor em uma solução on-premise. Trata-se de um runtime dividido cuja metade de execução pertence ao cliente. É essa diferença que determina se o recurso atende ou não à sua política.

O que fica na rede privada — e o que ainda sai dela

O checkout completo, o cache de build e as credenciais locais da máquina permanecem no worker. Comandos, operações no repositório, builds e chamadas a serviços internos também acontecem ali. Com isso, deixa de ser necessário copiar o repositório inteiro para uma VM de execução gerenciada pelo fornecedor.

O agente ainda precisa de contexto para tomar decisões. Durante uma execução, o worker envia ao Cursor o conteúdo dos arquivos necessários, a saída do terminal, diffs, capturas de tela, resultados do MCP local e metadados de roteamento. Capturas de tela, vídeos e referências a logs também podem ser enviados ao armazenamento de artefatos gerenciado pelo Cursor para aparecerem nos pull requests e no painel.

É possível bloquear o host de artefatos sem interromper o agente, mas esses artefatos deixam de aparecer no pull request e no painel. O Privacy Mode também se aplica: o código enviado pelo worker não é usado para treinamento pelo Cursor nem por seus provedores de modelos. Isso não torna a sessão offline.

Essa é a primeira consequência para o negócio. A análise de segurança agora pode aprovar separadamente o local de execução e o processamento pelo modelo, mas ainda precisa aprovar ambos.

Quem pode usar — e o que muda para cada equipe

Backend corporativo com serviços internos

Uma equipe de backend pode depender de um registro privado de pacotes, um banco de dados de staging e endpoints de serviços inacessíveis a partir de uma VM gerenciada. Um Team Pool pode operar na mesma rede controlada e executar o build sem abrir uma rota de entrada vinda do Cursor.

O ganho está no controle de acesso, não em privacidade automática. A equipe de plataforma pode continuar usando suas políticas de rede e seu cofre de segredos, enquanto a equipe de segurança analisa exatamente quais resultados atravessam a conexão de saída.

Equipe de iOS dependente de Macs

Os Cloud Agents gerenciados pelo Cursor rodam em VMs Ubuntu. Uma equipe que precisa de hardware Mac para trabalhar com iOS pode cadastrar Macs como workers, conceder as permissões necessárias de uso do computador e permitir que o agente clique, digite, faça capturas de tela ou controle o navegador nessa máquina.

O benefício é permitir que o agente remoto use a mesma classe de hardware do build. O custo é conhecido por qualquer equipe que administre uma frota de Macs para builds: divergências entre imagens, permissões, disponibilidade, limpeza e substituição continuam sob sua responsabilidade.

Plataforma com demanda variável por agentes

Uma equipe de plataforma pode colocar Cloudflare Containers atrás de um Team Pool. O template de referência inicia um contêiner isolado para cada sessão assumida, usa um Durable Object como responsável por esse contêiner e pode armazenar snapshots do repositório em cache no R2.

O pool continua existindo quando nenhum worker está conectado, permitindo reduzir a capacidade a zero. Quando a demanda volta, o controlador assume a solicitação e inicia um contêiner. O ganho é pagar por computação conforme o uso, em vez de manter uma frota permanentemente ativa.

Pessoa desenvolvedora com devbox persistente

My Machines atende a quem trabalha em um projeto dependente de ferramentas ou de estado local difíceis de recriar. Vários agentes podem compartilhar a mesma máquina — uma conveniência em uma estação pessoal e um alerta em trabalhos sensíveis.

O benefício é a rapidez de configuração. O risco são os resíduos entre execuções, pois o Cursor não apaga nem recria seu laptop entre sessões. O diretório de trabalho, as credenciais, a limpeza dos processos e a integridade da máquina ficam sob sua responsabilidade.

Como configurar agentes de IA auto-hospedados na Cloudflare

A opção com Cloudflare é útil porque deixa explícito o novo limite de responsabilidade. Ela exige Cursor Enterprise, uma chave de conta de serviço da equipe com escopo de agente, uma conta Cloudflare Workers Paid com Containers e R2, Node.js 20 ou mais recente e Docker.

1. 1

   Cadastre um Team Pool

   Instale a CLI do Cursor, confirme que ela funciona e conecte um worker local temporário para fazer o pool aparecer no Cursor.

   curl https://cursor.com/install -fsS | bash
   agent --version
   export CURSOR_API_KEY="<team service-account API key>"
   CURSOR_API_KEY="$CURSOR_API_KEY" agent worker --pool cloudflare-test start

   Depois que o pool aparecer, interrompa esse worker com Ctrl+C e execute unset CURSOR_API_KEY. Mantenha o worker local parado durante o teste com a Cloudflare para impedir que ele assuma a solicitação primeiro.

2. 2

   Implante o template de referência do Cursor

   Clone o template, instale as dependências, entre na Cloudflare e crie o bucket opcional de snapshots.

   git clone https://github.com/anysphere/cloudflare-workers.git
   cd cloudflare-workers
   npm install
   npx wrangler login
   npx wrangler r2 bucket create cursor-pool-worker-snapshots

3. 3

   Armazene as credenciais

   Guarde a chave da conta de serviço do Cursor como segredo do Worker. Adicione credenciais Git somente quando os contêineres precisarem acessar repositórios privados.

   npx wrangler secret put CURSOR_API_KEY
   npx wrangler secret put GIT_USERNAME
   npx wrangler secret put GIT_TOKEN

   Uma chave pessoal da API do Cursor não funciona em um Team Pool. Esse é o erro de configuração com maior chance de parecer uma falha de infraestrutura, porque o controlador retorna 401.

4. 4

   Defina o pool e a capacidade

   No wrangler.jsonc, altere CURSOR_POOL para cloudflare-test. Defina containers[].max_instances como o máximo de sessões simultâneas que sua equipe está preparada para executar, e não como o número de pessoas desenvolvedoras.

   O arquivo de referência usa, por padrão, max_instances igual a 10 e um contêiner standard-1 com 0.5 vCPU, 4 GiB de memória e 8 GB de disco. Builds reais podem exigir uma configuração maior.

5. 5

   Faça o deploy e acompanhe a primeira execução

   Faça o deploy e mantenha abertas as visualizações do controlador e dos contêineres enquanto inicia um Cloud Agent e seleciona o pool auto-hospedado.

   npx wrangler deploy
   npx wrangler tail
   npx wrangler containers list

   A primeira execução agendada do controlador pode levar até cinco minutos para começar. Quando uma sessão é assumida, mas não inicia, o problema costuma estar na capacidade dos contêineres, na clonagem do repositório ou nas credenciais Git.

O custo mudou de lugar — não desapareceu

Os Cloud Agents gerenciados pelo Cursor incluem a infraestrutura de execução. Self-Hosted Machines continuam consumindo o modelo selecionado pelo preço do Cursor e acrescentam a conta do seu worker. Team Pools também exigem um contrato Enterprise, cujo preço é personalizado.

A Cloudflare mostra como essa despesa adicional se comporta. O produto Containers faz parte do plano Workers Paid de $5 por mês. A franquia inclui 25 GiB-horas de memória, 375 minutos de vCPU e 200 GB-horas de disco. Acima disso, a memória custa $0.0000025 por GiB-segundo, a CPU ativa custa $0.000020 por vCPU-segundo e o disco provisionado custa $0.00000007 por GB-segundo.

Considere a configuração standard-1 do template de referência e simule 100 sessões que trabalham por uma hora cada, usam toda a CPU disponível enquanto estão ativas e depois permanecem na janela ociosa de cinco minutos do template. Descontada a franquia, o cálculo dos contêineres fica em cerca de $12 no mês:

$5 plan + $3.15 CPU + $3.675 memory + $0.168 disk = $11.993

Esse é um exemplo de infraestrutura, não o valor total da conta do Cursor. Ele não inclui uso de Worker e Durable Object, logs, saída de dados, R2, contrato Enterprise, uso do modelo nem as pessoas que mantêm a frota. Também parte do princípio de que a menor configuração do template é suficiente. Um repositório com compilação pesada pode exigir um contêiner maior.

Em geral, a decisão mais cara não é a tarifa por segundo, e sim a política de manter capacidade ativa. O worker genérico de pool do Cursor usa por padrão uma janela de reconexão de 3,600 segundos, enquanto o template da Cloudflare reduz esse período para 300 segundos. Uma janela maior acelera prompts subsequentes e mantém a cobrança pela memória e pelo disco provisionados. Uma janela menor reduz o gasto durante a ociosidade, mas provoca mais inicializações a frio.

A capacidade também é sua responsabilidade. O template vem preparado para 10 contêineres simultâneos. A próxima solicitação fica em espera ou não consegue iniciar quando a capacidade definida, o limite da conta ou o host subjacente não está disponível. O Cursor pode encaminhar o trabalho a um pool, mas não pode criar uma capacidade que você não provisionou.

O isolamento segue a mesma lógica. O template da Cloudflare entrega um contêiner próprio para cada sessão. Uma máquina pessoal pode executar vários agentes no mesmo host. Se a política exigir uma VM nova, disco apagado, separação entre tenants ou um ambiente sem segredos residuais ao fim de cada execução, cabe à sua equipe construir e validar esse comportamento.

As atualizações passam a fazer parte do calendário operacional. Sua equipe assume a imagem base, a CLI do Cursor, as ferramentas de build, os certificados, as dependências e o rollout. Na Cloudflare, implantar uma nova imagem de contêiner interrompe os contêineres em execução; portanto, a atualização precisa aguardar o fim das sessões ativas ou aceitar essa interrupção.

O que fazer agora

Tome uma decisão ainda nesta semana se um Cloud Agent precisa de hardware específico, uma imagem personalizada ou acesso a ferramentas que a rede gerenciada não consegue oferecer. Comece com um pool restrito e um repositório de baixo risco. Inclua o processamento pelo modelo e os dados devolvidos pelas ferramentas na análise de segurança, porque mudar o local de execução não elimina nenhum dos dois.

Espere se a única necessidade for acessar código-fonte privado ou um serviço interno. O Cursor recomenda testar ambientes gerenciados, controles de rede, Tailscale, AWS PrivateLink ou Cloudflare Tunnel antes de assumir uma frota de workers. Essas opções deixam o ciclo de vida e o isolamento dos hosts sob responsabilidade do Cursor.

Nada muda para equipes cujos Cloud Agents gerenciados já atendem às políticas e reproduzem o build. A auto-hospedagem não acrescenta capacidades ao modelo. Ela muda o local de execução e transfere a responsabilidade operacional.

A tarefa para segunda-feira é objetiva: escolha um repositório representativo, registre quais trechos de código, segredos, resultados de ferramentas e artefatos podem atravessar esse limite e execute o mesmo build em um agente gerenciado e em um pool auto-hospedado com capacidade estritamente limitada. Meça o tempo na fila, as horas de contêiner, as alterações aceitas, as falhas de limpeza e o tempo gasto na manutenção da imagem. Só aprove a frota se o requisito de controle justificar essa segunda conta.

Receba na newsletter a próxima análise prática de workflows de IA.