A Cursor lançou o Projects em 10 de setembro de 2026. Em vez de abrir um chat novo para cada tarefa, você trabalha em uma conversa persistente com um agente coordenador que planeja um grande volume de trabalho e entrega a programação propriamente dita a uma frota de subagentes rodando em paralelo, em sua maioria na nuvem.
O interessante não é "mais agentes". É a mudança no que passa a ser o seu trabalho. Você deixa de vigiar um único agente e passa a dirigir o trabalho em um nível mais alto, revisando resultados prontos em vez de ver o código sendo digitado. A Cursor chama isso de "terceira era do desenvolvimento de software" e diz internamente que usuários que trabalham principalmente no Projects fazem merge de seis vezes mais PRs.
É realmente útil para trabalho que dura mais que um único chat: grandes funcionalidades, migrações longas e manutenção sem fim. Também é uma questão real de custo e controle, porque um coordenador que inicia muitos subagentes na nuvem cobra por tarifas de API e coloca mais linhas de código entre você e a última pessoa que as leu. Eu construo sistemas de agentes para viver na eesel, então abaixo vou mostrar exatamente como o Projects funciona, quanto custa, onde os céticos têm razão e como esse modelo de "você dirige, os agentes trabalham" se parece fora do código.
O que o Cursor Projects realmente é
Um Project é um contêiner para um trabalho grande. A descrição da própria Cursor: ele permite "assumir volumes maiores de trabalho, como uma funcionalidade, uma migração ou um app completo". Enquanto um chat esquece tudo assim que você o fecha, um Project mantém o contexto por meses, pode delegar a muitos agentes e até agir em trabalho recorrente sem ser solicitado.
Você inicia um pela navegação à esquerda, descreve o que quer construir e o coordenador assume a partir daí. Está em beta e sendo liberado para todos os usuários a partir da data de lançamento.
Se você usava o Cursor como uma ferramenta de autocompletar mais chat, este é um salto maior do que o changelog dá a entender. A unidade de trabalho passa de "uma mensagem" para "um projeto", e aquilo que você gerencia passa de "o código" para "os agentes".
A mudança real: de um agente para um coordenador
A Cursor vem construindo isso há um tempo. Já em fevereiro de 2026 ela descrevia uma "terceira era" em que "frotas de agentes assumem volumes inteiros de trabalho" e o desenvolvedor dirige o trabalho em vez de cada agente. O Projects é essa visão entregue.
Esta é a trajetória, porque é a forma mais clara de ver o que mudou:
Na era um, você escrevia o código e a IA sugeria a próxima linha. Na era dois (onde ainda estão a maioria das ferramentas de programação agêntica), você dá um prompt a um agente por tarefa e o observa trabalhar. O Projects é uma aposta na era três: você dirige um coordenador, e o coordenador comanda a frota. O coordenador não escreve código ele mesmo; como ele delega em vez de executar, "nunca fica bloqueado e responde sempre à direção".
Esse último detalhe importa mais do que parece. A razão pela qual um único agente é frustrante é que ele mergulha na tarefa e você espera. Um coordenador continua livre para conversar com você enquanto seus subagentes trabalham, e é isso que faz "dirigir, não vigiar" ser diferente na prática.
Como um Project funciona por baixo dos panos
Por trás do marketing, o Projects é uma camada fina de orquestração sobre quatro coisas que a Cursor já tinha: o coordenador, os subagentes, a execução na nuvem e os gatilhos de automação. Veja como se encaixam.
O coordenador planeja e delega
Você supervisiona um Project conversando com seu agente coordenador. Ele "planeja o trabalho, delega a agentes que o implementam e traz o trabalho pronto de volta para você conferir", criando e gerenciando agentes em seu nome e executando em paralelo quantos o trabalho precisar. Por baixo, cada subagente trabalha em sua própria janela de contexto, roda de forma autônoma e devolve o resultado ao agente pai. Desde o Cursor 2.5, os subagentes podem até iniciar seus próprios subagentes filhos, embora a árvore pare em um nível de profundidade.
Uma ressalva honesta que a documentação deixa clara: paralelismo não é velocidade grátis. Rodar cinco subagentes em paralelo usa cerca de cinco vezes os tokens de um único agente, e eles podem até ser mais lentos em tarefas simples porque cada um começa com um contexto limpo. O ganho é isolamento e escala, não ritmo puro.
Nuvem por padrão, local quando necessário
O Projects roda nos Cloud Agents (as VMs isoladas na nuvem antes chamadas de Background Agents). Um Project "roda em seu próprio computador, então fechar o notebook não o interrompe", e é isso que permite rodar muito mais subagentes em paralelo do que sua máquina suportaria. Quando algo precisa rodar na sua máquina, o coordenador inicia um agente local para isso.
O que realmente importa aqui é o ambiente. Como a Cursor diz, "não configurar um ambiente de desenvolvimento para seus agentes na nuvem é como não dar um computador aos seus engenheiros". Você o define por configuração guiada por agente, um snapshot salvo ou um Dockerfile, e os agentes na nuvem clonam do GitHub, GitLab, Azure DevOps ou Bitbucket e fazem push para uma branch na entrega. Se você já configurou a integração do Claude Code com o GitHub ou algo parecido, o formato vai parecer familiar.
Contexto compartilhado que se acumula
Esta é a peça que considero mais subestimada. A frase da Cursor é "você não deveria precisar integrar um agente toda vez que começa uma tarefa". Cada Project mantém um conjunto de arquivos que sincronizam entre todas as máquinas, na nuvem e locais, que seus agentes usam, e os agentes escrevem nele pesquisas, artefatos e o que aprendem sobre sua base de código. O exemplo: "se um agente descobre como testar um serviço, todos os agentes futuros podem usar essas instruções".
O resultado é que o contexto cresce com o Project e o coordenador fica mais eficaz com o tempo. É o mesmo princípio de dar a um agente de suporte com IA uma base de conhecimento real em vez de explicar seu produto a cada sessão, só que voltado a uma base de código.
Assinaturas rodam sem prompt
O coordenador pode vigiar um canal do Slack, rodar em um agendamento ou acompanhar todos os seus PRs, consertando o CI e agindo quando eles são abertos ou mesclados. A Cursor comercializa isso como "assinaturas"; na documentação é o sistema de Automations, que dispara agentes na nuvem por agendamentos ou por eventos do GitHub, GitLab, Slack, webhooks, Linear, Sentry e PagerDuty. Aponte-o para um canal de relatos de bugs e ele começa a delegar toda vez que chega um bug. Esta é a camada de automação que transforma o Projects de uma ferramenta que você abre em algo que roda sozinho, a mesma ideia orientada por gatilhos de um chatbot de IA para Slack ou de um chatbot de IA para helpdesk que age em novas mensagens.
Os três tipos de trabalho para os quais o Projects foi feito
A Cursor é refrescantemente específica sobre onde isso se encaixa, e isso se resume a três padrões. Vale internalizar esta parte, porque o Projects definitivamente não é para uma correção de cinco minutos.
- Desenvolvimento de funcionalidades. Os agentes pesquisam o sistema e registram o que aprendem como contexto compartilhado, o coordenador planeja e os subagentes constroem e testam partes em paralelo. Depois do lançamento, o mesmo Project pode monitorar logs e tratar relatos de bugs com todo o contexto por trás das decisões originais.
- Migrações. A expressão da Cursor é trabalho "fácil de começar e difícil de terminar". Você combina uma abordagem segura com o coordenador, que então a aplica de forma incremental em toda a base de código. Você revisa cada PR de perto no começo e relaxa conforme o padrão se mantém.
- Gardening. Trabalho que nunca termina de verdade, como qualidade de código e regressões. O exemplo da própria Cursor é um Project de design system cujo coordenador examina cada novo PR, extrai componentes 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.
O fio comum: compensa quando o trabalho "vai durar mais que um único chat". Para uma correção rápida de bug, um agente simples é mais rápido e mais barato.
Não sabe em qual categoria seu trabalho se encaixa? Veja uma forma rápida de conferir antes de iniciar um Project.
Encaixe forte. Deixe os agentes pesquisarem primeiro, o coordenador planejar, depois construírem e testarem partes em paralelo, e mantenha o Project vivo para tratar bugs mais tarde.
O caso clássico do Projects: fácil de começar, difícil de terminar. Defina uma abordagem segura com o coordenador, revise os primeiros PRs de perto e relaxe conforme o padrão se comprovar.
Configure uma assinatura para o coordenador vigiar cada novo PR, extrair padrões e adicionar regras de lint. Este é o ponto ideal do "roda sem você".
Use um agente simples do Cursor. Uma correção pontual não precisa de coordenador, contexto compartilhado nem VMs na nuvem, e um Project custaria mais tokens sem nenhum ganho.
Quanto custa o Cursor Projects
Não há preço de tabela para o Projects, e essa é a manchete honesta. O Projects roda em Cloud Agents, e os Cloud Agents são cobrados pelo preço de API do modelo que você seleciona. É necessário um plano pago do Cursor para executar agentes na nuvem, e um administrador precisa conectar primeiro o controle de código-fonte. Veja o quadro de custos em termos simples.
| O quê | Como funciona | O porém |
|---|---|---|
| Requisito de plano | É preciso um plano pago do Cursor para executar agentes na nuvem | O plano gratuito não executa Projects na nuvem |
| Unidade de cobrança | Os agentes na nuvem cobram pelo preço de API do modelo escolhido | O custo acompanha os tokens usados, não uma mensalidade fixa |
| Paralelismo | O coordenador executa quantos subagentes o trabalho precisar | Cinco subagentes em paralelo ≈ cinco vezes os tokens |
| Controle de gastos | Você define um limite de gastos no primeiro uso | O limite é a proteção; por padrão não há teto fixo |
| Automações | As assinaturas são cobradas pelo uso de agentes na nuvem e usam a janela de contexto máxima de cada modelo | Sem opção de contexto, então execuções em segundo plano podem consumir muitos tokens |
Um exemplo prático deixa isso concreto. O Project de "gardening" do design system que a Cursor descreve está a caminho de tocar de 20 a 100 PRs por dia. Cada uma dessas execuções é um agente na nuvem (muitas vezes vários subagentes) cobrando pelas tarifas de API do modelo, o dia todo, você esteja olhando ou não. Isso pode ser um ótimo negócio frente ao tempo de um engenheiro, ou uma conta surpreendente, dependendo inteiramente do seu limite de gastos e de quão verbosos são os modelos. É por isso que o panorama completo de preços do Cursor importa mais do que nunca com o Projects, e por isso as preocupações com custo baseado em uso são o tema recorrente nas reações da comunidade, o que nos leva à parte interessante.
Um "cockpit para frotas de agentes" é o que os desenvolvedores realmente querem?
Aqui quero ser justo, porque a reação no dia do lançamento não foi só aplauso. O post de lançamento teve 5.861 curtidas, mas a resposta mais forte logo de início foi cansaço, não admiração:
"can you pls just merge the subscriptions instead of just adding extra features?"
Esse é o comentário mais votado no próprio anúncio. Ele traduz uma preocupação real: o Projects empilha mais uma superfície paga e medida na nuvem sobre um produto que já é cheio. E em abril de 2026, o redator de produto Aakash Gupta resumiu bem a aposta estratégica (escrevendo sobre a direção da Cursor, não sobre este lançamento específico):
"Cursor's move is to go vertical on the orchestration layer... 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."
Esse é todo o debate em duas frases. Alguns desenvolvedores adoram a superfície estruturada e revisável. Elliot Arledge, escrevendo em julho de 2026, expôs bem o argumento a favor:
"for most important dev and contracts I've been doing, cursor is my go-to and its not even close... being able to inspect code and ensure that production systems don't get slopified is super important to me."
A ansiedade contrária, em uma resposta nessa mesma conversa, é a que acho mais digna de ser levada a sério: "I really fear losing control over my codebase" (Tenho muito medo de perder o controle da minha base de código). Quanto mais o coordenador delega, menos linhas um único revisor realmente leu. Isso não é motivo para evitar o Projects. É motivo para manter sua disciplina de revisão exatamente onde estava no primeiro dia, principalmente quando o padrão "se sustenta" e você é tentado a passar o olho. Se você está comparando com outras ferramentas, nossos comparativos de alternativas ao Cursor e Cursor vs Windsurf mostram onde cada uma se posiciona.
Como esse modelo de "dirigir a frota" se parece além do código
O que mais me chamou a atenção, construindo sistemas de agentes na eesel: o Cursor Projects é uma instância específica de programação de um padrão que está aparecendo em todo lugar. Um coordenador que planeja e delega, subagentes que fazem o trabalho, contexto compartilhado que se acumula, gatilhos que o executam sem prompt. Troque "base de código" por "fila de suporte" ou "pipeline de conteúdo" e a arquitetura é a mesma.
É exatamente assim que a eesel é construída, só que voltada para outros trabalhos. A eesel é uma plataforma de colegas de equipe com IA, e você contrata colegas prontos para trabalhar em uma função específica em vez de um bot de uso geral. O elenco atual é um colega de helpdesk com IA e um redator de blog com IA, cada um chegando com as habilidades, integrações e contexto da empresa para sua função. O colega de helpdesk entra na sua fila existente e redige ou resolve tickets; o redator de blog pesquisa e escreve conteúdo longo da forma como este artigo foi feito. É a mesma mudança de "você dirige, o agente trabalha" que a Cursor vende, voltada à automação de atendimento ao cliente e a equipes de conteúdo SEO em vez de pull requests.
E como este artigo trata, na verdade, de fluxos de trabalho agênticos orientados por terminal, vale destacar o paralelo com a CLI. O Cursor permite controlar subagentes na nuvem a partir do editor com comandos como /in-cloud e /autopilot. A eesel oferece o mesmo tipo de superfície programável para seus colegas: a CLI da eesel (@eesel/cli) é um binário real do npm cuja documentação diz literalmente "everything on this site can be done from the terminal". Você pode usar eesel integrations connect, editar as regras permanentes do agente com eesel instructions, controlar ações arriscadas com eesel approvals e acompanhar cada execução, da mais recente à mais antiga, com eesel activity. Todo comando imprime JSON e aceita --dry-run, então se encaixa direto no CI, e cada workspace também é um servidor MCP, conectado como qualquer outra integração MCP, o que significa que um agente de programação como o Cursor, o Claude Code ou o Codex pode operar diretamente seu colega de suporte ou de conteúdo. Essa visão de observabilidade eesel activity corresponde quase um a um ao "bring the finished work back to you to check" do Cursor.
O único ponto em que um colega de suporte ou de conteúdo precisa ir além de um coordenador de código: você não pode "revisar cada PR" quando o agente está falando com um cliente real. É por isso que a eesel permite simular um colega com seus tickets históricos reais antes que ele responda, e manter as ações sob aprovação até você confiar nele. É a mesma lição que os céticos do Cursor apontam, aplicada a um trabalho que chega direto a uma pessoa.
Experimente a eesel
Se o Cursor Projects convenceu você do modelo de "dirigir uma frota de agentes, não vigiá-los" e você comanda uma equipe de suporte ou de conteúdo, é exatamente isso que a eesel faz para esses trabalhos. Você conecta um colega de helpdesk com IA ao Zendesk, Freshdesk, Gorgias ou Slack, ele aprende seu histórico e sua central de ajuda e começa a redigir e resolver tickets; ou aponta o redator de blog com IA para seu pipeline de conteúdo, em vez de juntar ferramentas de escrita com IA separadas. Ele pode ser controlado pelo painel ou inteiramente pelo terminal com a CLI e o servidor MCP da eesel, e você pode simulá-lo com dados reais antes de entrar no ar. É grátis para testar.
Perguntas frequentes
O que são os Cursor Projects?
O Cursor Projects, lançado em 10 de setembro de 2026, é uma forma de conduzir um grande volume de trabalho (uma funcionalidade, uma migração, manutenção contínua) por meio de uma única conversa no Cursor. Em vez de abrir um chat novo para cada tarefa, você fala com um agente coordenador que planeja o trabalho e o delega a vários agentes executando em paralelo.
Quanto custam os Cursor Projects?
Não há preço separado para o Projects. Ele roda nos Cloud Agents do Cursor, que são cobrados pelo preço de API do modelo que você escolher, e você precisa de um plano pago para executar agentes na nuvem. Como um coordenador pode iniciar muitos subagentes ao mesmo tempo, o custo acompanha o uso, e não uma taxa fixa. Veja nosso detalhamento completo dos preços do Cursor para os detalhes dos planos.
Como o agente coordenador é diferente de um chat normal do Cursor?
Um chat normal faz o trabalho na sua frente. O coordenador não escreve código ele mesmo; ele planeja, delega a subagentes e traz o trabalho pronto de volta para você revisar. É a mesma mudança rumo à programação agêntica que você vê em ferramentas como o OpenAI Codex e o GitHub Copilot.
Os Cursor Projects podem rodar sem eu acompanhar?
Sim. Os Projects usam "assinaturas" para que o coordenador possa vigiar um canal do Slack, rodar em um agendamento ou acompanhar seus PRs e consertar o CI sem um prompt. É a mesma ideia dos fluxos de trabalho de agentes automatizados em outras ferramentas. No suporte, os fluxos de atendimento ao cliente com IA da eesel funcionam com o mesmo modelo orientado por gatilhos.
Os Cursor Projects são seguros em uma base de código de produção?
Podem ser, se você mantiver uma pessoa no circuito. Os subagentes podem trabalhar em branches isoladas ou em suas próprias VMs na nuvem, e o coordenador devolve o trabalho pronto para revisão antes do merge. O risco real é revisar menos conforme você confia mais. Se você usa agentes em trabalho voltado ao cliente, uma ferramenta como a eesel permite simular com histórico real e condicionar as ações a aprovações antes de tudo.