Grok 4.5 Deep Dive: Coding on Par with Top Models, at a Fraction of the Cost

A New Model Quietly Arrives, With a Bold Promise From Its Creators: For Development Work, It Rivals Top Models at a Fraction of the Cost. This Is Grok 4.5—Trained by xAI in Deep Collaboration With Cursor.

As a developer who has used it non-stop over the past 24 hours, I want to give an honest take on this model—the good, the bad, and the ugly.

An Unexpected Surprise

Interestingly, I was initially skeptical of the hype. But Cursor gave me early access to a new model, which I assumed was a new version of Composer, and I was quite impressed using it. It was only later that I learned this model was actually Grok 4.5.

Looking at Artificial Analysis's coding index, Grok 4.5 is nearly neck-and-neck with GPT-5.5, only slightly behind Fable, while also beating Opus 4.8. Although I think these numbers might be a little aggressive based on my experience, they're not far off.

What's even more noteworthy are the training details. Officials revealed that Grok 4.5 was trained on tens of thousands of NVIDIA's latest GB300 GPUs. The GB300 is the flagship data center chip in NVIDIA's Blackwell Ultra series, which officially entered mass production and delivery in 2025. To understand the strategic significance of this hardware choice, you need to understand the generational leap the Blackwell architecture brings to AI training: compared to the previous-generation Hopper architecture (H100/H200), Blackwell introduces a second-generation Transformer engine that supports FP4 precision mixed computation—FP4 is currently the lowest-precision floating-point format supported by data-center-grade chips, capable of boosting matrix operation throughput nearly 4x with almost no loss in model quality. More critically, the GB300 integrates HBM3e high-bandwidth memory, with a single-card capacity of up to 288GB and memory bandwidth exceeding 10TB/s—which is crucial for training ultra-large-scale MoE models like Grok 4.5. Larger HBM capacity means more expert parameters can fit on a single card, dramatically reducing cross-card communication overhead; high bandwidth directly determines the loading speed of activated parameters during Expert Routing, thereby affecting training convergence efficiency. xAI's ability to be among the first to deploy the GB300 at scale is largely thanks to its early infrastructure buildout at its Memphis supercomputing data center. Being able to mobilize such a scale of compute marks xAI's true entry into the ranks of the world's top AI labs in terms of compute power.

It's worth noting that the GB300 also features fifth-generation NVLink interconnect technology, with inter-card bandwidth reaching 1.8TB/s in an 8-GPU server—nearly double the previous generation. This is especially important for distributed training of MoE models—under the Expert Parallelism paradigm, every forward propagation step requires high-frequency transfer of token activations "routed to remote experts" between cards, and the elimination of the NVLink bandwidth bottleneck directly translates into improved training throughput. This also explains why, even when using an MoE architecture with more parameters, xAI can maintain competitiveness in training efficiency.

The team invested heavily in data filtering, deduplication, quality scoring, and domain selection. This time it's a 1.5 trillion parameter MoE model, whereas the previous Grok had only 500 billion parameters—clearly indicating that this is a brand-new pretraining, not a fine-tune on top of the old model.

What is an MoE model? The core idea of the Mixture of Experts model was first proposed by Jacobs et al. in 1991, but it truly shone in large language models starting with Google's Switch Transformer (2021) and GLaM. Unlike traditional dense models that activate all parameters in every forward pass, MoE's key component is the "Gating Network," responsible for dynamically selecting which "Expert Subnetworks" to activate during each token's forward pass, typically using a Top-K routing strategy (e.g., Top-2, meaning only two experts are activated at a time). Each expert is essentially an independent feed-forward network (FFN) focused on handling different types of semantic patterns. This means a 1.5 trillion parameter MoE model may only call about 200-300 billion parameters during actual inference, thereby maintaining ultra-large model capacity (which determines breadth of knowledge and complex reasoning ability) while keeping computational costs on par with mid-sized dense models. The MoE architecture also brings another key advantage: different experts can be distributed across different GPUs for parallel processing, making horizontal scaling of model size more efficient—this is precisely one of the underlying technical logics enabling Grok 4.5's low pricing, and the fundamental reason Google widely adopts this architecture in models like Gemini 1.5 and Mixtral.

To further understand MoE's scaling logic: when a model scales from 500 billion to 1.5 trillion parameters, a dense model's inference compute (FLOPs) increases proportionally, but an MoE model's actual inference compute stays almost unchanged, because the number of activated experts is fixed (determined by the Top-K hyperparameter). This "decoupling of parameter count from compute" property is the fundamental reason the MoE architecture can continuously scale model capacity without significantly raising inference costs—and it's the core support that allows Grok 4.5 to maintain low pricing after scaling from 500 billion to 1.5 trillion parameters.

