Cursor’s Valuation Surge

The highest valuation in the global AI programming sector has just been refreshed. The rising star in the AI programming world, Cursor (backed by Anysphere), has seen its valuation soar to $29.3 billion, approximately ¥207.9 billion.

On November 13, Anysphere announced the completion of a $2.3 billion Series D funding round (around ¥16.3 billion). Following this round, the company’s valuation jumped from $9.9 billion at the end of the previous funding round in June to $29.3 billion, nearly tripling in value.

Cursor’s official blog reveals that this funding round attracted prestigious investors, including NVIDIA, Google, and top-tier fund Coatue, with existing investors Accel, Thrive, a16z, and DST also increasing their stakes. The lead investors for this round were Accel and Coatue.

However, according to CNBC, Anysphere’s CEO Michael Truell stated that the startup currently has no plans for an IPO:

“Our focus right now is on growing the company and the team. We have a lot of work to do before considering an IPO.”

Cursor’s Explosive Growth in Two and a Half Years

In 2023, a native AI IDE named Cursor quietly launched. Since then, it has rapidly gained popularity in the global developer community with minimal marketing budget, becoming one of the fastest-growing SaaS products.

Cursor’s rise coincides with the emerging trend of “Vibe Coding” in software engineering: developers interact with AI using natural language, which automatically generates, modifies, and refactors code. The core of this paradigm is not merely model power but the Cursor × dual-engine architecture. This architecture is specifically trained for coding and serves as Cursor’s “brain”. The Cursor team has rewritten the underlying architecture of the IDE to excel in context memory, multi-language support, and inference speed, allowing it to truly understand and manipulate real codebases rather than generating isolated text.

Leveraging this architecture, Cursor achieved remarkable commercial growth within two years: its annual recurring revenue (ARR) surpassed $500 million, daily active users exceeded 1 million, and paid users reached 360,000, covering 50,000 enterprises and penetrating over half of the Fortune 500.

This explosive growth is also driven by the concentrated release of industry pain points: a shortage of engineers, high costs, and the heavy maintenance burden of legacy systems, with repetitive debugging taking up significant time. Cursor’s product naturally addresses these issues, and the free version encourages trials, while community ecosystems promote diffusion, accelerating the product flywheel.

Capital has shown no hesitation in this growth trajectory.

Starting from a $60 million funding round in July 2024, followed by $105 million in the December funding round, $900 million in May 2025, and the recent $2.3 billion Series D round in November 2025, Anysphere’s valuation skyrocketed from $2.6 billion to $29.3 billion in less than a year.

Such speed is unprecedented in the global AI programming sector, with investors including Accel, Thrive, a16z, DST, NVIDIA, Google, and Coatue.

There were also rumors that OpenAI led the seed round for Anysphere and attempted to acquire it twice, with the highest offer reportedly reaching the $10 billion mark, but the acquisition did not proceed due to Anysphere’s refusal to sign an exclusivity agreement.

However, behind this rapid growth lies some concerns. There have been discussions about Cursor’s deep reliance on foundational models (OpenAI, Anthropic) and the VS Code ecosystem, theoretically posing structural risks with “one API change”.

At the same time, the acceleration of open-source large models is causing foundational capabilities to converge, continuously compressing technical barriers.

In response to these challenges, Anysphere is attempting to embed Cursor deeper into the enterprise development chain—from testing and DevOps to observability and data feedback; aiming to build a next-generation moat through more difficult-to-replace “full-link integration”.

a16z’s Latest Podcast Reveals Exclusive Stories Behind Cursor

Cursor is currently at the center of industry attention, but its starting point was not so glamorous.

Recently, a16z featured a conversation with Anysphere founder Michael Truell on a podcast. The founder, who propelled the company to a $200 billion valuation in just two and a half years, shared the real growth trajectory of Cursor for the first time—how it pivoted decisively from a nearly unviable “3D robot CAD” direction at a critical turning point to ultimately secure a core position in the global AI programming sector.

In this interview, Michael discussed Cursor’s product positioning, key design trade-offs, why they decided to enter through VS Code, how the team developed a usable first version of the IDE in just two weeks despite extreme resource scarcity, and how they handled infrastructure bottlenecks, multi-cloud vendor architectures, and model supply chain risks during rapid scaling.

Meanwhile, as one of the most watched AI programming companies today, Cursor’s foresight about the industry’s future is also notable: software engineering is shifting from “writing code” to “judging whether the code is correct”, redefining the role of engineers as technical decision-makers rather than mere keyboard executors.

