Cursor and xAI shipped Grok 4.5 on 8 July 2026, and the interesting sentence in the announcement is not in the benchmark table. Training, they write, “included trillions of tokens of Cursor data which capture a wide-range of user interactions with codebases and software tools.” Repositories were never the point. Interactions were. The model learned the trajectory — how a developer investigates, fails, backtracks, verifies — rather than only the finished file.

Read as a systems diagram, that is a new edge in the graph. The IDE stopped being a client of the model and became an upstream data source for it. Cursor’s own footnote that “an earlier snapshot of the Cursor codebase was accidentally included in training” — their words, in their CursorBench caveat — is the honest tell that this pipeline is young and its boundaries are not yet crisp.

The topology behind the release

Grok 4.5 is a mixture-of-experts model, priced at $2 per million input tokens and $6 per million output, with a fast variant at $4/M in and $18/M out. Cursor is doubling included usage for the first week and shipping the model across desktop, web, iOS, CLI and the SDK. Composer 2.5, the coding specialist, stays in the pool as a smaller weight class. So the product surface now offers two sizes, and the deliberate widening of the data mix — high-quality STEM tasks, research papers, “other knowledge work,” per the release — is a bet that generalist reasoning beats a narrow code head on long-running work.

The mechanism worth naming is the environment factory. Cursor describes “a distributed agent system to construct these environments at scale,” where engineers specify a problem and a verifier, and large groups of agents build, test and refine each task. Some of those environments, they claim, “would have taken teams of hundreds of engineers months to build.” That is a closed loop: model N builds the training substrate for model N+1. TNW’s launch coverage framed the release as xAI’s first model aimed beyond software engineering; the loop is what makes that claim structurally plausible rather than marketing.

←TODAY: Your keystrokes in an AI IDE are a training input, priced at $2/M in and $6/M out on the way back to you.
→3012: The offices that survived were the ones that knew which of their tools held their process, not just their files.
Fulcrum: A dependency you cannot see is a dependency you cannot price — and the IDE just moved from tool to supplier.

Where the queue builds

An architecture office running Grasshopper scripts, IFC exports and a Python glue layer now carries a plausible new dependency: a proprietary model whose quality partly derives from telemetry of how people like you work. That is not automatically bad. It is unpriced. Ask three questions of any AI-assisted stack — what leaves the machine, what is retained, what happens on the day the vendor’s endpoint returns 503. Offices that have been through a tooling migration report the same failure mode: the thing they could not replace was never the software, it was the undocumented workflow that had quietly moved into it.

Atelier: The Büro question this release forces is not procurement but consent — what did the team agree to when it opened the IDE. A practice adopting agentic coding tools inherits a data-egress policy whether or not it ever wrote one. Monday move: open your AI IDE’s privacy setting and switch the project holding client geometry and tender data to a no-training / local-index mode, then write the one-line rule into your BEP so the next hire inherits the decision instead of re-making it.

Hack: Trace the real dependency graph of your own toolchain before a vendor traces it for you. Python’s importlib.metadata lists every third-party package your environment actually resolves — the live graph, not the diagram on the wall. Run it inside the interpreter that drives your Grasshopper-adjacent scripts or your IfcOpenShell chain, and count the names you did not expect. The one you cannot explain is your third single point of failure.

from importlib.metadata import distributions
deps = {d.metadata["Name"]: d.version for d in distributions()}
for name in sorted(deps):
    print(f"{name:30s} {deps[name]}")
print(f"-- {len(deps)} packages in the real graph")

The trade-off, plainly

Broadening the data mix buys generality and costs sharpness: Cursor is explicit that Composer 2.5 was trained as a coding specialist and that both weight classes will continue. So a generalist at $6/M output is a poor call for a repetitive IFC-parsing chore that a smaller model handles at a fraction of the spend. Meanwhile the new cybersecurity safeguards Cursor shipped alongside the launch are a quiet admission that a model good at “creatively using tools” is good at that in both directions.

PAZ’s position here is the boring one, and we will keep repeating it: build the parts you cannot afford to lose. That is why the PAZ Grasshopper↔Archicad Library exists as a first-party layer rather than a vendor plugin — the workflow stays legible when the model underneath changes. Pair it with an open exchange path (Speckle, Bonsai) and the model becomes swappable rather than load-bearing.

Trial Grok 4.5 during the doubled-usage week, benchmark it against Composer 2.5 on one real task from your own backlog, and write down the cost per completed task. Then draw the dependency graph — the real one, with the vendor endpoints on it — and hang it where the whole team can see the edges.

Source: cursor.com