The Unique Advantage of the Cursor Collaboration

Cursor (now part of xAI) revealed more details in its official article. The training included trillions of Cursor usage data points that capture users' extensive interactions with codebases and software tools, allowing the model to learn both from existing software and from "developer-agent" interactions.

The combination of this data with the RL training pipeline seems to be precisely the key to Grok 4.5's excellent benchmark performance. Traditional RLHF (Reinforcement Learning from Human Feedback) relies on human annotators to rank model outputs by preference, which is costly and prone to annotation bias—human annotators often tend to reward outputs that look "fluent" rather than truly "correct" code logic. The path Grok 4.5 takes goes further—combining trillions of real Cursor operation trajectories with RL, essentially a hybrid training paradigm of implicit Behavioral Cloning and online RL. These real records naturally provide "state-action-outcome" triplets: the state is the current codebase snapshot and user intent, the action is the model's edit suggestion, and the outcome is whether the user accepts it or modifies it further. This dataset naturally covers the complete development loop of "ambiguous requirements → multi-round clarification → code generation → bug fixing → refactoring," enabling the model to learn developers' real decision-making patterns when facing ambiguous requirements, bug fixes, and multi-round iterations—rather than idealized behavior in a lab environment. This is conceptually similar to the approach DeepMind used in AlphaCode 2: using real competition submission records (including erroneous submissions and correction processes) as training signals, rather than relying solely on synthetic data. Cursor's user base of millions of daily active users is a core data moat that other models find hard to replicate—even if competitors know the methodology, they can't accumulate real development behavior data of the same scale and quality in the short term.

This data advantage is also reflected in a key dimension: the density of coverage for failure modes. Synthetic training datasets or competition datasets typically only contain "success paths," whereas real Cursor data inevitably contains numerous records of users rejecting suggestions, undoing operations, and repeatedly requesting modifications—these "negative sample trajectories" are crucial for training the model to understand "what kind of output will be accepted, and what will be rejected." This is essentially an implicit reward signal based on real user behavior, with information density far higher than manually constructed preference pairs.

The team deliberately kept the training data broad, incorporating high-quality STEM tasks, research papers, and other knowledge-work content, giving the model solid capabilities across multiple domains.

The team's transparency is commendable: they candidly admitted an advantage on Cursor Bench, because an early Cursor codebase snapshot was inadvertently included in the training data, so they did not use this benchmark to promote Grok 4.5 externally—this kind of honesty is rare in the current AI arms race.

Pricing: The Real Core Competitiveness

If there's anything that truly makes Grok 4.5 stand out, it's its pricing strategy.

Grok 4.5 is priced at $2 input and $6 output per million tokens. By comparison, Fable is $10 input and $50 output—a 5-to-10x cost difference. On Cursor Bench, Fable 5 High costs $8.77 per task, while Grok 4.5 costs only $1.51, and scores slightly higher.

Note that this pricing only applies to contexts below 200K tokens. Above that, the price doubles, and the maximum supported is only 500K tokens. This design is a bit awkward—the increase from 200K to 500K context isn't that large, yet it costs double. This is likely to keep the base version's input/output costs as low as possible, while balancing the high profits from reselling GPUs to companies like Anthropic and Google. xAI has put itself in a delicate position, but has handled it well overall.

