Grok 4.6: Better Agent Benchmarks, With Tradeoffs in Speed and Cost

I've been impressed by the pace of Grok releases. Grok 4.5 was the first model from outside Anthropic or OpenAI that I could imagine using daily, even though it wasn't my default. Now Grok 4.6 promises stronger long-running agent work, and I've spent time testing it on both demos and real projects.

My initial impression is that it can handle extended tasks and coordinate subagents without losing the goal. But it has rough edges too. The official Grok Build CLI has impressed me, while some of the model's visual and game-building results have been disappointing. I want to separate those experiences from the benchmark claims.

The launch announcement says Grok 4.6 builds on 4.5 with a focus on long-running agents and interactive and visual work. Theo initially characterizes the change as post-training, but the announcement he later reads also describes a longer supplemental training run before supervised fine-tuning and reinforcement learning. The release involves more than the simple explanation alone suggests.

The chart shown in the announcement reports an Artificial Analysis Intelligence Index score of 61, level with GPT-5.6 Sol and above Grok 4.5's 56 in that comparison. Such an index is useful context, but it isn't a complete measure of how useful a model feels in a specific workflow. My own experience with models has sometimes diverged from their scores.

The displayed DeepSWE result rises from 54% for Grok 4.5 to 65.9% for 4.6, while FrontierCode rises from 56.6% to 61.3%. CursorBench also improves. I raise a concern about earlier benchmark contamination and say I'm unsure whether the version shown resolves it; that uncertainty matters when interpreting the comparison.

At launch, Grok 4.6 was available in Cursor and Grok Build, with a temporary increased usage allowance advertised for the first week. I've been using access included in my X subscription to build small games and work on T3 Code's Grok integration. Availability, subscription benefits and prices are specific to that time and can change.

The announcement describes supplemental training with curated model-generated reasoning and engineering data, followed by supervised fine-tuning and agentic reinforcement learning. It mentions tasks across coding, knowledge work and specialized environments. The company says it observed more self-testing on long runs; I didn't consistently see that in my game experiments.

The release also describes expanded safety evaluation. To try a practical task, I ask the model for a security audit of Lakebed and whether the project is ready to launch. While it runs, I inspect the vendor's comparison table, where different benchmarks put the models in different orders.

Artificial Analysis reports a five-point index gain over Grok 4.5 and places 4.6 near other leading models on that index. Theo also mentions a forecast about a future 4.7 release, but that was a prediction at recording time, not a confirmed result. Benchmarks, launch dates and rankings should be read as a snapshot.

The pricing shown was $2 per million input tokens and $6 per million output tokens, with an estimated $0.84 per task in the particular Artificial Analysis evaluation. That task cost is a benchmark estimate, not a subscription price or a guarantee for another workload. The chart shows about $0.36 for Grok 4.5 and $0.84 for 4.6 in that test.

Although the headline input and output rates were unchanged, the task cost rose in the displayed comparison. I noticed higher token use and slower completion in my own tests: 4.5 often felt unusually fast, while 4.6 more often felt like a task I would send away and return to later. Token usage, cache charges and speed all affect practical cost.

The model card shown lists a 500,000-token context window. The pricing screenshot lists cached input at $0.50 per million tokens for 4.6 versus $0.30 for 4.5, even though my spoken figures differ. These are recording-time figures; actual costs depend on the provider, cache behavior and workload.

Next I look at generated interface designs. I want to see whether a different model produces a different visual sensibility. The examples I show without a design skill feel inconsistent or generic to me: noisy backgrounds, too many cards and familiar template-like layouts.

Adding a design skill improves some examples, though others still don't appeal to me. I prefer the comparison designs from Fable and other models in this sample. This is a subjective assessment of selected outputs, not a controlled design benchmark or a guarantee about every prompt.

I also ask models to rebuild Fish Slop, an aquarium game, using the older codebase as a reference. It's a useful personal test because a game combines interactions, timing, visuals and multiple systems. In Grok's 2D version, I find the proportions, controls, selection behavior and pace unsatisfying.

The first 3D attempt opens to a black screen. I send the model a screenshot and ask it to fix the problem, which also lets me try the image display in Grok Build's CLI. It then renders a scene, but the controls and object placement are still wrong in the version I play.

I compare that result with other models' 3D attempts. They have flaws too, but in my examples they reach a more functional scene and better fish models. These are a handful of individual runs, so they illustrate my experience with this task rather than establishing a universal ranking.

The real-code work is more promising. The Lakebed audit finds a previous audit in Git history and produces a list of launch concerns, including identity handling and production isolation. I think it does a decent job, although it misses deeper issues. An agent's audit is a starting point for review, not proof that a system is secure.

I ask Grok to examine T3 Code's Cursor integration and a possible migration from an older ACP adapter to the Cursor SDK. The report identifies several issues that match problems we've encountered, alongside tradeoffs around features and authentication. Those are the model's findings in this particular investigation, not an independent verification of the SDK's current capabilities.

I run into an integration problem of my own: the client disconnects during plan approval and the plan isn't visible where I expect it. That is frustrating and shows that the surrounding harness and UI matter alongside the model. I need to improve how T3 Code handles Grok's events and plan mode.

In another task, I ask about gaps in T3 Code's Grok Build implementation. The model makes a plan, responds to feedback and produces a pull request; I ask it to follow the review. Some events collapse awkwardly in the interface, but the long-running sequence follows my instructions reasonably well in this example.

I then ask it to inspect my own session history for additional event-handling gaps and create a separate stacked pull request. This requires keeping the earlier change, the new investigation and project-specific instructions in context. I found Grok 4.5 surprisingly good at stitching multi-step work together, so this is a capability I care about in 4.6.

I sketch a rough personal scorecard for cost, intelligence, speed, thoroughness and orchestration. Fable feels strongest to me on intelligence and orchestration, while Sol is particularly thorough and Grok 4.5 stood out for speed and cost. These numbers are my informal impressions, not standardized measurements.

For 4.6, I see better intelligence, some improvement in thoroughness and competent subagent use, but lower marks for speed and cost than 4.5. It still misses things. Because speed and low cost were the qualities that made 4.5 distinctive for me, losing some of that advantage changes how attractive the upgrade feels.

Overall, Grok 4.6 isn't my favorite model and I don't expect to use it heavily immediately after this review. I'm interested in what a later release might do, but that is a hope rather than a measured result. More capable competitors and lower costs would benefit the ecosystem, so I'll keep watching.