Michael reflected on the process of Cursor’s pivot from a wrong direction to a growth path. A few years ago, the team was attempting a project that later proved difficult to establish—automating 3D robot CAD design using large models. This idea sounded advanced in the early stages, but they encountered structural issues such as data scarcity, model inference incompatibility with three-dimensional scenarios, and difficulties in bridging industry knowledge, leading to long-term stagnation.

According to Truell, this experience made the team realize that they lacked sufficient mechanical engineering background and could not bridge the professional gap solely with large models. The CAD project hit a bottleneck, and team pressure continued to accumulate. The direction adjustment was both accidental and inevitable. All four founders were deep engineers, familiar with command lines, and were among the early adopters of GitHub Copilot. They observed that AI could intervene in software engineering with high quality for the first time, but the supply of tools at the layer level was still very limited. After discussions, the team abandoned CAD and refocused on a field they were more familiar with.

Since then, the company’s development path began to change. Cursor chose to enter through VS Code rather than building a new IDE from scratch. The team believed that the core issue was not to “reinvent the editor” but to “make the model work in real development processes”. Based on this judgment, Cursor’s first version was completed in a matter of weeks and quickly spread in the developer community after its release.

With no marketing budget, early growth primarily stemmed from spontaneous community sharing. Cursor rapidly spread in the developer community, becoming a frequently discussed AI programming tool, leading the company into a high-speed growth cycle.

Rapid growth also brought more complex challenges.

At its peak, Cursor’s API call volume accounted for a double-digit percentage of a cloud service provider’s revenue; the team had to complete the decentralization of model suppliers, build their own inference and training systems, and rewrite parts of the infrastructure in a short time.

These adjustments were more about addressing stability pressures brought by growth rather than merely pursuing “technological leadership”. The team realized that only by mastering more foundational capabilities could they establish differentiation in the engineering tools market in the future.

Cursor’s organizational structure is also atypical. Its recruitment process involves candidates writing code in the office for two days instead of traditional whiteboard interviews. This approach allows candidates to directly engage with the real work environment and helps the team assess compatibility.

Acquisition strategies also revolve around “talent density”. For example, they once acquired a five-person team primarily because one member was responsible for core development of GitHub Copilot’s predecessor features, rather than to fill a specific product module.

For Cursor, such organizational structure is a foundational strategy to cope with the uncertainties of rapid growth.

While the industry often describes the future as “automated programming”, Truell’s judgment is more cautious. He believes that complete automation is still a distance away. The industry is in the early stages of tool upgrades, and differences in model capabilities, engineering practices, and enterprise environments make “unmanned engineering” difficult to implement comprehensively in the short term.

He likens the current phase to the period between the “iPod and iPhone”—a new form is emerging, but the technological route and usage methods are still evolving.

Cursor’s goal is to maintain speed during this transition period and explore the possibilities of next-generation development tools.

From Cursor’s development trajectory, the competition in AI programming tools has shifted from auto-completion and single-file generation to deeper integration across the engineering chain, including testing, deployment, observability, and data feedback.

Cursor’s rise is not a typical story of “a successful product iteration” but rather a timely withdrawal from a wrong direction to seek a clearly defined demand where the team has advantages. Its growth stems from the alignment of product and scenario, team density, and foundational infrastructure capabilities, while industry backgrounds such as tight engineer supply and rising complexity of enterprise systems constitute long-term driving forces on the demand side.

With its valuation reaching $29.3 billion, Cursor has become one of the most watched companies in this sector. However, it still faces challenges related to foundational model competition, upstream and downstream dependencies, and the degree of integration in the enterprise market.

The Origin of Cursor

a16z: I recently met a startup that said, “We are the Cursor of the 3D field.” I found it interesting because Cursor initially also worked on 3D. Can you tell us the origin story of the company?

Michael: The starting point of the company can be counted from different stages, but the core is that we, the co-founders, were originally colleagues from school or elsewhere. Two key moments prompted us to truly consider entrepreneurship.

The first was our first experience with a truly “useful” AI product, especially GitHub Copilot—the leading player in the field at that time. This made us realize that AI should not remain in the lab; it can already generate real value in the real world.

The second was the inspiration from scaling laws—despite the temporary lack of new ideas in the field, as long as the model scale continues to expand, the effects will continue to improve.

This was between 2021 and early 2022.

After that, Cursor’s prototype emerged from a whiteboard discussion. We were very excited about the concept of “Cursor for X”—we believed that many knowledge work fields would see a company responsible for automating that domain.

Such companies would build the best products in that field, gain the strongest distribution channels, establish considerable commercial scale, accumulate data and capital, and ultimately evolve into a “laboratory” that promotes the progress of foundational models, thereby enhancing the product itself and forming a virtuous flywheel.

