O Cursor Projects, que foi lançado em 10 de setembro de 2026, é a resposta do Cursor a um problema real: um chat de IA comum esquece tudo assim que você o fecha. Um Project mantém um agente coordenador rodando por semanas, e esse coordenador não escreve código. Ele planeja o trabalho, delega a uma frota de subagentes na nuvem e traz pull requests de volta para você revisar. Ele também pode rodar sozinho, monitorando um canal do Slack ou seus PRs abertos.
Como construo agentes de IA que fazem trabalho de verdade, minha leitura honesta é: o modelo de coordenador é a ideia certa, e o "contexto compartilhado que cresce" é a parte que realmente importa. O problema é o modelo de custo. Você paga preço de API por cada subagente, e um coordenador que sobe vários em paralelo é uma questão de medição de uso, não produtividade de graça. Ideal para migrações e manutenção de longo prazo; exagero para uma correção rápida.
Um enquadramento que vale manter claro antes de continuar: o Cursor é infraestrutura para construir software, não um colega que faz um trabalho. Se você quer uma IA que assuma uma função logo de cara (suporte, conteúdo), é outra categoria, e vou mostrar onde as duas se encontram.
O que o Cursor Projects realmente é
Se você já usou o Cursor, conhece o formato de uma sessão: abre um chat, descreve uma tarefa, o agente edita arquivos, você revisa e segue em frente. Fecha a aba e o contexto some. Para uma correção de 20 minutos, tudo bem. Para uma migração de três semanas, você acaba reexplicando seu código a um agente novo várias vezes.
O Projects foi feito para o segundo caso. O Cursor o descreve como uma forma de "assumir trabalhos maiores, como uma funcionalidade, uma migração ou um app completo", em que o Project "mantém o contexto ao longo de meses de trabalho" e "executa trabalho recorrente sem ser solicitado". É o produto concreto por trás da visão da "terceira era do desenvolvimento de software" que o Cursor lançou em fevereiro: dirigir uma frota de agentes em vez de cuidar de um único chat.
O Cursor diz que usa o Projects internamente há meses, incluindo migrações de algumas centenas de PRs, e que entregou o próprio Projects com ele. O número de destaque: novos usuários mesclam 30% mais PRs, e usuários intensivos do Projects mesclam seis vezes mais. É um dado interno e autodeclarado, então trate como qualquer estatística de produtividade do próprio fornecedor, mas ele mostra o que o produto otimiza: volume de trabalho mesclado, não linhas digitadas.
Tudo está em beta e sendo liberado para todos os usuários desde o dia do lançamento. Você inicia um pelo menu à esquerda, descreve o que quer construir e o coordenador assume daí.
O agente coordenador: a mudança real
Esta é a parte que eu sublinharia. Quando você abre um Project, não conversa com um agente de programação. Conversa com um coordenador, e segundo o changelog do Cursor, "o agente coordenador de um project não escreve código; ele planeja o trabalho, delega a agentes que o implementam e traz o trabalho concluído de volta para você conferir."
Parece uma distinção pequena. Não é. Como o coordenador delega em vez de executar, o Cursor diz que "ele nunca fica bloqueado e sempre responde às suas orientações." Quem já viu um único agente mastigando uma tarefa longa conhece a frustração: você quer redirecioná-lo, mas ele está no meio de uma edição e inacessível. O coordenador contorna isso por nunca ser quem está com as mãos no código. Ele cria e gerencia agentes em seu nome, rodando quantos em paralelo o trabalho exigir, e o Cursor apresenta o teto como dirigir "milhares de agentes por meio de um coordenador".
Por baixo, isso roda no sistema de subagentes que o Cursor já tinha, o que vale entender porque explica tanto a força quanto o custo. Cada subagente "opera em sua própria janela de contexto", começa do zero, trabalha de forma autônoma e "devolve seu resultado ao agente pai". Eles podem rodar em paralelo e, desde o Cursor 2.5, um subagente pode até lançar seus próprios subagentes filhos, mas a árvore para aí: um subagente filho não pode lançar outros. Se você pedir isolamento, cada um recebe seu próprio Git worktree ou uma VM dedicada na nuvem com seu próprio clone do repositório, para que agentes paralelos não se sobrescrevam. As alterações ficam em branches separados até o pai mesclar.
A troca honesta, direto da documentação do Cursor: rodar cinco subagentes em paralelo usa cerca de cinco vezes os tokens de um único agente, e em tarefas simples eles podem ser mais lentos, porque cada um começa do zero. O que você compra é isolamento de contexto, não velocidade. É justo o Cursor dizer isso em voz alta, e é a frase à qual eu associaria um alerta de gastos.
Nuvem por padrão: onde o trabalho realmente roda
Um Project roda na nuvem, não no seu notebook. A formulação do Cursor é "nuvem por padrão, local quando necessário." Um Project "roda em seu próprio computador, então fechar o notebook não o interrompe", o que permite "rodar mais subagentes em paralelo do que seu notebook suportaria". Quando algo realmente precisa da sua máquina, o coordenador sobe um agente local para executar lá.
Isso é construído sobre os Cloud Agents, a infraestrutura que o Cursor chamava de Background Agents: VMs isoladas com ambientes de desenvolvimento completos que clonam seu repositório do GitHub, GitLab, Azure DevOps ou Bitbucket, trabalham em um branch e enviam de volta PRs prontos para mesclar com artefatos como capturas de tela e logs. Você pode até controlar a área de trabalho remota de um agente para testar o software modificado sem fazer checkout do branch localmente.
A etapa de configuração que as pessoas subestimam é o ambiente. O Cursor é direto: "não configurar um ambiente de desenvolvimento para seus agentes na nuvem é como não dar um computador aos seus engenheiros." Você o configura com um Dockerfile ou um snapshot salvo, e se pular essa etapa, seus agentes trabalham às cegas. Se você já integrou um novo contratado e viu ele perder um dia com uma configuração local quebrada, já sabe por que isso importa; é o mesmo imposto, pago uma vez por Project.
Contexto compartilhado: a parte que se acumula
Este é o recurso que considero realmente subestimado, e é o que faz o Projects ser mais que "agentes em segundo plano com um nome mais bonito".
A frase do Cursor é que "você não deveria ter que integrar um agente toda vez que começa uma tarefa." Então cada Project mantém um conjunto de arquivos que sincronizam entre todas as máquinas, na nuvem e locais, que seus agentes usam. Os agentes escrevem pesquisa, artefatos e "o que aprendem sobre o código e como você prefere que o trabalho seja feito" nesse contexto compartilhado. O exemplo do Cursor: se um agente descobre como testar um serviço, todos os agentes futuros podem usar essas instruções.
Esse é o efeito composto. O contexto "cresce com o Project, tornando o coordenador mais eficaz com o tempo". É a diferença entre contratar um prestador que esquece seu código toda manhã e um que está na equipe há um mês. Já construí sistemas em que todo o jogo é dar ao agente o contexto certo da empresa logo de início, e posso dizer que a segunda versão vale muito mais do que parece num slide de lançamento. Também é o recurso menos chamativo do anúncio, o que geralmente é sinal de que é o verdadeiro.
Subscriptions: o Cursor Projects no piloto automático
A outra manchete é que um Project pode agir sem você. O Cursor chama isso de Subscriptions, e o coordenador pode "monitorar um canal do Slack, rodar em um horário ou acompanhar todos os seus PRs, corrigindo a CI e agindo quando são abertos ou mesclados." O exemplo concreto do changelog: conecte o Slack, aponte para um canal de relatos de bugs, e o coordenador passa a delegar uma correção a cada bug que chega.
Por baixo está o sistema de Automations do Cursor, que é mais capaz do que o blog do Projects deixa transparecer. Os gatilhos podem disparar em um horário cron, em eventos de controle de código (PR aberto, enviado, mesclado, CI concluída), em mensagens do Slack ou reações com emoji, em um webhook para o qual você faz POST ou em eventos do Linear, Sentry e PagerDuty. Uma automação pode então abrir PRs, comentar, pedir revisores, postar no Slack, usar servidores MCP e manter anotações persistentes em um arquivo MEMORIES.md entre execuções.
Dois limites que vale conhecer antes de depender disso: apenas canais públicos do Slack são visíveis aos gatilhos do Slack por enquanto, e os gatilhos de PR não rodam em PRs de forks (exceto o gatilho de mesclagem). Nenhum é impeditivo, mas são o tipo de coisa que você quer descobrir antes, não depois, de montar um fluxo em torno deles.
Os três trabalhos para os quais o Cursor Projects foi feito
O Cursor é refrescantemente específico sobre onde isso se encaixa, e bate com o que eu realmente usaria.
- Desenvolvimento de funcionalidades. Um Project começa com agentes pesquisando o sistema e registrando o que aprendem; depois o coordenador planeja e envia agentes para construir e testar partes em paralelo. Após o lançamento, o mesmo Project pode monitorar logs e tratar relatos de bugs "com todo o contexto por trás das decisões originais". Essa última parte é a recompensa do contexto compartilhado.
- Migrações. O Cursor as chama de "fáceis de começar e difíceis de terminar", o que é exatamente certo. Você estabelece uma abordagem segura com o coordenador, e ele a aplica de forma incremental no código. Você revisa cada PR com atenção no início e depois relaxa conforme as correções se sustentam.
- Gardening (manutenção). Trabalho que nunca acaba: qualidade de código, vigilância de regressões. O exemplo real do Cursor é um Project de design system em que o coordenador “examina cada novo PR, extrai componentes que pertencem ao design system e adiciona uma regra de lint sempre que vê o mesmo erro duas vezes”, a caminho de tocar de 20 a 100 PRs por dia.
Se seu trabalho não se parece com um desses três, um Project provavelmente é a ferramenta errada. Aqui está a checagem rápida que eu faria antes de abrir um.
Quanto custa o Cursor Projects
Aqui eu desaceleraria. Não existe preço de tabela para o Projects, e não é o Cursor escondendo o jogo: é realmente baseado em uso. Projects roda em Cloud Agents, e a cobrança decorre daí.
| Componente | Como é cobrado | O que você precisa |
|---|---|---|
| Cursor Projects (o recurso) | Sem cobrança independente; em beta | Um plano pago do Cursor |
| Subagentes na nuvem | Preço de API do modelo selecionado; você define um limite de gastos no primeiro uso | Controle de código conectado por um administrador |
| Subagentes em paralelo | Cerca de 5x os tokens para 5 agentes contra 1 | Ter consciência de que paralelismo multiplica o custo |
| Automations / Subscriptions | Cobradas como uso de agentes na nuvem, no contexto máximo de cada modelo | Um plano pago; automações da equipe são cobradas do pool da equipe |
O que você precisa internalizar: um coordenador que sobe muitos subagentes em paralelo é um multiplicador de custo, não almoço grátis. Em um Project movimentado, "milhares de agentes" é um teto de marketing, mas até um punhado de agentes paralelos na nuvem a preços de modelos de ponta soma rápido. Essa é exatamente a preocupação que apareceu nas reações da comunidade, e é legítima. Se você já é do tipo de equipe que acompanha o custo por resolução de um agente de IA, vai querer a mesma disciplina aqui: defina limites de gastos e trate as Subscriptions automatizadas como um medidor ligado.
O que as pessoas estão dizendo
O tuíte de lançamento foi muito bem, com 5.861 curtidas no primeiro dia. Mas a reação que achei mais reveladora foi a resposta mais popular, postada onze minutos depois:
"can you pls just merge the subscriptions instead of just adding extra features?"
Essa é a tensão do dia do lançamento em uma linha. O Cursor está empilhando capacidades, e alguns de seus usuários mais engajados prefeririam que ele simplificasse o que já existe em vez de lançar mais uma superfície paga. Não é tanto uma crítica ao recurso quanto um sinal de que o pacote de coordenador, nuvem e subscriptions é muita superfície nova de uma só vez.
A pergunta estratégica mais afiada veio do gestor de produto Aakash Gupta, ao escrever sobre a direção do Cursor rumo a frotas de agentes em abril de 2026:
"They're saying: the model is a commodity, the workflow is the moat. The question is whether developers want a dedicated cockpit for managing agent fleets, or whether the terminal where the model lives is enough."
Acho que essa é a aposta real do Projects. Os modelos estão cada vez mais intercambiáveis, então o Cursor aposta que a camada de orquestração, o coordenador, o contexto compartilhado e os gatilhos, é onde ele consegue fidelizar. Querer um cockpit ou uma linha de comando é questão de gosto, e engenheiros sensatos ficam dos dois lados. Se você está ponderando essa escolha, nosso panorama de alternativas ao Cursor e a comparação Cursor vs Windsurf cobrem o espectro "cockpit vs terminal", assim como qualquer comparação com o OpenAI Codex ou a CLI do Claude Code.
Onde o Projects se encaixa e onde não
Minha opinião depois de revirar a documentação: o Cursor Projects é a versão mais coerente de "gerenciar uma frota de agentes" que já vi ser lançada, e o design do contexto compartilhado é o motivo. O modelo de coordenador resolve um incômodo real, a execução na nuvem é sensata, e a honestidade da documentação sobre custos de tokens e lentidão dos subagentes gera confiança.
Onde eu pisaria no freio: está em beta, o modelo de custo premia a contenção, e tudo pressupõe que seu trabalho é grande e duradouro. Para um dev solo fazendo edições rápidas, é mais maquinário do que o trabalho exige, e um chat simples é a melhor ferramenta. Também aguça uma ansiedade real que uma resposta no thread de lançamento colocou bem: quanto mais um coordenador delega, menos linhas de código foram escritas e revisadas por um humano. O Projects depende muito de você ser disciplinado ao revisar os PRs que ele devolve. Isso é uma característica, não um defeito, mas fica por sua conta.
E há um ponto de categoria que vale mencionar, porque foi o que mais me ocupou a cabeça ao ler o anúncio.
O Cursor é infraestrutura; um colega é outra coisa
O Cursor Projects é infraestrutura de programação agêntica. Ele constrói seu software. Não é um colega que aparece e faz um trabalho definido por você, e não tenta ser. É uma distinção real, não uma crítica.
É exatamente assim que penso sobre o que construímos na eesel. A eesel é uma plataforma de colegas de IA, e você contrata colegas prontos para trabalhar em funções específicas: um colega de IA para o helpdesk que entra na sua fila de suporte e um redator de blog com IA. Cada um chega com as habilidades, integrações e contexto da empresa para sua função, e trabalha desde o dia zero. Onde o Cursor dá um cockpit para construir software, a eesel dá um colega que já faz o trabalho.
O interessante é onde os dois se encontram. Porque o Cursor Projects adora uma CLI e um gatilho, e a eesel também. A CLI da eesel é uma forma amigável a agentes de operar o mesmo colega e workspace da eesel que você usaria no painel: uma pessoa pode rodá-la em um terminal, scripts podem automatizá-la, e agentes de programação como o Cursor, o Claude Code e o Codex podem controlá-la. Assim, um Cursor Project que corrige seu app pode, no mesmo fôlego, pedir à CLI da eesel que inspecione as instruções do seu colega de suporte, proponha uma mudança delimitada e revise as respostas de teste antes de um humano aprovar. O mesmo instinto de contexto compartilhado, aplicado ao colega que atende seus clientes em vez do código que os serve.
Se o Projects faz você pensar em agentes fazendo trabalho de verdade enquanto você dorme, esse é o instinto certo. Para o lado de suporte e conteúdo desse trabalho, essa é a lacuna que a eesel preenche, e é grátis para experimentar.
Experimente a eesel para o trabalho que um agente de programação não fará
O Cursor Projects reconstruirá de bom grado seu fluxo de cobrança. O que ele não fará é responder aos 400 tickets de "cadê meu reembolso?" que essas decisões geram. Esse é o trabalho para o qual um colega eesel de IA para o helpdesk é contratado: ele se conecta ao Zendesk (e a Freshdesk, Gorgias, Slack e mais) em minutos, aprende com seus tickets passados e sua central de ajuda e começa a redigir ou resolver desde o primeiro dia. É um agente de IA contratado para a fila, com preço fixo por ticket em vez de por usuário.
E se você vive no terminal, não precisa sair dele. A CLI da eesel permite que seu agente de programação inspecione e ajuste o mesmo colega eesel que o painel usa, de modo que a IA que entrega seu código também possa ajudar a calibrar a IA que atende seus clientes. Você pode experimentar a eesel de graça, sem cartão de crédito, e simulá-la com seus tickets históricos reais antes que ela toque em uma única conversa ao vivo.
Perguntas frequentes
O que é o Cursor Projects?
O Cursor Projects é um recurso lançado em 10 de setembro de 2026 que permite conduzir um trabalho longo (uma funcionalidade, uma migração, um app inteiro) por meio de um único agente coordenador. Em vez de abrir um chat novo por tarefa, você conversa com o coordenador, que planeja o trabalho, delega a subagentes na nuvem e devolve pull requests prontos para você.
Quanto custa o Cursor Projects?
O Projects não tem preço separado. Ele roda nos Cloud Agents do Cursor, cobrados pelo preço da API do modelo escolhido, e você precisa de um plano pago do Cursor para executá-los. Rodar cinco subagentes em paralelo consome cerca de cinco vezes os tokens de um único agente, então defina um limite de gastos antes de escalar.
O Cursor Projects vale a pena para equipes pequenas?
Ele brilha em trabalhos que duram mais que um único chat: migrações, manutenção contínua ou uma funcionalidade que você vai acompanhar por semanas. Para uma correção pontual, um chat normal do Cursor é mais barato e simples. Leia nossa análise completa do Cursor antes de comprometer uma equipe com ele.
O Cursor Projects pode funcionar sem eu dar comandos?
Sim. A camada de automação, chamada Subscriptions, pode monitorar um canal público do Slack, rodar em um horário ou acompanhar seus pull requests e agir quando eles são abertos ou mesclados. É o mesmo mecanismo das Automations do Cursor, que também se conectam a GitHub, GitLab, Linear, Sentry e PagerDuty.
Qual é a diferença entre o Cursor Projects e um colega de IA como a eesel?
O Cursor Projects é infraestrutura de agentes para construir software. A eesel é um colega que você contrata para um trabalho definido, como um colega de IA para o helpdesk ou um redator de blog com IA, e que funciona já de início. Eles se complementam: um agente de programação como o Cursor pode até controlar um colega eesel pela CLI da eesel.