A OpenAI encerrou o contrato que dava à Cursor acesso a seus modelos. A decisão veio logo após a ferramenta de programação assistida por IA ser adquirida pela SpaceX. A OpenAI não explicou publicamente os motivos — não se sabe se a questão é concorrência, estratégia comercial ou algo relacionado à própria SpaceX como compradora.
Cursor é uma das ferramentas mais usadas por desenvolvedores para codificação com IA, construída em cima de modelos de fundação de terceiros, incluindo os da OpenAI. Esse modelo de negócio — empresas de produto rodando sobre APIs de grandes provedores — é a espinha dorsal de boa parte do ecossistema de aplicações de IA hoje. Cursor, Perplexity, e uma lista longa de startups seguem essa lógica: não treinar modelo próprio, focar em experiência de produto, e alugar inteligência de quem tem capital para treinar em escala.
O problema é que essa arquitetura tem um ponto único de falha óbvio. Se o fornecedor decide, por qualquer razão, cortar o acesso, o produto que depende dele fica comprometido de uma hora para outra. Não é a primeira vez que se discute esse risco em teoria — mas normalmente fica como um argumento acadêmico sobre "moat" e dependência de infraestrutura. Aqui é um caso concreto: um contrato foi encerrado, e a razão não foi divulgada.
Vale notar que o gatilho parece ter sido a aquisição pela SpaceX, não um problema técnico ou de performance do modelo. Isso sugere que a decisão tem mais a ver com quem é o novo dono da Cursor do que com a ferramenta em si. SpaceX e OpenAI não competem diretamente em nenhum mercado óbvio, o que torna a lógica comercial por trás do corte ainda mais opaca — e reforça que empresas de IA de fundação podem tomar decisões sobre quem tem acesso a seus modelos por critérios que vão além de performance técnica ou volume de uso.
Para a Cursor, o caminho agora provavelmente passa por diversificar fornecedores — usar modelos de outras empresas como Anthropic ou Google, ou modelos abertos — algo que muitas ferramentas de codificação já fazem em algum grau como camada de resiliência. Mas a transição não é trivial: modelos diferentes têm comportamentos diferentes, e trocar o motor por baixo de um produto usado por muitos desenvolvedores tem custo de engenharia e risco de qualidade.
Fica em aberto até que ponto esse tipo de decisão vai se tornar mais comum à medida que os grandes provedores de modelos também competem em produtos finais — e se startups que hoje dependem de uma única API deveriam considerar isso um risco existencial, não apenas um detalhe de infraestrutura.