At that time, we believed that Microsoft would do this in the vertical field of “programming”, so we wanted to choose a direction that was less competitive and more niche.

Since some team members had studied mechanical engineering and were familiar with CAD systems, we initially decided to try automation in mechanical engineering / CAD.

But it turned out that this direction was not suitable. Our match with this field was very low. When communicating with mechanical engineers, we often could not truly understand the core of their daily work, like “blind men touching an elephant”.

Looking back, I even think that those six or seven months should have been spent interning at mechanical engineering companies to experience their work firsthand.

Ultimately, we abandoned the CAD direction and returned to the field we were most interested in and best at—programming.

Why Did Cursor Succeed Early?

a16z: I have a theory: the key to Cursor’s early success was “focus”. You chose VS Code instead of rewriting an editor from scratch, and you didn’t immediately dive into foundational model competition. Many companies were pursuing more “sci-fi” directions at the time. Do you agree?

Michael: I agree with most of your observations, but I must say that Cursor’s story is far from finished.

Returning to our initial CAD experience: the cold start difficulty in that field was enormous, with no existing models, scarce 3D data, and LLMs offering little help. We spent a lot of time modeling and cleaning data, even leaving behind PTSD. So when we returned to the familiar scene of programming, we became exceptionally focused, wanting to create a product that could genuinely be used as quickly as possible.

At that time, we had limited funding, and the team consisted of only four founders, yet we faced Microsoft and dozens of startups—ranging from foundational models to workflow reconstruction, various directions were being pursued. In such a competitive environment, we could only compress time and focus all available energy on the product.

We set a constraint for ourselves: to write an update email to investors every month (even if no one read it, it served as a good deadline). From deciding to create Cursor to developing a usable IDE for ourselves took only a few weeks—not even a fork of VS Code, but built from scratch. A few weeks later, we handed it over to external users for testing, and within a few months, we released the first beta, quickly gaining attention and officially starting the initial growth flywheel.

Why Did You Choose Not to Expand to CLI, IntelliJ, and Other Directions?

a16z: As momentum grew, users began requesting support for CLI, IntelliJ, and other tools, but you did not pursue this. Was this intentional?

Michael: Yes, it was very intentional. The four of us founders discussed daily over meals: should we expand? Should we develop models? Should we create new IDEs?

I believe we were very deliberately trying to “own the surface layer”. Doing this is not uncommon now, but at that time, many people thought it was strange to create an editor (whether forking or rewriting). Many would say, “You can’t get programmers to switch editors; they are too attached to their own.”

But we knew that wasn’t true. Because we ourselves switched ecosystems to VS Code because of Copilot. We were originally the kind of “old-timers using command-line Vim”, so we understood very well: if you create a better “mouse trap”, people will migrate, but the threshold is high.

At the same time, we were also very clear that at some point in the future, we would need to enter the model layer. There is a whole story behind this gradual approach, which has now become a very important product lever for us. But we did not want to start from there—the goal at the start was simply to get something done and not touch the model stuff yet.

a16z: I remember you once called me to say, “We fell from a big cloud because the other side couldn’t handle our traffic.” At that time, Cursor was growing astonishingly. I’ve been in this industry for 30 years and have seen many companies, but I’ve never seen anyone scale to your level in such a short time, especially with such a small team.

Michael: I think our approach to “scale” early on was that a very small team was operating a rapidly growing online service. My co-founders are all excellent, but to be honest, from the perspective of “work experience”, we weren’t particularly experienced. So it quickly became that a large number of users began using our service, while we were still learning and putting out fires on the side.

Some things can easily push the system to its limits. For example, we had our own file synchronization system, which you can think of as having two or three “mini Dropbox” within Cursor. The internal system also had a whole set of search capabilities to support AI, which seemed simple on the surface but was technically quite complex. Depending on the architecture, it could easily put pressure on the underlying cloud resources.

Soon, we reached a significant scale in areas that seemed like just ordinary cloud services. That period was filled with a lot of “blood and tears”: we were running a very large Kubernetes cluster, larger than many companies, yet only five people were figuring it out as we went along, naturally leading to various small problems and incidents.

Once we stabilized the architecture and began to expand the team, new problems arose, such as filling the API suppliers’ capacity to the brim. These suppliers initially had no idea how to understand us—four twenty-somethings ended up accounting for a significant percentage of their API revenue, and they had to plan their capacity and financials based on our growth.