From the economic logic of the pricing structure, the cost curve for long-context inference is not linear: when the context window exceeds a certain threshold (usually the region where the model's attention computation begins to hit the "quadratic complexity" inflection point), the compute overhead of each additional token rises significantly, because standard Full Attention has a computational complexity of O(n²). The 200K token tiered pricing node is likely precisely the balance point xAI found between inference efficiency and marginal cost—requests below this threshold can be highly batch-processed with GPU utilization near peak; above it, more VRAM must be reserved for each long-context request, batch processing efficiency drops, and marginal cost rises sharply.

Astonishing Token Efficiency

What truly shocked me was its token efficiency. In Artificial Analysis's intelligence index, Grok 4.5 scored 54, ranking fourth, just behind GPT-5.5 and ahead of Sonnet 5. And the average cost per task was only $0.31, lower than GLM 5.2's $0.37 and Kimi K2's $0.35, yet with a much higher score. For reference, Fable 5 needs $2.75 to do the same work.

In terms of token consumption for coding tasks, Fable used 7.2 million tokens, Opus used 9.2 million, while Grok 4.5 achieved a high score with just 2 million tokens. This efficiency difference is deeply significant at the engineering level: token consumption not only determines direct cost but also affects response latency—in the high-frequency usage scenarios of AI coding assistants, lower token consumption means shorter wait times and faster iteration rhythm. Understood from an information theory perspective, token efficiency essentially reflects the model's "semantic compression capability": an efficient model can express program logic of equal complexity with shorter token sequences, meaning its internal representation encodes code semantics with higher density.

More importantly, it shows that Grok 4.5 has higher inherent efficiency in information compression and instruction following, able to express results of equal quality with more concise output, rather than padding out answers by stacking redundant reasoning steps (like repeatedly restating the problem or over-expanding intermediate derivation chains)—this "verbose reasoning" phenomenon is especially prominent in some models that have been over-trained with reinforcement learning, and significantly drives up actual usage costs. From a user experience perspective, redundant tokens also cause significant "Time to First Token" degradation in streaming output mode, reducing the fluidity of real-time interaction. Grok 4.5's advantage in token efficiency gives it a real competitive edge beyond its face-value pricing in the AI coding assistant scenario, which is highly sensitive to response speed—this makes it an excellent default coding model. Let it run first, and if you're not satisfied, use another model to finish up.

Real-World Usage: Unexpectedly Reliable

Benchmarks ultimately can't measure how a model feels to use in real-world scenarios. Many Google models have impressive scores but write mediocre code in practice. So how does Grok 4.5 perform in the trenches?

Honestly, I was amazed. I was doing a comprehensive pre-release audit for my cloud product Lakebed. Grok 4.5 found most of the issues that Fable and GPT-5.6 found, and performed excellently when it came to fixing them. I kept ramping up the difficulty, having it handle complex multi-objective tasks: splitting PRs, addressing review comments, making changes based on screenshots—it handled them all, and the process was enjoyable.

I even deliberately made my questions increasingly vague, wanting to see where it would break down, but it never made a mistake. Keep in mind that even GPT-5.5 can "get stuck" in these long multi-turn conversations, fixating excessively on some detail from three messages ago. This phenomenon is technically called "Attention Dilution"—as context length increases, the Transformer's attention mechanism has to distribute weights across more tokens, causing the relative attention weight of early key information to decline, and the model may "forget" or incorrectly inherit constraints already resolved in earlier conversation rounds.

There are several common mitigation strategies for this problem in engineering practice: first, improvements at the positional encoding level, such as RoPE (Rotary Position Embedding) and YaRN (dynamic NTK interpolation), which adjust the decay curve of positional encoding to keep the positional information of distant tokens better distinguishable; second, attention sparsification (Sparse Attention), such as Sliding Window Attention, which reduces the computational overhead of long sequences by limiting each token's attention range; third, explicit memory mechanisms (External Memory), which let the model actively extract and index key constraints in long conversations. Grok 4.5 had no issues at all in the multi-turn interaction experience, which is likely related to characteristics of its MoE architecture in long-context processing: different experts can focus on handling different segments of conversation history, forming an implicit distributed memory that reduces the information "dilution" effect.

An Unexpected Surprise: 3D Modeling Capability

What surprised me even more was its 3D modeling capability. I asked it to turn a previous mini-game into a 3D version, and it successfully created a complete 3D environment, modeling various creatures and scene geometry on its own, with results far surpassing any other model I've used, including Fable and GPT-5.6.

Although the model quality is far from "publishable" standards, and the control directions were even reversed (A key moved right, D key moved left), this is the first model whose 3D modeling in frameworks like Three.js is "almost decent." Three.js is a WebGL-based JavaScript 3D graphics library, and its technical difficulty lies in the fact that its API abstraction layer is deliberately kept thin, directly exposing many low-level concepts to developers—the Scene Graph defines the hierarchical transformation relationships of objects, Geometry requires manually defining vertices, normals, and UV coordinates, complex interactions exist between materials (Material) and lighting systems (PBR physically based rendering), while the camera's Projection Matrix and View Matrix require developers to understand the coordinate transformation chain of 3D space.

For an AI model, correctly handling Three.js code means simultaneously maintaining consistency across multiple 3D coordinate systems and understanding the conversion relationships between spatial rotation representations such as Euler Angles and Quaternions—which places high demands on the model's spatial geometric reasoning ability. The specific error of reversed control directions (A/D key mapping flipped) precisely illustrates the fine-grained nature of this challenge: such errors often stem from the model getting confused when handling the Chirality difference between the "camera coordinate system" and the "world coordinate system," involving the sign conventions of the right-handed coordinate system, which is a classic "semantic trap" in 3D programming. Even so, being able to generate a structurally complete and basically runnable Three.js scene without explicit 3D programming guidance already represents significant progress for current AI models in the field of spatial reasoning. Grok 4.5's ability to make a breakthrough in this area is likely related to the large number of real Cursor users' operation trajectories on 3D projects included in its training data. This was something I completely did not anticipate.

Regrets and Limitations: A Generational Gap

Of course, Grok 4.5 isn't perfect. On Skate Bench, it became expensive due to repeatedly reasoning in an attempt to find techniques, ultimately scoring only 76%—the lowest score among frontier labs at the highest reasoning setting. Its reasoning is indeed on the "heavy" side, averaging 2,100 tokens per response.

The more critical weakness lies in Orchestration. Orchestration refers to the model's ability to act as an "Orchestrator Agent" coordinating multiple sub-agents, decomposing complex tasks, and managing concurrent processes—this is one of the most cutting-edge capability frontiers in current AI engineering. Specifically, orchestration capability includes: decomposing high-level goals into sub-task sequences in the form of a directed acyclic graph (DAG), assigning appropriate tools or sub-agents to each node, monitoring execution status in real time and handling exceptions (sub-process timeouts, tool call failures, inconsistent results), and triggering reasonable Rollback or Retry strategies upon local failures. This capability is crucial in software engineering scenarios: large refactoring tasks typically involve modifying dependency chains across dozens of files, parallel test generation requires coordinating the output of multiple code analysis tools, and CI/CD pipeline optimization requires the model to understand the topology of the build system.

From a technical standpoint, Grok 4.5's shortcomings in orchestration may be related to the routing mechanism of its MoE architecture: in long-sequence tasks requiring dozens of tool call steps, different tokens are routed to different experts, making it harder than dense models to maintain the coherence of task state—the lack of shared Global Working Memory between different experts makes cross-step state tracking more prone to "semantic drift," i.e., by the 20th step of a tool call, the model has partially forgotten the constraints established at step 3. This phenomenon is formally similar to the "Task-Switching Cost" in cognitive science: when an agent needs to frequently switch contexts between different tool calls, the cognitive load of maintaining complete task state (manifested in the model as attention and KV Cache management overhead) increases exponentially with task depth. This also explains why it performs excellently in single, long-context conversations, but easily gets stuck in "decompose-assign-aggregate" multi-agent scenarios. Fable and GPT-5.6 represent a new generation of models—their training was specifically reinforced for "Tool-Use Chains" and "Multi-Step Planning," enabling them to schedule sub-agents and break large tasks into smaller pieces, thereby completing more difficult tasks. Grok 4.5 is clearly lacking in this respect; when I tried using it to split sub-agents, I wasn't satisfied—it often got stuck because a process hung, not knowing how to clean up afterward.

To use a gaming analogy: they just released the best PS2 game in history, but the PS3 has already been on the market for two months. Grok 4.5 is more like an ultimate creation made with last-generation technology, rather than truly crossing into a new generation.

Conclusion: xAI Can No Longer Be Underestimated

Despite the limitations above, xAI's leap this time is still astonishing. Going from being nearly forgotten, able only to resell GPUs, to beating almost all competitors at its own tier with a cheaper, more efficient model—such a magnitude of progress can perhaps only be matched by DeepSeek^Ad.

I once predicted xAI might have a crazy turnaround, thinking it would take six months to a year, but the timeline turned out to be even shorter. This is the first competitor Anthropic and OpenAI have truly needed to be wary of in a long time. I hope the ultimate outcome Grok 4.5 brings is that everyone can access faster, cheaper, smarter AI models.

Congratulations to xAI for catching up. I didn't think you had it in you, but you clearly did.

Key Takeaways

• Grok 4.5 is a 1.5 trillion parameter MoE model, pretrained on tens of thousands of GB300 GPUs, and the scale of compute marks xAI's official entry into the ranks of top AI labs
• Highly competitive pricing: $2 input / $6 output per million tokens, 5-10x lower than models at the same tier, with extremely high token efficiency (completing the same task using only 1/3 to 1/4 the tokens of competitors)
• Excellent real-world coding experience: smooth handling of multi-turn complex tasks, stable long-context attention, and unexpectedly strong spatial reasoning ability in high-difficulty scenarios like Three.js 3D modeling
• The core weakness is multi-agent orchestration: underperforms in complex tasks requiring coordination of sub-agents and management of concurrent tool call chains, related to its MoE architecture lacking cross-expert global working memory
• Cursor data is the core moat: trillions of real development behavior trajectories constitute a training advantage hard to replicate, with information density and failure-mode coverage far exceeding synthetic data or competition datasets
• Suitable as a default coding model: completes most development tasks at extremely low cost, then switch to a stronger model when hitting capability limits—this workflow has proven itself in both economics and practicality