Grok 4.5 Hands-On: A Faster, Cheaper Coding Dark Horse — Can It Replace Opus and GPT?

Grok 4.5's Surprising Leap Forward

When people think of Grok, few would associate it with top-tier coding ability. Until now, it had never truly stood alongside frontier models like Opus 4.8 or GPT 5.5 — and it was especially mediocre at programming tasks. But Grok 4.5 has completely changed that impression.

In one sentence: if you've been wanting Opus 4.8-level quality but faster and cheaper, Grok 4.5 is basically the answer. That's a bold claim, especially given Grok's starting point — but there's solid evidence to back the enormous leap from the previous 4.3 to 4.5.

According to Cursor, Grok 4.5 is the "smartest model" jointly trained with teams related to xAI, and the first not built solely around software engineering scenarios. Unlike the coding-focused Composer 2.0, Grok 4.5 is more like the general-purpose Grok we know — capable of handling long-running tasks across software engineering, data science, finance, law, and other domains that require the creative use of tools.

Don't Just Look at Benchmarks: Real-World Performance Is What Matters

Both xAI and Cursor have published their own benchmark reports. But as many developers agree, benchmarks aren't everything.

SWE-bench is one of the most widely cited code-capability benchmarks in the industry. Created by a research team at Princeton University, it was formally presented at NeurIPS 2023. It draws issues from real open-source GitHub projects and asks models to generate patches that pass the corresponding test cases, thereby simulating real software engineering tasks. This design is closer to real engineering scenarios than fill-in-the-blank programming problems — it doesn't test syntax completion, but requires the model to read an issue, understand the full codebase context, and generate a patch that makes the existing test suite pass.

Notably, SWE-bench's evaluation tasks come from 12 mainstream Python open-source repositories (including Django, Flask, scikit-learn, and others), with each task corresponding to a real Pull Request that the model must reproduce independently without access to that PR. In the benchmark's early days, top models achieved a pass rate of under 2%; as agent frameworks and model capabilities have rapidly evolved, leading systems now exceed a 50% pass rate. This rapid climb has itself sparked community skepticism about the test's validity.

First, open-source code and issues on GitHub appear extensively in the pretraining corpora of major models, so the test set is essentially no longer "unseen," creating a risk of data contamination. Second, some teams specifically boost their scores by fine-tuning on similar problems or optimizing the reasoning pipeline, which is severely disconnected from the generalization ability needed in day-to-day development. This has prompted the community to explore evaluation approaches that are harder to "game," such as using private codebases or introducing human verification steps.

It's worth mentioning that SWE-bench's evaluation framework is itself continuously evolving — SWE-bench Verified introduced a human-annotated "verifiable subset," while SWE-bench Multimodal has begun incorporating multimodal inputs like UI screenshots, attempting to more closely approximate the complexity of real engineering scenarios. The emergence of these variants both acknowledges the limitations of the original benchmark and reflects the community's ongoing exploration of the question: "How do we measure real programming ability?"

One telling case deserves attention: Cursor deliberately chose not to publish its own Cursor Bench scores in its blog — even though Grok 4.5 High outperformed Fable 5.0 on that test at a much lower cost. The reason is that an early snapshot of the Cursor codebase was accidentally included in the training data, giving Grok 4.5 an innate advantage on that test. While the team couldn't quantify the exact impact, they have removed this data from the training set of future models. This precisely illustrates why benchmarks shouldn't be the sole basis for judgment.

What's truly worth referencing is Artificial Analysis's evaluation. Its value lies not in the absolute numbers, but in clearly showing the leap from Grok 4.3 to 4.5 — jumping from the bottom of various tests (human baseline, Terminal Bench, etc.) to the top ranks, essentially on par with models like Opus 4.8 and GPT 5.5.

Price and Efficiency: The Real Killer Advantage

Grok 4.5's pricing is highly competitive: $2 per million input tokens and $6 per million output tokens.

For comparison:

• Opus 4.8: $5 per million input tokens, and output tokens as high as $25
• GPT 5.5: $5 per million input tokens, output tokens at $30