During that time, we had to spend a lot of energy managing relationships and ensuring suppliers were willing to give us enough resource quotas. Later, we discovered that the same model API token could be purchased from different suppliers, and there were even dealers specifically selling tokens. So we became a team searching everywhere for sonnet tokens. Eventually, we began training some models ourselves and running some inferences, which brought new scalability challenges.

Will You Eventually Build Your Own Infrastructure or Rely on Multiple Cloud Providers?

a16z: Where do you think this will head in the future? Will you continue to rely on multiple external third parties, forming a heterogeneous external dependency system? Or will most infrastructure gradually be brought in-house and built primarily?

Michael: Are you referring to inference infrastructure?

a16z: No, I mean all infrastructure—websites, desktop applications, backend systems, etc.

Michael: I believe we have been very “multi-cloud” from the beginning, and this path has basically been set. In the long run, we will continue to rely on multiple cloud vendors rather than just one. We are currently using Databricks, Snowflake, AWS, GCP, Azure, and PlanetScale for databases.

Some of the scaling issues we encountered were very real, especially regarding database scalability. We have many operations that heavily rely on database performance. Initially, we used RDS, and generally, just making the instance larger would suffice for a long time, but eventually, you would encounter the “instance maximum limit” issue, at which point you have to ask yourself: should we shard the database?

Later, we switched to another database service on AWS, and they told us we didn’t need to shard, but that was actually incorrect; you would still need to shard. You originally thought these cloud vendors had solved all problems, but in reality, very few customers reach that scale, and they are also learning as they go. In this regard, PlanetScale has been crucial for us; we transitioned from AWS’s non-sharded system to PlanetScale, and the results were excellent.

So in the long run, we will definitely continue using multiple cloud services. Each vendor has its own advantages, which is why we chose a multi-cloud strategy.

How Do You Prioritize R&D? Balancing Multiple Products

a16z: Let’s continue discussing products. You were initially very focused, but later began launching more, such as BugBot, CLI, and various infrastructure improvements. How do you decide whether to pursue these? Are these directions emerging naturally, or do you have a very strict prioritization mechanism?

Michael: It’s actually quite deliberate. We say “no” to many things. But I do believe that in the future, we must become a multi-product company.

In this field, there is a significant multi-product opportunity: creating a comprehensive “packaged solution” of AI programming tools. We hope that for many clients, Cursor will be the layer of their “AI coding service provider”.

So far, our core “wedge” remains that piece—the “glass pane” where engineers write code daily: the editor. We believe there are still many things to do in the editor, which is also where we invest the most resources.

At the same time, we also believe that changes in the way work is done in the editor will inevitably alter team collaboration methods. This is both a huge strategic opportunity and a necessary condition to excel in the “editor”—you must have a set of supporting tools to help teams with code reviews, collaboration, and communication.

So all of this is intentional. To be honest, we are still learning how to do the multi-product thing better: like how to provide enough “air cover” for these projects, and how to truly enable the sales team for cross-selling.

a16z: Yes, transitioning from a single product to a multi-product go-to-market strategy is indeed very challenging.

Michael: We are continually learning, but we are already very excited about the early results.

How Do You Recruit? A Strict Two-Day Trial

a16z: I have seen many companies, and Cursor’s recruitment process is undoubtedly one of the most rigorous and thoughtful I have encountered. Every time I help you with recruitment, you always send me the candidate’s background, current progress, and your strategy in advance, which shows how much effort you put into recruitment. Can you talk about how you do recruitment? What practices are effective, and which are ineffective?

Michael: The first piece of advice is: have your board members make as many calls as possible until they shout stop (laughs), fully utilize their time.

Specifically, our process has some mainstream practices, but also some quite different aspects. Generally, small companies use a method when hiring their first engineers: they let the candidate work with the team for a while in a contract-like capacity, rather than going through standardized LeetCode algorithm questions or standard interview rounds—we did this because it felt the most natural and closest to what we wanted to know: “Are we comfortable working with this person?”

In general, many companies stop this model after hiring the first few people, but we wanted to stop and have tried many times to stop internally, but we haven’t stopped yet. To this day, all members joining the engineering and design teams spend two days in the office working on a real project.

These two days are very flexible; it’s not a rigid schedule of “9 am whiteboard interview, 10 am system design, packed for two days”. We give candidates a desk, a computer, and tell them: “Here are three projects you can work on, here’s a ‘frozen version’ of the Cursor codebase and a pre-configured development environment; you can start.”

These two days of “trial work” serve two main purposes: first, they test many “orthogonal dimensions” that traditional coding interviews cannot cover. Prior to this, we would conduct a round of relatively traditional coding interviews and then bring candidates in for this. During these two days, we can see:

• Can they complete a task from start to finish in a real codebase?
• Are they “proactive and self-motivated”?
• In our environment, where engineering, design, and product are very closely intertwined, we like to hire engineers with a sense of product—two days of trial work can also reveal what they might create if placed in a relatively “vacuum” environment.

I think these two days provide us with a wealth of hardcore technical signals about “surviving and thriving in our environment”.

The second purpose is cultural fit:

• These two days allow us to sense: “Are we willing to work with you?”
• At the same time, it lets the candidate judge: “Am I willing to work with you?”

Additionally, a third derived benefit is that candidates gain a lot of real information about the company during these two days: what the daily rhythm is like, what code is written, who they partner with, what the first day of onboarding feels like, etc. This is why, as long as a candidate ultimately says “yes”, our matching rate is usually very high.

This is a very “atypical” practice we still adhere to: two days of onsite trial work, even now that the company has grown beyond 200 people.

a16z: You wouldn’t do two days of trial work for go-to-market positions, would you?

Michael: Initially, we did! When hiring our first few salespeople, we did just that: we gave them real inbound leads, assigned them a quota, had them do actual product demos, simulate communication with real customers, and even let them review real data and propose strategies. At first, it even reached the point where: “Here’s all the information, please tell us how we should do sales.” Afterward, the process became more formalized, but initially, that’s how it operated.

Why Does Cursor Engage in So Many M&A Activities?

a16z: You are one of the fastest and boldest early companies I have seen in terms of acquisitions. The traditional view always suggests that “startups should not acquire other startups”, but your acquisitions have clearly been very successful. Can you share your thoughts on this?

Michael: So far, for us, this has basically continued our consistent approach: to find the best people, we are willing to use all possible means.

When we were expanding the team from the initial ten people, we had already made many “crazy recruitment moves”. For example:

• Even if the other party has already rejected you, you still fly to the country where the TA is located to meet them;
• If they reject you again, you create a story: say there will be a researcher dinner in San Francisco in six months, strongly suggesting the TA fly over to attend;
• When six months later they actually come, you reignite the conversation and ultimately convert them into a company engineer, resulting in them becoming one of the best people on the team—this is something we have done for real.

Thus, we have always cared deeply about “bringing in the strongest talent”. Sometimes, these people are “conveniently” not in any company; but more often, they are already entrepreneurs or responsible for critical tasks in other companies. This is why many of our acquisitions start from a “talent-first” perspective.

However, starting from talent gradually extends to strategy. In the future, we will more systematically view acquisitions as a means to form product teams within the company resembling a “general manager system”, building a complete suite of AI coding tools and bringing in complementary founding teams. For many new products, our typical thought process is: either we build it ourselves, or we see if there are suitable small teams in the market to join us.

Our first formal acquisition case was Supermaven. That was a five-person team, and the founder Jacob had previously worked on TabNine (the top auto-completion product before Copilot appeared) and later did research at OpenAI (alongside John). He was also building his own completion model, and their technical route was completely complementary to Cursor. We maintained contact with him for many months and ultimately pushed for this acquisition very proactively and aggressively.

Final Philosophical Question: Will Cursor Be Automated by Its Own AI?

a16z: I want to ask you one last question. This is something I heard from one of your candidates, and I find it quite philosophical. He said, “Cursor is disrupting the entire software industry, but Cursor itself is also written in software; will Cursor eventually be threatened by its own revolution?” I answered him, “I would rather be the disruptor than the disrupted.” But honestly, that sounds too much like a VC’s answer. What do you think?

Michael: I believe that software development is still very far from complete automation. Despite ongoing discussions in the external world, despite huge demand, rapid industry pace, and daily changes, the true upper limit of software automation has not yet been reached. In large organizations—engineering teams of dozens, hundreds, or even thousands—development processes remain extremely inefficient. Many executives easily overestimate the extent to which “software development has already been automated”, but that is not the case.

The entire software development field will experience many “iPhone moments” of technological leaps. The stage we are currently in is more like experiencing the “iPod moment”, about to welcome the “iPhone moment”, and after that, there will continue to be more “iPhone moments”. Software development is undergoing continuous and significant leaps, and Cursor must become a company capable of continuously building the next generation of products. As long as we stop innovating, we will be eliminated.

This is also why giants like Microsoft find it more challenging to completely dominate this market. The pace of change is too fast, the technological leaps are too drastic, and the underlying structures are too flexible, making it harder for large companies to keep up with this rhythm. This is certainly a challenge, but it is also the greatest opportunity.