(I work at Cursor) We score well on Terminal-Bench and SWE-bench Multilingual. DeepSWE, not so great yet, as it's more for very long-horizon tasks. We're planning to include more public benchmarks in our next model release.
(I work at Cursor) When Composer 2.5 launched, we initially scored very competitively on AA's composite benchmark. I believe 3rd place overall. They have recently updated to use DeepSWE, which has more of a focus on very long-horizon tasks, and Composer isn't as good at those yet. We're aware and working on this for our next model.
Overall, some benchmarks show Composer doing well, others not so much. We think the model is very capable at the given price point. There's lots to improve! If you see any specific behaviors or places the model isn't very good, lmk here or can email me lrobinson at cursor.com.
(I work at Cursor) CursorBench includes many evals from actual engineering tasks from the Cursor team, which include our private codebase. This codebase is held-out from training so models haven't seen it, including Composer.
(I work at Cursor) Sorry about this, we should have made this more clear. The new privacy mode is needed because we have to store some state to enable running agents in the cloud. If you don't want to use cloud agents, you can continue using the legacy privacy mode. Currently the mobile app requires this new privacy mode and won't work without it. We're pushing an update right now to make this more clear in app and can help you get reverted back to the legacy version on the support thread.
Glass was a codename while the UI was in early alpha with testers. It redirects to download now because there is no special link anymore. It's just part of Cursor 3 itself.
I'm an engineer at Cursor, can try to clarify questions here.
> I wish they'd keep the old philosophy of letting the developer drive and the agent assist. Even when I'm using AI agents to write code, I still find myself spending most of my time reading and reasoning about code.
We very much still believe this, which is why even in this new interface, you can still view/edit files, do remote SSH, go to definition and use LSPs, etc. It's hard to drive and ship real changes without those things in our opinion, even as agents continue to get better at writing code.
> I'm hoping in this new UI in v3 I can still get that experience (maybe it's just hidden behind a toggle somewhere for power users / not shown off in the marketing materials).
This new interface is a separate window, so if you prefer the Cursor 2 style, that continues to exist (and is also getting better).
We used a Kimi base, with midtraining and RL on top. Going forward, we'll include the base used in our blog posts, that was a miss. Also, the license is through Fireworks: https://x.com/Kimi_Moonshot/status/2035074972943831491
We've found it to be a strong mix of speed and intelligence. It scores higher than Sonnet 4.5 on Terminal-Bench 2, maybe we will post more on this later.
(I work at Cursor) We have all these! Plan mode with a GUI + ability to edit plans inline. Todos. A tool for asking the user questions, which will be automatically called or you can manually ask for it. Hooks. And you can use Opus or any other models with these.
> The JS engine used a custom JS VM being developed in vendor/ecma-rs as part of the browser, which is a copy of my personal JS parser project vendored to make it easier to commit to.
> By prioritizing the vibe coding use case, Cursor made itself unusable for full-time SWEs.
This has actually been the opposite direction we're building for. If you are just vibing, building prototypes or throwaway code or whatever, then you don't even need to use an IDE or look at the code. That doesn't really make sense for most people, which is why Cursor has different levels of autonomy you can use it for. Write the code manually, or just autocomplete assistance, or use the agent with guardrails - or use the agent in yolo mode.
> One way to achieve that would be to limit the number of lines seen by an LLM in a single read: read first 100 lines
Cursor uses shell commands like `grep` and `ripgrep`, similar to other coding agents, as well as semantic search (by indexing the codebase). The agent has only been around for a year (pretty wild how fast things have moved) and 8 months or so ago, when models weren't as good, you had to be more careful about how much context you let the agent read. For example, not immediately putting a massive file into the context window and blowing it up. This is basically a solved problem today, more or less, as models and agents are much better are reliably calling tools and only pulling in relevant bits, in Cursor and elsewhere.
> Try to write a prompt in build mode, and then separately first run it in plan mode before switching to build mode. The difference will be night and day.
Agree. Cursor has plan mode, and I generally recommend everyone start with a plan before building anything of significance. Much higher quality context and results.
> Very careful with asking the models to write tests or fix code when some of those tests are failing. If the problem is not trivial, and the model reaches the innate context limit, it might just comment out certain assertions to ensure the test passes.
Agree you have to be careful, but with the latest models (Codex Max / Opus 4.5) this is becoming less of a problem. They're much better now. Starting with TDD actually helps quite a bit.
It's not about a privacy, but common courtesy. Especially after I gave them a heads up in DM about the post and offered to answer any more questions they had. They said they'd reach back out, then didn't, then posted this publicly? Really strange.
I would have appreciated if he asked me before using my name in the post. Especially after I intentionally did not mention them by name at all. Was trying to avoid talking about any one company.