Our general impression after a few days with Grok 4.7 is that there’s a clear overall improvement over Grok 4.6.
For us, the biggest change isn’t necessarily one specific area like long tasks. It’s that Grok 4.7 seems much better at actually sticking to what we asked for and to the decisions we already made during the task.
With Grok 4.6, we often ended up preferring Composer. Grok could usually get to a decent result, but many times it would ignore or drift away from constraints, approaches, or decisions we had already agreed on.
With Grok 4.7, this is probably the biggest improvement we’ve noticed so far. The results themselves can be similar, but now it follows the agreed direction much more consistently, and for real project work that makes a huge difference.
We’ll keep testing more specific areas, but so far this has been the most noticeable improvement for us. Cheers!
Just a note: we’re testing it with xHigh and a 500k
This is so surprising, as we have had the opposite experience, but maybe we need to adjust how we interact with the new model. Were you able to carry over the same behaviors from other model interactions? Curious how structured vs. conversational your work with Grok/Cursor is, too.
I am seeing degradation in quality across all models, not just Composer and Grok. I’m wondering if has something to do with the harness changes mentioned in this blog post? Muse/Opus/Grok/Composer all seem to be having issues following tasks and keeping context throughout the conversation. It seems to have started towards the end of last week.
In our case we actually use Grok/Cursor in a few different ways, but always around a real project involving one or more repositories.
The three main patterns are:
No harness / conversational first.
We start each requirement with a fairly free conversation: what needs to be done, expected behavior, possible approaches, tradeoffs, etc. We usually ask the model for its opinion as well. This continues until the person is confident there are no open questions. Then we switch to Agent mode and let it implement, sometimes generating several thousand lines of code.
Harness defined inside the repository.
Here the workflow is much more structured. We have things like an AGENTS.md pointing to documentation, agents, rules, etc., and different stages with specialized agents.
For example, the first stage may involve a business agent with all the business documentation and a technical agent with the technical documentation. Their job is to analyze the requirement and interact with the user until everything is clear and aligned.
After that, the rest can be fully automated: development, technical tests, user-level tests, validation, and iteration until everything passes. Each agent also leaves artifacts behind, and at the end we generate a summary that becomes part of the traceability/documentation for future requirements.
Harness outside the repository.
Conceptually it is similar to the previous one, but the workflow is controlled by an external system, for example Jira states. The process can move automatically between stages or be routed to a person when needed.
So our interaction style ranges from very conversational to very structured.
What surprised us with Grok 4.7 is that we noticed the same improvement in both cases: it seems better at preserving previously agreed decisions, constraints, and workflow rules. With 4.6, that was one of the main reasons we sometimes preferred Composer.
We haven’t changed our way of working specifically for 4.7, so at least in our case the improvement seems to come from the model rather than from adapting the prompts or structure.
My question is; how will xAI compare with current development? I mean; Opus 5.5 and Sonnet 5.5 are just out and honestly I can just code the whole day with both (composer/grok is not needed anymore…). I hope (REALLY HOPE) composer/grok will improve quality of their models so I can say goodbye to Claude and go back to my favorite (which is composer)
It’s a no for me. It seems to get stuck just endlessly thinking and spouting nonsense without giving useful solutions. Regression from 4.6 for me. I miss composer.
Grok 4.7 is really poor in analysis task as compared to Grok4.6 . Grok 4.6 seems real improvement and 4.7 seems a big regression. It unnecessarily goes in thinking loop, forgetting original task / memory on how to use tools. Even composer2.5 is better than grok4.7 for everyday tasks of coding/analysis and debugging.
Bro, I can tolerate Grok 4.7 taking a longer time to deliberate and consuming more resources; however, what I find unacceptable is that it incurs higher costs without demonstrating any significant improvement or advantage over Grok 4.6.
Furthermore, the majority of the multimodal issues I have mentioned predominantly arise in Loop-Engineering. Although it autonomously captures screenshots, it fails to pinpoint the crux of the problem, particularly when handling software interface interactions, where omissions frequently occur. Consequently, I am compelled to intervene manually to halt and redirect its modification efforts.
Please train grok to fix bug at the root cause, not patch on the symptom. Fix bug at exactly where the bad data generated rather than repair the bad data as a post-process. For almost every bug grok fails to uncover the real reason.
I think Grok 4.7 performs very poorly. Even with extra‑high mode enabled, its thinking is quite incomplete, and it is not good at explaining problems. There is no improvement in performance compared with 4.6; sometimes I even find 4.6 more usable. Compared with Grok 4.8, 4.9, 5.0… I am more looking forward to Composer 3.0. I still miss the cost‑performance and results of Composer 2.5 back then, though Composer 2.5 is indeed outdated now.
Agreed! it needs a lot of setup to perform on an enterprise/industry grade tasks, despite cursor keep advertising, it is mainly for enterprise and teams
Cursor Grok causes major issues in production. It creates stubs and workarounds, complicating everything.
Essentially, it behaves deceptively, and its code cannot be trusted.
Composer 2.5 doesn’t do this, and neither does Opus 5.
I’ve built over 30 projects of varying complexity using Cursor. Problems started arising with more complex tasks after the introduction of Cursor Grok.
Please keep developing Composer… it’s the best workhorse, proven across a multitude of tasks.
I use Opus 5 for major debugging and final verification.
Steps to Reproduce
Try to build complex project with UI and Python with Composer and Grok.
Super disappointing. For a lot of the reasons people said.
I have it run headless and I review AI work in Github. I point out things that are wrong and needs to change, then it just describes some mix of what the original code was doing vs what I’m suggesting, leaving me wondering what it’s trying to say. Then it doesn’t actually change stuff.
Repeatedly pulling teeth to try and get it to follow up on simple code review feedback.
Huge Cursor fan, Composer 2.5 fan, and Cursor Grok 4.6 became my personal go-to.
However, comparing against GPT-5.6 Luna in use, I’m finding Luna is completing my tasks more consistently and correctly. And it can be far cheaper… Very surprised to find myself concluding a low-tier model beats a Cursor-trained model in my use. YMMV.
It broke somewhere around Grok 4.7, switching back to Grok 4.6 helped.
Agent receives full plan with doc references and file paths. It has all the .cursor/rules for implementation details, all the tools / scripts and skills. Yet, Grok 4.7 at high spent like 10 minutes “Exploring” and making no progress whatsoever. Poking it to execute the plan didn’t help much, chain of thought only shows “I will do X, then I will do Y” which basically duplicate what’s already in the plan.
This setup has been working for me for a year now, so it turns out it’s Grok 4.7 who fails by overthinking. Could also be related to some Cursor harness changes - can’t tell for sure since there’s no exact changelog for automatic updates.
Also, after I switched to Grok 4.7 I ran out from Cursor budget for last month (including Clodu jobs), which didn’t happen since like half a year. No wonder it it just burns tokens before it does anything.