Grok 4.5: not the benchmark rank, the cost per completed task

On 16 July, SpaceXAI introduced Grok 4.5, by its own account the company’s strongest model, built for coding, agentic tasks, and knowledge work. The most telling numbers are not the benchmark points. On SWE-Bench Pro, Grok 4.5 scores 64.7%, below Opus 4.8 (max) at 69.2% and well below Fable (max) at 80.4%. For the same tasks, however, it needs 4.2 times fewer output tokens. Which puts a second question next to “which model is better”, one that often weighs more in agent operations: what does a completed task cost?

What is Grok 4.5?

SpaceXAI puts the price at 2 US dollars per million input tokens and 6 US dollars per million output tokens, with throughput around 80 tokens per second. On SWE-Bench Pro the model reaches 64.7% and spends 15,954 output tokens per task on average, against 67,020 for Opus 4.8 (max). Grok 4.5 was trained alongside Cursor, where it is available on all plans, and it is now the default model in Grok Build.

The picture across benchmarks is mixed, and that is part of the story. On SWE Marathon, Grok 4.5 leads with 29.0% ahead of Opus 4.8 (max) at 26.0% and Fable (max) at 24.0%. On Terminal Bench 2.1 it sits at 83.3%, essentially level with GPT 5.5 xhigh. On DeepSWE 1.1 it falls behind Opus 4.8 (max) at 53%. Quote a single row from that table and you can support almost any thesis with it.

Why token efficiency is an axis of its own

A benchmark score measures how often a model gets there. It says nothing about how much it burns along the way. In a chat that hardly matters, in an agent it does. An agent that reads, writes, tests, and corrects for hours generates its cost in the volume of output tokens, not in the elegance of a single reply. A factor of four on that axis is not a side detail. It changes which runs you can afford at all, how often you retry a task, and whether an overnight batch run is an option or an invoice.

The axes point in different directions here. Grok 4.5 is cheaper per token and leaner in consumption, but on SWE-Bench Pro it gets there less often. The gap of 4.5 points to Opus 4.8 is not a rounding error: across a hundred tasks that is about four and a half cases that do not go through. A failed attempt costs tokens too, and it costs you time checking it. Whether the saving survives depends exactly on how expensive a failure is in your workflow.

Where the leanness comes from

SpaceXAI names per-token intelligence as the explicit focus of its reinforcement learning. Training ran across hundreds of thousands of tasks, centred on multi-step software engineering, graded automatically and by models. The training stack is built to be highly asynchronous, so agentic rollouts can run for hours while learning continues. That is a plausible explanation for the token advantage, and it is also the limit of the claim: the optimisation targeted a task profile, not your repository. How well it fits is decided by your code, not by the announcement.

How do you check the maths for yourself?

Take a handful of real tasks from your project, ones with a clear acceptance condition, a green test for instance. Run them with both models and record three things: tokens consumed, number of attempts until the test passes, and the time you spent reviewing. Only that third value makes the calculation honest. A model that lands less often shifts work into your review, and review time appears on no API invoice.

After that, the choice can also be split. For wide, mechanical stretches with an easily checked result, much speaks for the lean model; for the delicate parts, for the accurate one. SpaceXAI had already moved in that direction when it pulled the loop into the tool with /goal in Grok Build. That the default there is now a model optimised for the cost of that loop is the consistent next step. The line stays the same as in agentic engineering: reliability comes from the architecture around the model. The model decides what a run costs. What it was worth is still your call.

Sources

• SpaceXAI: Grok 4.5