It should be added that while GPT 5.5 has a higher sticker price, it's fairly token-efficient in actual use; Opus 4.8 is relatively "token-hungry." Grok 4.5 is said to be roughly twice as token-efficient as leading peer models, completing tasks in fewer than half the steps. This means it's not only cheaper per token, but actually consumes fewer tokens and responds faster — a triple advantage stacking up to make its value proposition quite compelling.

Understanding the underlying logic of this efficiency advantage requires introducing the concept of "effective cost": when evaluating the real-world usage cost of an LLM, simply comparing the sticker price per million tokens is often misleading. What truly matters is "total tokens consumed to complete a unit task × unit price." If one model can finish in 3 tool calls what another needs 7 calls to accomplish, its actual bill may be lower even at a higher sticker price. This is why IDE vendors like Cursor increasingly favor "cost per task" rather than "cost per token" as the core metric when evaluating integrated models.

Why Could Grok Leap from the Bottom to the Top?

At a time when other AI labs are generally making only incremental improvements, Grok's leap stands out. The answer lies largely in the Cursor acquisition.

The core value of acquiring Cursor lies in data. Cursor has substantial revenue and top talent, but what truly propels a model to the next level is the massive amount of real developer interaction data it has accumulated over the years. The official blog essentially confirms this: Grok 4.5 uses a MoE (Mixture of Experts) architecture, and its training includes trillions of tokens of Cursor data, covering the extensive interactions between developers and codebases and software tools.

The MoE (Mixture of Experts) architecture is one of the core technologies driving large-model scaling in recent years. The idea traces back to the "mixture of experts" neural networks proposed by Jacobs et al. in the 1990s, and was reignited in the large-model era by Google's Switch Transformer (2021), then widely validated by projects like Mixtral and GPT-4. Unlike traditional "dense" models that activate all parameters for every input, MoE divides the model into a large number of relatively independent "expert" subnetworks, and during each inference, a lightweight "gating network" dynamically selects a few experts (usually Top-2) to process the current token. This design allows the model's total parameter count to be enormous (boosting capacity and knowledge storage) while activating only a small fraction of parameters during actual inference (controlling compute cost and latency) — essentially trading memory for compute.

A typical MoE model might have hundreds of billions of total parameters but activate only about 20–30% of them per forward pass, keeping inference latency close to that of a small model while maintaining high capacity. Another engineering challenge of the MoE architecture is "load balancing": if most tokens are always routed to the same few experts, the remaining experts are wasted through underutilization, while the overheated experts become performance bottlenecks. To address this, Switch Transformer introduced an auxiliary loss to penalize imbalanced routing, and later work like Expert Choice routing fundamentally changed the routing direction — having experts actively "choose" tokens rather than tokens choosing experts, thereby guaranteeing load balancing at the architecture level. For Grok 4.5, which needs to simultaneously possess cross-domain capabilities in code, law, finance, and more, the MoE architecture provides a relatively "low-cost" path to capability expansion, which is also one of the structural reasons for its inference-speed advantage over some dense models.

Whenever a developer uses a model in Cursor — accepting a change, requesting tweaks, or abandoning a suggestion entirely — as long as they haven't opted out, this feedback is saved and becomes highly valuable training material. This type of data is known in the AI training field as RLHF (Reinforcement Learning from Human Feedback) preference data, whose value far exceeds that of unlabeled code text. RLHF was systematically implemented by OpenAI in InstructGPT (2022). Its core workflow is: collect human preference comparisons of model outputs (A is better than B), train a "reward model" to predict human preferences, and then use this reward signal to fine-tune the language model through reinforcement learning (typically the PPO algorithm).

The data Cursor has accumulated is especially valuable because it covers not just static code text but complete human-machine interaction trajectories: which suggestions developers accepted, which they rejected, how they requested modifications, and in what context they abandoned a direction. Such "implicit feedback" signals barely exist on the public internet, yet are key to letting a model truly understand "what constitutes good engineering judgment." Notably, this kind of data also naturally contains "negative samples" — rejected or modified suggestions carry rich information too, telling the model which approaches don't work in real engineering. In recent years, the research community has also developed more efficient alternatives to RLHF, such as DPO (Direct Preference Optimization), further lowering the engineering barrier to converting preference data into model capability. The model can thus learn both from existing software and from real human-machine interactions — how developers work and how agents collaborate with their environment. Through the Cursor acquisition, xAI gained in one stroke a high-quality closed-loop data asset that is rare in the external market.

