Grok 4.5 Is on Writingmate: Testing SpaceXAI's New Model for Agentic Coding and Tool Use

Grok 4.5 landed in the Writingmate catalog on July 8, 2026, a day before xAI made it public, and the pitch is specific enough to actually test: a 1.5-trillion-parameter Mixture-of-Experts model trained in part on Cursor interaction data, built for agentic coding and tool use, with a claimed 83.3% on Terminal-Bench 2.1 and roughly a quarter of the output tokens Claude Opus 4.8 needs on comparable tasks.

That is a lot of specific numbers for a launch-day post, so I ran the same agentic test plan I used for Hy3 and Laguna XS 2.1: multi-step coding tasks, tool-calling reliability, and a straight token-count comparison against a model I already trust for agent loops. This is not a benchmark reprint. It is what happened when I gave Grok 4.5 real work and watched what it did with each turn.

Grok 4.5 is listed in the Writingmate model directory as x-ai/grok-4.5, grouped under x-ai/grok-4.5-20260708, with a 500K-token context window and mandatory reasoning turned on by default. It comes from xAI, now folded into the SpaceXAI umbrella after this year's merger, and it is live to test today rather than waitlisted.

What's actually new in Grok 4.5

The headline architecture claim is scale: 1.5 trillion total parameters in a Mixture-of-Experts layout, which puts it in the same size class as the largest frontier models currently in the catalog. Scale alone does not make a coding model useful, so the more interesting detail is the training data. xAI says a meaningful slice of Grok 4.5's post-training came from Cursor interaction data, meaning real edit sequences, real diffs, and real accept/reject signals from developers working inside an IDE rather than static code snippets scraped from repositories.

That matters for agentic work specifically because IDE interaction data captures something benchmarks usually miss: the sequence of a plan, a partial edit, a test failure, and a correction. If the training signal actually reflects that loop, you would expect the model to handle multi-turn coding tasks more like a developer and less like a one-shot autocomplete engine. The Terminal-Bench 2.1 score of 83.3% is xAI's evidence for that claim, since Terminal-Bench specifically scores an agent's ability to complete real command-line and file-system tasks inside a sandboxed terminal, not just answer questions about code.

The second claim, roughly 25% of the output tokens Opus 4.8 needs on comparable tasks, is the one I actually cared about testing, because token efficiency is the difference between an agentic model you can run in a loop all day and one that burns your budget on the second retry.

Grok 4.5 specs at a glance

Field	Grok 4.5	Reader takeaway
Provider	xAI (SpaceXAI)	Same lineage as Grok 4 Fast, but positioned squarely at agentic coding this time.
Availability date	July 8, 2026 in the catalog; public launch July 9, 2026	Confirm the live model page before wiring it into a production agent loop.
Architecture	1.5T-parameter Mixture-of-Experts	Large enough to compete with the biggest frontier models already in the catalog.
Context window	500,000 tokens	Enough room for full repository context, logs, and multi-file diffs in one turn.
Input	Text, image, file	Good fit for screenshots, error captures, and file uploads alongside code.
Reasoning	Mandatory, default effort "high"	You cannot fully disable reasoning; budget for it in latency-sensitive loops.
Pricing (OpenRouter)	$2.00 / $6.00 per 1M input/output tokens	Cheaper per token than most Opus-class models, before you factor in token efficiency.

How I tested Grok 4.5 for agentic coding and tool use

I ran three passes through Grok 4.5 in the Writingmate model directory, keeping the task, tool contract, and acceptance criteria identical to the Hy3 and Laguna XS 2.1 test runs so the comparison actually meant something.

• Multi-step coding test: a real bug report with a stack trace, one relevant file, and a misleading symptom, asking for root cause, smallest patch, and a regression test.
• Tool-calling reliability test: a task requiring three sequential tool calls (search, read, write) with explicit argument schemas and a required fallback if a call returned an error.
• Token efficiency test: the same repository-planning prompt run against Grok 4.5 and against Claude Opus 4.8, counting output tokens for an equivalent-quality plan.
• Constraint-change test: a second-turn instruction that changed one requirement, checking whether the plan updated cleanly or the model ignored the change.

On the multi-step coding test, Grok 4.5 correctly isolated the root cause on the first pass and wrote a test that failed against the original code, which is the actual bar for a coding model rather than a plausible-sounding explanation. On tool-calling, it handled the sequential calls cleanly and, notably, asked one clarifying question when a tool argument was ambiguous rather than guessing, which is exactly the behavior you want in a loop you are not watching turn by turn.

The token efficiency claim held up directionally, though not exactly at the stated ratio. For the repository-planning prompt, Grok 4.5 produced a comparable plan in noticeably fewer output tokens than Opus 4.8, driven mostly by less restated context and fewer hedging paragraphs. It was not a precise 4x difference in my run, but the direction and the magnitude were both real, and that translates directly into cost and latency in a long agent loop.

For an agentic release like this, the real test is not a clever first answer. It's whether the model keeps tool arguments valid, keeps the plan state clean across turns, and doesn't quietly balloon its own output when the task gets harder.

Grok 4.5 vs. Opus 4.8 and other agentic models already in the catalog

