Your own model deepens the moat and the governance that comes with it
Building Composer moved Cursor from the app layer to the model layer. Here's what that shift means for AI governance.
Cursor might be paving a way for the so-called wrapper companies to actually survive and thrive.
Earlier this year in March the maker of its popular AI-powered IDE announced its agentic coding model called Composer 2, designed for long-horizon coding tasks. And in May it announced Composer 2.5, which according to Cursor is better, more reliable and more pleasant than its predecessor.
Prior to the development of its Composer series of models, Cursor relied on coding models developed by third parties, including those from frontier labs like OpenAI and Anthropic. The release of the original Composer in October 2025 model marked the first time that the company offered its own proprietary model inside its app.
The motivation for developing Composer was to make a more efficient model built specifically for coding tasks inside the Cursor app. While models from frontier apps work well for coding purposes, they are general-purpose models built to do many different things. This means that the model weight’s are trained to work across a broad range of tasks rather than being optimised for coding specifically.
Cursor therefore wanted to build its own model where all the weights would be optimised for coding for its specific app and also much cheaper to run.
Wrapper companies building proprietary models was thought to be rather infeasible given the fierce competition from frontier labs and the enormous resources needed to build such things; the compute, the data, the talent and the money to fund it all.
But Cursor is demonstrating that this may not always be true. The company has been building its AI-powered IDE for a number of years, over which time it has accumulated money, talent and, crucially, data - code, conversation threads and other user activity that Cursor can rely on to build its own model.
This is described in its privacy policy. Obviously if you use Cursor then the app will be processing what the policy defines as “Inputs and Suggestions”, which means the prompts and code submitted to Cursor and the AI-generated responses to these inputs. Cursor only uses this data to train its models if users explicitly agree to Cursor using this data for such a purpose (and this is also reiterated in its terms of service). Cursor’s Data Use & Privacy Overview page describes how this is determined by the Privacy Mode settings in the Cursor app - if this is switched off, then Cursor “may use and store codebase data, prompts, editor actions, code snippets, and other code data and actions to improve [its] AI features and train our models.”
It is this kind of data that Cursor can leverage to build a model like Composer. To build a specialised model built for long-horizon coding tasks inside Cursor, it would be ideal to use authentic data representing how they actually use the app. User data reveals the behaviours executed and the workflows being deployed inside an app, which can form important signals for a model designed to support such activity and better align it with user intent. The technical paper for Composer 2 mentions the use of a “large code-dominated data mix” for pretraining and carrying out reinforcement learning with large datasets of coding tasks run in “environments that emulate real Cursor sessions as closely as possible.”
Federico Cassano, a researcher at Cursor, also somewhat admitted this in a podcast interview with Sequoia in which he agreed with the notion that Cursor “sits in the middle of so many interesting coding tokens [it] actually pretty uniquely have access to data to be to train at almost pretraining scale”:
What Cursor is doing here could be seen as natural evolution for AI companies for three main reasons:
Being reliant of frontier developers for the intelligence engines behind their apps makes their stack more vulnerable. Just look at the Fable fiasco with the US government last month.
Trying to engineer existing models, whether through clever system prompts or elaborate UIs, only gets you so far. Such engineering does not fundamentally change the weights of these models and therefore does not enable them to reliably bake into the model the nuances of how its app works and how users utilise it.
Model providers themselves have been making their own moves into the application layer. Anthropic’s Claude Code, OpenAI’s Codex and Gemini’s Antigravity are agentic coding products that compete directly with Cursor.
Consequently, it could be argued that AI companies should be looking to build their own models as a way to distance and protect themselves from frontier labs and establish deeper moats that make them more sustainable businesses in the long-run.
That being said, the influence of larger companies in the industry is never far away. Cursor explains in its blog post for Composer 2.5 that its partnership with SpaceX announced in April 2026 will provide access to 10x more compute to train its model in the form of millions of GPUs from Colossus, xAI’s data center located in Memphis, Tennessee.
The obvious consequence of building proprietary foundation models is that these AI companies move themselves to a different part of the supply chain. Instead of sitting firmly in the application layer of the AI ecosystem, building models also spreads them in the model layer.
And this move has consequences from a legal perspective that might easily be overlooked.
One relates to privacy and the rules around if and how AI companies can repurpose user data for model development. I have written about some of the issues here previously in relation to the GDPR:
But other implications come from the EU AI Act. This legislation includes specific provisions relating to general-purpose AI models and systems, with a complex set of rules applying to the builders and users of such models.
These provisions came into force in August 2025, and the Act will be enforceable in August 2026. It will therefore be interesting to know if companies have the Act on their radar when making these moves into the model layer, especially for those that operate on a global scale.
Addressing these legal implications early strengthens the moat for companies like Cursor. If they can show users and enterprises that their models are not only purpose-built and highly capable, but also compliant with EU law, the product becomes far more trustworthy and far more attractive and also ticks off an item that investors may have on their list.
In this newsletter I cover:
How Composer 2 was developed
The GPAI provisions in the AI Act
How the GPAI provisions apply to Cursor’s development of Composer
Whether the recent Omnibus changes anything
What other AI companies looking to build their own models and serve EU users should be thinking about