O Que É Cursor Origin? A Plataforma Git para Agentes de IA Explicada

O Cursor agora quer hospedar seu código, não apenas escrevê-lo. Em 17 de agosto de 2026, a empresa começou a lançar o Origin, seu próprio serviço de hospedagem git, em fase beta inicial para todos os planos pagos. Repositórios, pull requests, navegação de código e sincronização bidirecional com o GitHub foram lançados no primeiro dia, tudo em uma nova aba "Codebase" dentro do editor.

A proposta é direta: os "forges" git foram projetados para humanos que fazem commits algumas vezes ao dia, e o Cursor aposta que a próxima década do controle de versão será moldada por agentes que abrem branches, atualizam PRs e mesclam trabalho 24 horas por dia. O Origin é a primeira plataforma de hospedagem projetada em torno dessa premissa desde o início.

Se sua equipe desenvolve APIs, isso o afetará mais cedo do que você imagina: suas especificações OpenAPI, seus testes de contrato baseados em CI e seu fluxo de trabalho de revisão vivem onde quer que seu remote git aponte. Aqui está o que o Origin faz hoje, o que está faltando e como manter um fluxo de trabalho de API (incluindo a automação de testes do Apidog) intacto se você experimentá-lo.

O Que é o Origin

Origin é um "forge" git em nuvem operado pela Cursor. O beta inicial inclui:

• Repositórios hospedados que você cria a partir da aba "Codebase", da web em cursor.com/codebase, ou de um agente Cursor no meio de uma tarefa. Os remotes seguem o padrão https://cursor.com/codebase/{owner}/{repo}, e os comandos padrão git clone, push e pull funcionam com eles.
• Pull requests com as partes que você esperaria: um cronograma, commits, verificações, diffs, comentários e mesclagem, revisáveis dentro do editor ou no navegador.
• Navegação e busca de código na web, com configurações em nível de repositório e de codebase.
• Uma CLI dedicada para fluxos de trabalho de terminal, separada do editor.
• Integração com agentes, que é o ponto principal: agentes podem ler a codebase, responder perguntas sobre ela, fazer alterações, atualizar PRs e fazer push de branches da mesma interface onde você revisa o trabalho deles. Conforme o changelog, mais “recursos nativos para agentes serão lançados em breve”.

Disponibilidade: Apenas planos Pro, Teams e Enterprise. Usuários de planos gratuitos não podem criar repositórios Origin, e organizações empresariais podem optar por não usar o Origin. Detalhes como cotas de armazenamento, uma API pública e webhooks ainda não estão documentados, o que é importante lembrar antes de mover algo importante. Consulte a documentação do Origin da Cursor para o estado atual.

O Origin encerra um mês agitado para a empresa; a cobertura da imprensa, incluindo o relatório do SiliconANGLE, também observa que o lançamento ocorreu dias depois que a SpaceX concluiu sua aquisição da Cursor. Para uma atualização sobre o lado do editor do produto, nosso guia completo sobre o Cursor AI cobre os fundamentos.

A sincronização com o GitHub é a parte inteligente

Ninguém migra uma empresa do GitHub em um fim de semana, e o Cursor sabe disso. Então, o beta do Origin aposta em uma sincronização bidirecional em vez de uma migração:

• Espelhe um repositório GitHub para o Origin e os repositórios sincronizados atualizam em tempo real.
• Comentários e reações de PRs sincronizam nos dois sentidos em segundos: um comentário deixado no Cursor é publicado no GitHub, e uma resposta do GitHub aparece no Cursor.
• O GitHub permanece a fonte da verdade para qualquer repositório que tenha sido iniciado lá. Pushes continuam fluindo para o GitHub; o Origin é um espelho ativo com uma experiência de agente melhor, não um remote de substituição.
• As permissões de acesso espelham suas configurações de leitura/escrita do GitHub, para que a sincronização não amplie silenciosamente quem pode acessar um repositório.