Meanwhile, xAI's hardware resources are equally significant — training spanned tens of thousands of NVIDIA GB300 GPUs combined with stability techniques designed for large-scale training, together enabling Grok 4.5's capability leap. The GB300 belongs to the Blackwell Ultra architecture, with a single card boasting up to 288GB of HBM3e memory, designed specifically for training ultra-large-scale language models. Compared with the previous-generation H100, the GB300 offers roughly 4x the peak compute at FP8 precision, and supports fifth-generation NVLink interconnect, dramatically increasing inter-node bandwidth. This is especially critical for the MoE architecture — MoE's expert routing mechanism generates massive cross-device All-to-All communication, and interconnect bandwidth is often the bottleneck of cluster efficiency.

In ultra-large-scale training clusters, this communication overhead typically accounts for 15% to 30% of total training time, and easing the bandwidth bottleneck has a multiplier effect on overall training throughput. Beyond hardware, training large-scale MoE models also requires solving the scheduling problem of "Expert Parallelism": unlike data parallelism or tensor parallelism, expert parallelism requires distributing different experts across different devices, and dynamic routing means the number of tokens flowing to each expert varies within each batch. How to handle this dynamic load while ensuring computational efficiency is a major systems-engineering challenge. Yet the number of GPUs is only the ticket to entry — what truly determines training efficiency is cluster interconnect bandwidth and stability engineering. In training tasks at the thousand-plus-card scale, node failure rate multiplied by training duration usually means a robust checkpoint recovery and fault-tolerance mechanism must be designed, and this is precisely where xAI has invested specifically.

Hands-On Coding Ability: Highlights and Shortcomings

Completing a Task Fable 5 Repeatedly Failed

In a Rust + Electron screen-recording project being ported from macOS to Linux, Grok 4.5 solved in minutes a problem that Fable 5 had failed to complete after six or seven consecutive attempts. The root cause was a wiring bug in the "rainbow screen" preview, not missing capture.

Grok 4.5's fix involved: pointing the software preview to live.jpg and pulling it at 15 FPS, skipping preview live-start on Linux to avoid FFmpeg overwriting compositor frames, renaming the portal source, and lazy-loading Electron Updater to prevent crashes before the app was ready. This fix case is quite representative: screen capture on Linux involves the three-way coordination of PipeWire/XDG Desktop Portal, DRM/KMS compositor framebuffers, and the FFmpeg video pipeline, where a timing race at any layer can corrupt frame data — the rainbow screen is a classic symptom of incorrectly mixing YUV and RGB color spaces or frame pointer overruns. That Grok 4.5 could locate and fix problems on both the TypeScript (Electron main process) and Rust (native capture layer) sides simultaneously shows it has a relatively complete understanding of asynchronous timing issues that cross language and process boundaries, rather than merely doing surface-level syntax fixes. While not a perfect fix, it genuinely works and involves changes on both the TypeScript and Rust sides.

Excellent Engineering Judgment

When building a "Java version of UV" in Rust (a static binary tool for managing JDKs and natively resolving Maven dependencies), Grok 4.5 delivered a satisfying result: all 24 tests passed, it compiled successfully on the first try, and Clippy checks were completely clean.

Even more praiseworthy was the genuine engineering understanding it demonstrated. When choosing which JDK package to install, it proactively added stable tie-break sorting for the package IDs — because the Foojay API doesn't guarantee the order of returned results, and without this line, the same install command run twice could yield different packages, when the core of this tool is precisely reproducibility. This proactive defensive-coding awareness is especially rare: when an API contract is ambiguous, low-quality AI code typically handles only the "happy path," whereas Grok 4.5 proactively identified an implicit source of non-determinism and eliminated it at the code level — exactly the kind of detail an experienced engineer would scrutinize during code review. The code style is also quite idiomatic, without the nested-if pileups AI tends to produce.

Shortcomings That Still Exist

Of course, problems do objectively exist. In the function for choosing the "best installed pin," Grok 4.5 compared semantic versions as strings, causing 209.9 to be incorrectly judged as greater than 209.11.

