July 2026 compressed two related builder decisions into one stack question: a stronger coding-first model (Grok 4.5) and an inspectable agent harness (Grok Build) that is now open source. I care less about keynote adjectives and more about what changes in an agent loop I would actually ship.

Reader promise: You will leave with a clear split between the model (Grok 4.5) and the harness (Grok Build), plus a routing checklist for when each belongs in your agent loop.

Fast Context

Grok 4.5 and Grok Build Terminal Agent Architecture
Figure 2.0 — Grok 4.5 model integrated with Grok Build terminal agent loop via Agent Client Protocol (ACP) for multi-file AST diffing and autonomous terminal execution.

Grok 4.5 is xAI's frontier model (SpaceXAI branding in current docs) positioned for coding, agentic tasks, and knowledge work. Official docs list model id grok-4.5, knowledge cutoff February 1, 2026, standard API pricing around $2 / 1M input and $6 / 1M output for prompts under 200k tokens (higher tier at ≥200k), and tools such as function calling, web search, X search, and code execution. Context window is documented at 500,000 tokens. It is available on the xAI API, as the default model behind Grok Build, inside Cursor, and through model gateways including OpenRouter. Region and product availability can lag (including EU AI Act constraints at launch)—check the console for your account before you assume global default status.

Cursor describes joint training with xAI and positions Grok 4.5 for long-horizon, tool-heavy work—not only tab completion. Treat CursorBench and similar vendor benches carefully: Cursor has disclosed that an earlier snapshot of their codebase was accidentally included in training for some evaluations and is being cleaned up for future models. That honesty is useful. It is also a reminder that vendor benches are product artifacts, not gospel.

Grok Build is the coding agent harness and TUI. As of July 2026 it is open-sourced at xai-org/grok-build (Apache-2.0). You can install a grok CLI, run an interactive fullscreen TUI, run headless prompts for scripts/CI, or speak Agent Client Protocol (ACP) for editor integration. The published source covers context assembly, tool dispatch, the terminal UI, and extension surfaces (skills, plugins, hooks, MCP servers, subagents). You can also point ~/.grok/config.toml at custom / local models for a local-first loop. Open-sourcing the harness does not open-source Grok 4.5 weights.

Official Grok Build overview Install the CLI/TUI, run headless, configure custom models, and call grok-4.5 on the API.

TL;DR

Treat Grok 4.5 as a strong coding-agent brain and Grok Build as a readable nervous system. Use the API when you already own an agent loop (IDE plugin, CI bot, portfolio assistant). Use the open harness when you want to learn or extend how context, tools, MCP, and ACP are wired. Do not confuse open-sourcing the harness with open-sourcing the model weights. Pin pricing, region availability, and cache behavior before you make Grok the default for production traffic.

What Actually Shines

1. Model + harness as separate products

Most teams only buy a model slug. Grok Build being open matters because agent quality is often harness quality: how diffs are shown, how tools are sandboxed, how plans are reviewed, how MCP servers are loaded, how headless JSON streams into CI. Reading that loop beats guessing from a chat demo.

2. Three run modes that match real engineering

Interactive TUI for deep work. Headless -p prompts for automation. ACP for embedding in editors. That triad is the modern coding-agent shape. If your product only exposes chat, you are missing the headless and protocol surfaces where agents become infrastructure.

3. Custom models and local-first config

config.toml custom models mean the harness is not locked to one vendor forever. That is the open-source win: the loop can outlive any single model release—including Grok 4.5 itself.

Where I would put Grok 4.5 / Grok Build first (fit, not hype)
Long-horizon coding agents in a harness 90
API drop-in for existing agent loops 78
Default for every UI chat turn 42
Sole eval source of truth 28

Scores are my product-fit judgment for portfolio and product engineering, not a model ranking.

What I Would Watch Closely

Bench contamination and marketing lag. Cursor's disclosure about training data and CursorBench is the right kind of footnote. Re-check evals after cleanups before you rewrite routing policy around a single score.

Region and policy gates. EU AI Act constraints can change who can select the model in first-party apps even when the API story looks global.

Harness != weights. Open Grok Build does not mean Grok 4.5 weights are open. Local-first still needs some model endpoint you control or pay for.

Tool blast radius. A TUI that can edit files and run shell commands is powerful. Production use needs allowlists, confirmations, and audit logs—especially headless in CI.

Architecture Pattern: Brain, Harness, Gateway

For AssistMe-style systems and coding agents, I keep three layers:

1. Brain — Grok 4.5 (or another primary) for hard multi-step coding / tool use. 2. Harness — Grok Build (or your own loop) for tools, MCP, ACP, permissions, and UX. 3. Gateway — OpenRouter or direct xAI for failover, metering, and slug stability.

The portfolio chatbot does not need to embed Grok Build's TUI. It needs the same ideas: bounded tools, visible state, fallbacks when the frontier model is unavailable or out of credits.

The Workflow I Would Use

1. Install Grok Build and run grok inspect on a real repo to see config, skills, MCP, and hooks. 2. Try one interactive task and one headless task (grok -p "..." --output-format streaming-json). 3. Call grok-4.5 once via the xAI API (or OpenRouter slug) from your existing agent loop. 4. Compare: same prompt in harness vs raw API—note tool use, latency, and failure modes. 5. Decide routing: Grok as primary for coding agents; keep a cheaper/free fallback for chat UX. 6. Document the data boundary: what files the agent may touch, what commands are blocked.

Things I Learned

  • Open-sourcing the agent harness is more actionable for builders than another closed chat skin.
  • Coding models should be evaluated inside a tool loop, not only on static completion prompts.
  • ACP and headless modes are how agents become products instead of toys.
  • Honest eval footnotes (data contamination, regional limits) should change your adoption timeline, not your Twitter take.

How I Would Apply This

On this portfolio and AssistMe stack:

  • Keep chat UX on a gateway with fallbacks; reserve Grok 4.5 for coding-heavy or long-horizon agent turns when credits allow.
  • Steal harness patterns (tool scopes, inspectability, MCP loading) even if the TUI never ships on the site.
  • Prefer explicit Voice Mode / agent states over pretending one model call is a full duplex coworker.
Source xai-org/grok-build Open-source coding agent harness and TUI (Apache-2.0).

Bottom Line

Grok 4.5 is a serious coding-agent brain. Grok Build being open is the lever: you can read, fork, and re-point the harness. Ship the split consciously—model, harness, gateway—or you will rebuild the same glue every release cycle.

Sources and further reading