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.

9

@kevinn I have yet to hear from you or anyone at Cursor on the token usage question.

The question was deliberately narrow to make it easy to answer.

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

Saying the change “was not made to increase what you spend” addresses intent. It does not address the actual effect of the change. At this point, the continued silence is becoming a damning admission by omission. If Cursor measured this and the replacement is more token efficient, then publish the numbers. If Cursor measured it and the replacement uses more tokens, say so. If Cursor never measured it before removing @Docs, say that.

But declining to answer a straightforward technical question about token consumption leaves a pretty obvious conclusion. Cursor either does not have data supporting the claim that this is a better replacement or the data is not favorable enough to share with it’s customers.

11

Hi @spencerthayer, I have not researched this topic extensively, so I don’t have an answer for you at this time.

12

Completely agree with @spencerthayer. Just watching “from the same directors” that devastated former twitter quality AND market value doing the same anti-work with cursor.

Luckily also agree that OpenCode is becoming each day better!

14

I completely agree with @spencerthayer. This was one of the features I relied on the most, and a major reason I chose Cursor over other tools. It was an extremely valuable part of the experience for me.

Even though current models are capable of searching documentation on their own, they still fail at it fairly often. More importantly, some documentation is unique, highly specific, or not easily discoverable, especially when the model has little or no prior knowledge of the tool.

Having a reliable way to explicitly provide and reference those docs made a significant difference, and removing that capability feels like a major step backward.

15

Thanks @kevinn but that answer creates a fairly serious contradiction with your earlier response.

“We didn’t make the decision lightly, but it was carefully considered.”

Now it’s:

“I have not researched this topic extensively.”

Which is it?

Both of your statements are difficult to reconcile. Token consumption is not some obscure side effect of replacing a managed documentation index with repeated fetching, searching, parsing, and context construction. It is one of the most obvious technical and economic consequences of the change. If the removal of @Docs was genuinely “carefully considered,” then comparative token cost should have been part of that evaluation.

Either someone at Cursor measured it, in which case publishing the results would answer the question, or Cursor did not measure it, in which case the claim that the decision was carefully considered deserves considerably more scrutiny. At this point, the absence of an answer is becoming an answer of its own.

And given Cursor’s statement that the decision was made in accordance with its “core operating principles,” all the rice in China says that burning more user tokens was not an overlooked consequence at all, but one entirely compatible with those principles.

The original question remains unanswered and I invite anyone at Cursor to actually address it:

For repeated use of the same documentation corpus, does the replacement workflow consume more tokens or fewer tokens than @Docs?

17

@Luciano_Soares and @vinicius73, the consequences are already showing up in actual daily use for me.

Since updating to the latest version of Cursor, I’ve seen a marked increase in token consumption while getting worse results. This is exactly the problem I predicted when @Docs was removed because the agent no longer has the context it needs to do the actual job.

Instead of working from an organized, indexed documentation corpus, the agent now has to rediscover information, fetch it, interpret it, and rebuild that context repeatedly. That burns more tokens and wastes more time, but the bigger problem is the quality of the work. Relevant documentation simply isn’t in context reliably when the agent needs it, and the output suffers as a result.

At $200/month, that tradeoff is indefensible. More token consumption for lower-quality work is the opposite of what a premium developer tool should deliver. This will be my last month using Cursor. I’m cancelling and burning through the remaining token budget as quickly as possible before it ends.

If the same degradation is showing up in your workflows, I’d seriously consider doing the same. Continuing to pay Cursor premium prices while the product consumes more resources to produce worse work only rewards a stupid, greedy product decision.

19

I completely agree. Got shocked when noticed that indexing docs was just sunshined.
Also seriously considering to move away. Unfortunately that can’t be immediately, but is the most likely natural flow.

20

@Luciano_Soares, the irony is that OpenAI is catching up to Cursor just as Cursor is deliberately making its own product worse. OpenAI is now building Company Knowledge around a fact serious engineering teams already understand.

It is especially short-sighted because Cursor already has a bad reputation in parts of the LLM coding space as a tool for vibe coders and casual users rather than serious engineering. @Docs was one of the features that pushed against that perception because it gave agents reliable access to the specific technical material required for real codebases. The fact is that internal documentation, proprietary context, and organization-specific knowledge are essential inputs for useful AI systems. Removing the feature makes that stereotype true.

22

Me and other colleagues at my company are also disappointed about this change. This used to work so well for us and now if we just link the docs, the agent will have to waste tokens in fetching them, etc.

23

Hi @Mauricio_Berlanga Thanks for your feedback, please see my comments here: Where did the @docs go? - #36 by kevinn

26

100% agree. Give us the docs back.

29

Well this sucks. For me the feature disappeared silently and I noticed a distinct decline in the quality of output for vendor APIs and had to go hunting as to why and surprisewe felt you did not need it so we removed it, yay for us.

32

100% agree with @spencerthayer please give us Docs feature back.

33

Really stupid movie. Definitely seems like a money grab, but honestly, I don’t think any serious developers are using this product. It’s 100% for vibe coders and small shops, not for larger projects. Please don’t get rid of the IDE.