Terminal-Bench 2.1 is designed to score exactly the kind of work Grok 4.5 is being positioned for: an agent completing real terminal and file-system tasks inside a sandbox, not answering a multiple-choice question about code. An 83.3% score there is a meaningful claim if it holds, but the number only matters in context against models already doing this job in production.

Model	Terminal-Bench 2.1 style claim	Context window	Output pricing (per 1M tokens)	Where it fits
Grok 4.5	83.3% (xAI claim)	500K	$6.00	Agentic coding, tool use, multi-step terminal tasks
Claude Opus 4.8	Comparable class, higher output tokens per task	1M	Higher than Grok 4.5	Long-context reasoning, careful review, high-stakes coding
Kimi K2.7 Code	Not directly comparable; coding-specific benchmarks	262K	$3.50	Repository-scale coding and refactors
Hy3	Not directly comparable; general agentic benchmarks	256K	Free/promotional	Lower-stakes agent loops and research decomposition

Watch a hands-on run through a terminal-agent task to see what this actually looks like outside of a benchmark chart:

The honest takeaway from that comparison: Grok 4.5 is not a strict upgrade over Opus 4.8, it's a different tradeoff. If your loop is bounded by cost and turn count, the token efficiency claim is the one that actually changes your math. If your loop needs the largest possible context window or the most conservative failure behavior on high-stakes code, Opus 4.8 still has the edge.

Where Grok 4.5 fits against your current agent stack

A tie is not a reason to switch. Run the same task, tool contract, and acceptance criteria you already use, and only move Grok 4.5 into your default stack when it wins on something concrete: fewer output tokens for the same plan quality, cleaner tool-call arguments, or a correction that your current model missed.

Open the Writingmate comparison page and paste in a real task from your own backlog rather than a demo prompt. A repeatable comparison URL beats a vague instruction to "try another model," because you can rerun it every time a new agentic release shows up in the Writingmate models catalog.

Best first use cases for Grok 4.5

• Multi-step coding tasks where the plan, patch, and test all need to stay consistent across turns
• Tool-calling workflows with explicit argument schemas and a required fallback path
• Cost-sensitive agent loops where output token count directly affects your bill
• Terminal and file-system automation tasks similar to what Terminal-Bench 2.1 measures

I would not yet trust it unattended on irreversible production changes or high-stakes code review with no human checkpoint, the same caution I would apply to any model on launch week. Stage the rollout: drafts and planning first, then move it into higher-risk loops only after it beats your current default on your own prompts more than once.

What the Cursor training data claim does and doesn't mean

It's worth being precise about what "trained on Cursor interaction data" actually implies, because it's easy to over-read. It does not mean Grok 4.5 has access to your codebase, your Cursor sessions, or any private repository data. It means xAI's post-training pipeline incorporated aggregated interaction patterns, the kind of edit-propose-test-correct sequences that happen thousands of times a day inside an IDE, as training signal for how an agent should behave across turns.

That distinction matters for the test plan. A model trained mostly on static code (function in, function out) tends to answer coding questions well but struggles with the parts of agentic work that aren't really about code at all: deciding when to ask a clarifying question, when to stop and run a test before continuing, and when a plan needs to be revised rather than defended. My constraint-change test was designed specifically to probe that. I gave Grok 4.5 a repository-planning task, let it produce a three-step plan, then told it in the next turn that one of the constraints had changed, a permissions requirement that made step two impossible as written.

Grok 4.5 rewrote step two and flagged that the change also affected the acceptance criteria for step three, without being asked to check that. That's the specific behavior IDE-derived training data should produce if the claim is real, and it's a more useful signal than the Terminal-Bench number by itself, because it's the failure mode that actually costs time in a real agent loop: a model that updates the letter of an instruction but misses the downstream consequence.

A practical checklist before you promote Grok 4.5 into daily use

Before I move any new agentic release out of "testing" and into "default," I run it through the same five checks regardless of which company shipped it. First, does it follow the exact output format I asked for, including tool-call argument schemas, without extra narration wrapped around them. Second, does it use the source material I gave it instead of quietly paraphrasing the prompt back at me. Third, does it say what it's uncertain about rather than filling gaps with a confident guess. Fourth, does a second pass actually improve on the first, or does asking for a revision just produce a longer version of the same answer. Fifth, is it worth the price difference against the model already doing this job.

Grok 4.5 passed the first three cleanly in my runs. The fourth was the most interesting: when I asked it to critique its own plan and produce a smaller version keeping only the parts I'd actually use, it cut roughly a third of the original output while keeping every constraint intact, which is a good sign for anyone running it in a loop where output length is a real cost. On the fifth check, price, it's cheaper per token than Opus 4.8 on the OpenRouter price sheet, and if the token efficiency claim holds across your own workload, the effective cost gap is larger than the sticker price suggests.

None of that means you should swap your default coding model this week. It means Grok 4.5 has cleared the bar to be worth a real head-to-head on your own backlog, which is a higher bar than most launch-week releases clear.

Bottom line on Grok 4.5

Grok 4.5 earns a real spot in an agentic coding stack, not because the 1.5T-parameter number is impressive on its own, but because the tool-calling behavior and token efficiency held up on tasks that actually resemble a working agent loop. It is not a clean replacement for Opus 4.8 on every job, but for cost-bounded, multi-step coding and tool-use loops, it is worth putting head-to-head against whatever you are running today.