Cursor cria hospedagem de código própria, e o GitHub cai por 6 horas no mesmo dia

Na manhã de segunda-feira, 17 de agosto, a Cursor começou a liberar para todos os usuários pagantes uma novidade chamada Origin: um serviço de hospedagem de código, ainda em beta inicial, com a versão empresarial podendo optar por não participar. Cerca de três horas e meia depois, o GitHub sofreu uma degradação de serviço global, que durou 6 horas e 42 minutos, com a taxa de erro em algumas funções chegando perto de 20%.

Os dois eventos não têm relação de causa e efeito, mas terem acontecido na mesma manhã tem mais força de convencimento do que qualquer evento de lançamento.

O que o Origin realmente oferece

Na interface surge uma nova aba chamada Codebase, onde é possível criar e gerenciar repositórios; projetos locais podem ser clonados ou enviados via CLI, e o endereço do repositório segue o formato cursor.com/codebase/<name>. Todo o conjunto de recursos de Pull Request foi transportado integralmente: linha do tempo, histórico de commits, status de checks, alterações de arquivos, revisão de diffs, comentários, merge — até PRs atribuídos a você no GitHub podem ser revisados diretamente na Cursor.

A relação com o GitHub é de sincronização bidirecional. Depois de conectar a uma organização do GitHub, os repositórios já existentes são sincronizados com o Origin; comentários escritos na Cursor são enviados ao GitHub, e vice-versa. Segundo a empresa, o GitHub continua sendo a fonte de verdade (source of truth), os pushes continuam indo diretamente para o GitHub, e os usuários podem desconectar a qualquer momento.

Entre os parceiros terceiros já integrados estão Vercel, Depot e Buildkite, cobrindo implantações de preview e pipelines de CI.

A parte de revisão não foi escrita do zero. Em dezembro de 2025, a Cursor adquiriu a Graphite, uma startup especializada em revisão de código; a equipe e a tecnologia da Graphite hoje sustentam o fluxo de revisão do Origin. Na época, a aquisição parecia apenas um recurso a mais para o editor; em retrospecto, parece mais uma preparação de insumos para a camada de hospedagem.

Por que fazer isso agora

Nos últimos anos, a posição da Cursor era a de "uma camada sentada sobre o GitHub". Quando um agente termina de alterar código, ele precisa abrir um PR, o PR passa pelo GitHub, os comentários de revisão são lidos no GitHub, e a ferramenta sincroniza os resultados de volta para o editor. Cada ida e volta entre sistemas nessa cadeia consome parte do contexto disponível do agente e aumenta a latência.

Trazer a camada de hospedagem para dentro de casa economiza menos requisições de rede do que se poderia pensar — o que realmente está em jogo é o poder de definir o produto. Quando a força principal que escreve código deixa de ser humana e passa a ser de agentes, a própria forma do repositório deveria mudar junto: quem consegue ver quais arquivos e em que momento, como uma alteração é dividida, para quem uma revisão é mostrada — hoje todas essas regras são definidas segundo os hábitos de colaboração humana. A frase oficial do Origin, "projetado para a escala dos agentes", se refere exatamente a essa camada.

Do lado do GitHub, a janela de oportunidade realmente está aberta. Em 2018, a Microsoft comprou o GitHub por US$ 7,5 bilhões em ações; oito anos depois, seu papel na era da programação com IA é bastante incômodo: precisa hospedar o código de todo mundo, ao mesmo tempo em que vende seu próprio Copilot e abre APIs para uma série de agentes concorrentes. A degradação de mais de seis horas em agosto colocou em xeque a premissa implícita de que "hospedagem é sinônimo de infraestrutura".

As chances desse jogo

De forma realista, no curto prazo ninguém vai tirar seus repositórios do GitHub só por causa do Origin. Issues, stars, forks, configurações de CI e os hábitos de contribuidores externos de projetos de código aberto estão todos enraizados no GitHub; o custo de migração está do lado social, e tecnicamente essa é, na verdade, a parte mais fácil de resolver. A própria Cursor sabe disso, por isso a primeira versão aposta em sincronização, não em substituição.

Onde há chance real de sucesso é nos repositórios internos das empresas. Código privado não precisa de comunidade nem de PRs externos; a empresa só se importa se o agente roda rápido, se o fluxo de revisão é tranquilo e se dá para cortar uma assinatura. Os usuários pagantes da Cursor já estão concentrados nessa camada, e o Origin se encaixa diretamente no fluxo de trabalho que eles já usam, com um limiar de adoção praticamente zero.

Uma conta rápida também ilustra o ponto. Numa empresa de duzentas pessoas, o GitHub Enterprise cobrado por usuário custa uma cifra de cinco dígitos em dólares por ano; a assinatura da Cursor é outra despesa, e a sobreposição de funcionalidades entre os dois está se ampliando rapidamente — revisão, gatilhos de CI, navegação de código, o Origin já faz tudo isso. Na época de renovação, as empresas só precisam se fazer uma pergunta: é necessário pagar pelos dois? A resposta depende de a estabilidade do Origin se sustentar, não de quem tem a lista de recursos mais longa.

Por trás disso também há um fator de capital. A Cursor já está sob o guarda-chuva da SpaceX, e o fluxo de caixa da controladora é suficiente para sustentar por anos um serviço de hospedagem que não dá lucro no curto prazo — um jogo completamente diferente do de uma startup que ainda precisa se preocupar com a reação dos investidores ao fazer a mesma coisa.

O indicador que realmente vale observar não está nas notas de lançamento: daqui a seis meses, quantas empresas terão definido o Origin como repositório principal, e não apenas como cópia sincronizada. Sincronização é um estado de transição; repositório principal é que é a conclusão.

Fontes: changelog oficial da Cursor, SiliconANGLE, CocoLoop, Slashdot; verificados o alcance da liberação do beta, a duração da degradação do GitHub de 6 horas e 42 minutos e o critério da taxa de erro, e a linha do tempo da aquisição da Graphite.