Este é o mesmo padrão de adoção de baixo compromisso que funcionou para o Cursor contra o VS Code: não pedir para ninguém sair, sentar ao lado do incumbente e deixar que o novo fluxo de trabalho vença pela conveniência. Você pode experimentar a interface de revisão de PR do Origin na segunda-feira sem avisar sua equipe de plataforma, porque nada em sua configuração do GitHub muda.

O subtexto estratégico é mais difícil de ignorar. O GitHub tem sido o lar padrão do código por quinze anos, e sua própria história de IA passa pelo Copilot, que compete diretamente com o Cursor; comparamos os dois em Cursor vs GitHub Copilot. A construção de seu próprio "forge" pelo Cursor é uma declaração de que ele não quer mais que seu roteiro de agentes seja limitado pela plataforma de um concorrente.

O que está faltando (e é muito, por enquanto)

O beta é um "forge", não uma plataforma DevOps completa. No lançamento, o Origin possui:

• Sem CI/CD nativo. Em vez disso, Depot e Buildkite se conectam através da aba "Apps" de um repositório e podem executar seus arquivos de workflow existentes do GitHub Actions em repositórios do Origin. É uma ponte pragmática, mas é uma dependência de terceiros onde o GitHub possui um produto integrado.
• Sem issues, sem discussões, sem wiki. A revisão de código é o único primitivo de colaboração.
• Sem auto-hospedagem, sem API pública documentada, sem webhooks, sem limites de armazenamento declarados.
• Um parceiro de lançamento notável: conecte o Vercel pela aba "Apps" e cada PR recebe um deploy de pré-visualização que vai para produção na mesclagem, o mesmo fluxo que o Vercel executa para repositórios do GitHub. (O Vercel tem entregado rápido ultimamente; é o mesmo Gateway que está atualmente executando o desconto GPT-5.6 Sol.)

Nenhuma dessas lacunas importa muito enquanto o GitHub permanecer a fonte da verdade por trás da sincronização. Elas importam enormemente no dia em que uma equipe considerar tornar o Origin primário. Trate o beta como uma camada de revisão e agentes, não como infraestrutura.

O que isso significa especificamente para equipes de API

Seu fluxo de trabalho de API provavelmente toca o "forge" em três lugares: a especificação vive no repositório, os testes de contrato são executados em CI em cada PR, e os revisores aprovam as alterações em ambos. Veja como cada um se mapeia para o Origin hoje.

Especificações e revisão de design.

Se você segue um fluxo de trabalho "design-first", seu arquivo OpenAPI é o artefato mais revisado no repositório. Os diffs de PR do Origin tratam YAML como qualquer outro texto, e a sincronização bidirecional de comentários significa que um revisor de API que vive no GitHub e um operador de agente que vive no Cursor veem a mesma discussão. Nada quebra, nada melhora ainda; a parte interessante chega quando os agentes começam a propor alterações de especificação como PRs, que é exatamente o loop para o qual o Origin foi construído. Nosso guia para executar o Apidog CLI dentro do Cursor já aborda como permitir que o agente do editor valide uma especificação antes de fazer o commit.

Testes de contrato CI.

O Apidog CLI é executado como uma etapa em qualquer sistema de CI, e a resposta do Origin para CI é “traga seus workflows do GitHub Actions via Depot ou Buildkite.” Na prática, isso significa que uma etapa de workflow existente como apidog run --scenario smoke-tests deve ser transferida sem modificações, porque o formato do arquivo de workflow é o mesmo. A ressalva honesta: não verificamos a camada de compatibilidade do Depot para Actions contra todas as ações existentes, e ninguém mais o fez esta semana. Execute seu pipeline contra um repositório espelhado descartável antes de confiar nele com uma branch de lançamento.

Mudanças impulsionadas por agentes precisam de "portões" à prova de agentes.