Semantic Versioning (SemVer) is the software industry's standard version-numbering specification, formally proposed in 2013 by GitHub co-founder Tom Preston-Werner. Its format is MAJOR.MINOR.PATCH, where all three fields are non-negative integers representing breaking changes, backward-compatible feature additions, and bug fixes respectively, and must be compared numerically rather than lexicographically. Treating version numbers as ordinary strings is a common pitfall in AI-generated code — in string comparison, '2.9.0' is considered greater than '2.11.0', because when comparing the third character, the ASCII code of '9' (57) is greater than that of '1' (49), and the algorithm returns immediately, completely ignoring numeric semantics.

In scenarios like package managers or JDK version selection, this leads to silent erroneous downgrades or upgrades — the program throws no error, but the version actually installed may be the complete opposite of what was intended. Such bugs are often extremely hard to catch in testing because the functionality still works normally, just with the wrong version. The reason such problems recur in AI-generated code is partly due to abundant bad examples in pretraining corpora: Stack Overflow and tutorial blogs are full of code snippets that compare version numbers as strings, and the model statistically learned this pattern without learning that it's numerically incorrect. Even more ironically, the project had already introduced a jv-version crate specifically for version comparison, yet Grok 4.5 failed to reuse it. Additionally, in the TypeScript project it left behind unused shortDomain dead code — though such problems also exist in Fable 5, GPT 5.5, and Opus 4.8, and aren't unique to Grok 4.5.

One-Shot Generation Test

The testing also included making a lawn-mowing game by compiling Rust to WebAssembly.

The result was quite interesting: Grok 4.5 strictly followed the prompt of "pure Rust compiled to WebAssembly"; whereas Fable 5, despite having a better architecture and a more polished result, took the liberty of introducing JavaScript and CSS, deviating from the original requirement. This contrast perfectly reveals the different orientations of the two model types: one faithful to instructions, the other more inclined toward autonomous improvisation.

It's worth mentioning that compiling Rust to WebAssembly is itself a relatively mature but toolchain-demanding technical path — Rust's official toolchain provides Tier-1 support for the wasm32-unknown-unknown target, and combined with wasm-bindgen and wasm-pack can generate browser-executable modules with near-native performance. Unlike the Emscripten path of compiling C/C++ to WASM, Rust's WASM toolchain is closer to "native WASM": it doesn't rely on Emscripten's JavaScript glue layer, the memory model is fully managed by Rust's ownership system, and interoperability with JavaScript is generated at compile time via wasm-bindgen's procedural macros as type-safe bindings. This requires the model to accurately understand: which standard library features are unavailable under the wasm32 target (such as filesystem and threads), how to expose Rust functions to JS via #[wasm_bindgen], and how to manipulate the Canvas API without introducing JS dependencies — no easy test. That Grok 4.5 could complete this task under the pure-Rust constraint shows its understanding of toolchain configuration and cross-language boundaries has reached a usable level.

Workflow Positioning: The Best Partner for Rapid Iterative Tasks

Fable 5 is a "loop-type" model — you give it a clear goal and let it coordinate multiple sub-agents running in the background for extended periods. Opus 4.8, GPT 5.5, and Grok 4.5 are positioned differently, and among them Grok 4.5 has the fastest response speed.

It's essentially on par with the other two in coding ability, but much faster. You give it a task, and with almost no wait, you see results within a minute. For developers who enjoy frequent back-and-forth interaction with AI, Grok 4.5 is an ideal choice.

Here are several recommended usage scenarios:

• Direct replacement for GPT 5.5 or Opus 4.8, enjoying lower prices and faster speed
• As a sub-agent, letting Fable 5 handle high-level orchestration while routing batch execution tasks to Grok 4.5
• Pair programming, forming a "pair programmer" duo with Opus 4.8 or GPT 5.5 to complement each other

Conclusion: Coding AI Enters a New Three-Way Standoff

The first tier of coding models has now evolved into Anthropic, OpenAI, and xAI (with the help of Cursor), while Google has temporarily failed to break into the top three. Of course, the above conclusions come from a single reviewer's roughly 24 hours of hands-on experience, and it remains to be seen whether rate limiting will occur or whether performance will change in the future. But one thing is certain: the coding AI space now has one more serious player that can't be ignored — and it arrived faster than most people expected.

Key Takeaways

Key Takeaways