Cursor 3.14.2 Sunsetting @Docs!?!

Ideas Feedback
,
1

I just received this email from [email protected] so I am pretty sure that is @leerob.

Hi Spencer,

Lee from the Cursor team. You recently used @Docs in Cursor, so I wanted to send you an email directly.

We’re sunsetting this feature in version 3.14.2. With the latest models and improved web search, @Docs has become obsolete.

If you need to reference external docs, you can add a link inside your prompt or provide more guidance as a rule or skill.

Thank you for your continued support and usage of Cursor.

Sunsetting @Docs is an indefensible product decision.

@Docs is not obsolete because models and web search have improved. It solves a different problem. It allows developers to curate a known documentation corpus, index it once, and repeatedly retrieve the relevant sections. Pasting a link into a prompt or telling the agent to search the web is not an equivalent workflow. It adds latency, variable search results, version drift, repeated fetching, unnecessary context churn, and additional token consumption.

Rules and skills are not replacements either. They encode instructions and workflow conventions. They do not replace an indexed collection of authoritative API references and technical documentation.

This is the same product pattern described in my previous post about removing the CSS Inspector. Cursor keeps deleting direct, efficient tools used by professional developers and replacing them with agent-mediated workflows that require more prompting, more model calls, and most important to Cursor more tokens.

The CSS Inspector allowed developers to inspect and adjust properties directly. Its replacement makes the agent perform every change. @Docs allows developers to maintain reusable, indexed documentation. Its proposed replacement makes the agent fetch or search for the same information repeatedly.

The result will be a product that is slower, less deterministic, less controllable, and more expensive to use.

Since the SpaceX acquisition was announced, Cursor’s product direction increasingly looks less like an attempt to build the best professional IDE and more like an attempt to maximize metered agent activity. Removing an indexed retrieval workflow in favor of repeated searches is especially difficult to interpret any other way.

If Cursor has evidence that repeated web retrieval is faster, more accurate, more version-stable, and less token-intensive than a curated documentation index, publish the benchmarks. Otherwise, calling @Docs “obsolete” is cultish marketing language not an actual technical explanation.

And please do not respond with another claim that newer models make the feature unnecessary. Better models do not eliminate the need for controlled context. Web search does not replace a curated source set. Pasting a URL into every prompt does not replace persistent indexing. A rule or skill does not replace documentation retrieval.

Pretending these things are equivalent is gaslighting users who understand how the product works. It is marketing cult propaganda that treats every regression as progress.

Cursor used to justify its premium by providing workflows that competing tools did not. Now every update seems to remove another one.

OpenCode is becoming increasingly more capable, more transparent, and dramatically cheaper while Cursor actively dismantles the features that made its price defensible.

Reverse this deprecation. At minimum, provide a technically credible migration path that preserves persistent indexing, controlled sources, version pinning, private documentation access, predictable retrieval, and comparable token efficiency.

Anything less is another core feature being removed and relabeled as progress.

7

Hi @spencerthayer Thank you for the post. First, confirming the email from Lee is real.

On the decision itself: @Docs has been removed. We didn’t make the decision lightly, but it was carefully considered as part of the evolution of the product, and the decision was made in accordance with our core operating principles.

I can tell you a little bit more about our reasoning behind the change. The agent’s ability to locate and read documentation on its own has improved to the point where maintaining a separate documentation index was no longer necessary, so we chose to put that effort elsewhere. It’s a judgment call, and we understand that not everyone may agree with the decision. It was not made to increase what you spend.

Keeping a local copy of the docs you need in your workspace is a good option that meets your use case. Including links to docs is a fine option as well, and the Cursor agent is quite good at discovering the right docs by itself.

8

Thanks @kevinn for confirming that the email is authentic and that @Docs has been removed but your reply still does not address the requested migration path.

Keeping a local copy of documentation inside every workspace is not an equivalent replacement for a managed documentation index. It duplicates content across projects, requires manual maintenance, complicates version updates, and does not help with documentation that cannot reasonably be copied into a repository (like Shopify’s dev documentation).

Providing links is also not equivalent. A link still requires the agent to fetch, parse, and locate the relevant material again and again. Automatic discovery introduces the same repeated search, retrieval, and context-building costs raised in the original post.

A migration path that requires every user to manually manage vendor documentation into each workspace is not a serious migration path. And the statement that this decision was not made to increase spending does not answer the technical question about its effect.

Please answer one simple question directly:

For repeated use of the same documentation corpus, is the replacement workflow more token efficient or less token efficient than @Docs?

Not whether newer models are better at finding documentation. Not whether links and local copies are possible. Not whether the decision followed Cursor’s operating principles. Is it more token efficient or less token efficient?

If Cursor measured this before removing the feature, publish the comparison. If Cursor did not measure it, state that plainly. If the replacement consumes more tokens, then increased spending is a predictable consequence regardless of whether it was the stated intention.