Toda a premissa do Origin é que mais código chegue dos agentes, mais rápido. Isso eleva o valor das verificações automatizadas e determinísticas em cada PR, porque os revisores humanos se tornam o gargalo. Um conjunto de testes de contrato que falha a compilação quando um schema de resposta muda é precisamente o tipo de "portão" que escala com o throughput de agentes, e é uma configuração de cinco minutos no Apidog: defina asserções contra sua especificação uma vez, execute-as do CLI em qualquer CI que execute seus PRs do Origin. Baixe o Apidog se você quiser esse "portão" em vigor antes que seus agentes obtenham acesso de push, e veja nosso passo a passo de testes de QA com o Cursor para o loop de teste mais amplo.

Você deveria experimentar?

Um atalho para a decisão:

• Desenvolvedores solo e pequenas equipes em planos pagos do Cursor: sim, baixo risco. Espelhe um repositório, use a visualização de PR, mantenha o GitHub como verdade. Você não perde nada se o Origin não se fixar.
• Equipes com grande investimento em GitHub Actions: experimente em um projeto paralelo primeiro. Seus workflows teoricamente são portados via Depot ou Buildkite, mas “teoricamente portados” não é um plano de migração.
• Qualquer pessoa cuja história de conformidade mencione o GitHub: espere. Sem auto-hospedagem, sem API documentada e um rótulo de beta inicial tornam o Origin um ponto de partida inviável para código regulamentado hoje.
• Equipes que já usam agentes do Cursor intensamente: é para eles que o Origin existe. Se você está usando os recursos de agente do Cursor diariamente, ter agentes abrindo e atualizando PRs em um "forge" que os trata como usuários de primeira classe é um ganho real no fluxo de trabalho agora.

O "forge" está se tornando uma superfície para agentes

A verdadeira história não é que o GitHub tem um novo concorrente. É que o Cursor pensa que o próprio repositório está prestes a se tornar principalmente uma interface para agentes, com humanos revisando em vez de criar a maioria das mudanças. Quer o Origin vença ou não, cada "forge" será puxado nessa direção, e as equipes de API sentirão isso primeiro, porque especificações e testes de contrato são os "portões" de revisão mais automatizáveis em software.

A preparação é a mesma em qualquer caso: torne suas verificações de API scriptáveis e agnósticas ao "forge". O Apidog mantém suas especificações, mocks e cenários de teste em um só lugar e os executa a partir de uma CLI que não se importa se o PR veio de um humano no GitHub ou de um agente no Origin. Experimente gratuitamente, e seus "portões" de revisão se movem com você, não importa quem vença a guerra dos "forges".

FAQ

O Cursor Origin é gratuito? Não. O armazenamento de código do Origin requer um plano pago do Cursor (Pro, Teams ou Enterprise). Usuários de planos gratuitos não podem criar repositórios Origin, e organizações empresariais podem optar por não usar o Origin inteiramente.

Preciso sair do GitHub para usá-lo? Não. O design de lançamento assume que você não precisará: espelhe um repositório GitHub para o Origin e o GitHub permanece a fonte da verdade, com pushes, comentários de PR e reações sincronizando nos dois sentidos em tempo quase real.

O Origin possui CI/CD? Não nativamente. Depot e Buildkite se conectam através da aba "Apps" e executam seus arquivos de workflow existentes do GitHub Actions. O Vercel também está integrado para deploys de pré-visualização de PR.

Agentes podem usar o Origin diretamente? Sim, essa é a característica principal: os agentes do Cursor podem criar repositórios, responder perguntas sobre a codebase, atualizar pull requests e fazer push de branches. O Cursor diz que mais recursos nativos para agentes estão por vir; nosso guia do modo de agente do Cursor aborda o que os agentes já podem fazer no editor.

Como executo testes de API em pull requests do Origin? Da mesma forma que você faz no GitHub: execute o Apidog CLI como uma etapa de CI. No Origin, isso significa conectar Depot ou Buildkite ao repositório e reutilizar seu workflow existente do Actions, com seus comandos apidog run inalterados.