Can Grok 4.5 deliver an Opus-class agentic coding result without the premium frontier price tag? I ran Ship-Bench against Grok 4.5 using Grok Build to find out, looking at whether xAI’s latest model could hold up across a full SDLC workflow rather than just a narrow coding benchmark.
Hypothesis: Grok 4.5 would become a new benchmark for price/performance among domestic models and give overseas models real competition, especially for teams that care about strong coding experience without paying top-tier reasoning-model prices.
Key Insights
Grok 4.5 made a real case as a price/performance contender: it averaged 91.96 across the five Ship-Bench roles and passed all 5/5 phases on its first recorded run.
The strongest work showed up early, with Architect at 97, UX at 94.5, and Planner at 93.9, which meant the handoffs into implementation were consistently strong.
The app actually worked, with the Developer evaluation verifying browse, search, edit, and local-run flows through headless Chromium across multiple viewports and database states.
Reviewer was the weakest phase, not because the app failed, but because the QA evidence was leaner and the evaluation flagged missing performance measurements, missing dependency vulnerability scanning, and a required output-template miss.
Cost in this run cannot be measured honestly, because the run was done on Grok’s free tier with no token visibility, but that same free-tier setup also stretched the run over more than a week due to daily limits rather than model instability.
Setup
This run used the same Ship-Bench structure as the rest of the series, but the runtime details differed from my more typical Windows setup, which matters because harness behavior and environment friction can shape the practical outcome of an agentic workflow.
Environment
| Item |
Value |
| Machine |
Older Mac Mini |
| Runtime |
macOS Sequoia, Node v25.4.0 |
| Ship-Bench repo |
ship-bench |
| Benchmark task |
Simplified knowledge base app |
Run configuration
| Item |
Grok 4.5 run |
| Harness |
Grok Build v0.2.103 |
| Model |
Grok 4.5 |
| Backend |
Free Grok tier |
| Run repo |
evals_june2026_grok_4.5 |
Judge configuration
| Item |
Value |
| Judge harness |
Claude Code 2.1.220 |
| Judge model |
Opus 5 Medium |
| Evaluation mode |
LLM judge plus independent benchmark scoring across all five phases |
One practical caveat belongs in setup rather than in scoring: this run used the free Grok tier, so the workflow took over a week to complete because of daily limits, which is an operator-experience constraint but not evidence of model failure.
Ship-Bench Context
Ship-Bench evaluates models across five SDLC roles: Architect, UX Designer, Planner, Developer, and Reviewer. Each phase produces artifacts that feed the next stage, which makes the benchmark useful not only for measuring isolated output quality, but also for testing whether a model can maintain continuity across a realistic handoff-driven workflow.
This run used the standard simplified knowledge base app task. That task is large enough to expose meaningful differences in architecture, planning, implementation, and QA without becoming too unconstrained to compare cleanly across runs. Because Architect, UX, and Planner all passed their gates, no canonical rerun was needed for any downstream phase in this run.
Overall Results
| Metric |
Grok 4.5 |
| Architect |
97.00 |
| UX Designer |
94.50 |
| Planner |
93.90 |
| Developer |
90.58 |
| Reviewer |
83.75 |
| Average score |
91.96 |
| Passes |
5/5 |
The table tells a pretty clean story: Grok 4.5 was strongest in the thinking-heavy setup roles, stayed very solid through implementation, and dipped most in review completeness rather than in functional delivery. A first-look run that clears all five phases with a 91.96 average is a serious result, especially for a model being evaluated through its native coding harness rather than a hand-tuned comparison setup.
Architect
The architect stage tests whether the model can turn the product brief into a concrete technical plan with clear decisions and minimal unresolved ambiguity.
LLM judge summary: The architecture spec was implementation-ready, with explicit artifacts for the Prisma schema, FTS5 search strategy, client singleton, Zod schema, Playwright config, and scripts block, plus 16 pinned dependencies that the evaluator judged current and active at the time of review. The main deductions came from two deprecated API choices in the samples, but they were not severe enough to threaten the phase result.
Human notes: Grok created a reasonable architecture specification with the key decisions needed to guide the rest of the phases, and the dependency versions were close enough given the elapsed time between implementation and article writeup. It may have been a little too specific in places, though, which can create tension for downstream coding agents that would otherwise benefit from a bit more room to operate.
Practical takeaway: This was a strong architecture output and a solid start, even if it did not quite reach the bar I’ve seen from the very best architecture runs so far.
UX Designer
The UX stage evaluates whether the design direction is specific enough to guide implementation, including flows, states, layout decisions, and interaction details.
LLM judge summary: The evaluator found the UX spec highly implementable, with a token block, copy deck, component-to-file mapping, and explicit “do not invent” constraints, while deducting for the lack of rendered visuals, a de-prioritized mobile layer, and a few authoring defects left in the published document.
Human notes: The wireflows were especially strong, and the text wireframes were detailed enough that the document felt relatively complete as a handoff artifact. Grok did make a few judgment calls in what it deprioritized, but overall this felt like one of the better design specs in the benchmark series so far.
Practical takeaway: Grok 4.5’s UX work was near the top of the pack because it was genuinely useful to build from, not just detailed for its own sake.
Planner
The planner stage tests whether the model can convert the prior artifacts into an executable delivery sequence with sensible task sizing and dependency order.
LLM judge summary: The planner cleared the right-sizing gate with 83.3% good chunks, and the evaluator liked that each iteration ended in a runnable state with explicit acceptance criteria and verification commands. The main deductions were that the plan stretched to six iterations instead of the rubric’s nominal 3–5 band and included five brief features instead of the intended three-feature MVP scope.
Human notes: The vertical-slice orientation was a real plus, and six iterations felt fair given how the features were sliced. The familiar weakness was that E2E testing still got pushed to the end instead of being treated as an integrated discipline throughout the plan, but overall this was better than many of the other benchmark runs.
Practical takeaway: Grok 4.5 planned like a capable delivery lead: mostly sensible, execution-friendly, and stronger than average, even if it still followed the common benchmark habit of deferring end-to-end testing.
Developer
The developer stage measures whether the model can implement the assigned backlog into a working MVP while staying aligned to the prior artifacts.
LLM judge summary: The Developer phase shipped a working MVP and passed all four required flows, with the evaluator verifying 73 checks across viewports and database states, including pagination, search sync after writes, optimistic concurrency, sanitization, and error-state behavior. Deductions came from a slightly outdated Next.js version, missing coverage instrumentation, and a pair of dead helper functions left in the implementation.
Human notes: The coding runs were relatively smooth, and the biggest practical challenge was the free tier rather than Grok or Grok Build itself. Grok felt fast, handled E2E work without obvious struggle, and did not require steering or manual rescue during the implementation loop.
Practical takeaway: Grok 4.5’s biggest practical strength may be that it felt easy to code with, which matters a lot in real iterative agentic work.
Reviewer
The reviewer stage closes the loop by checking whether the built MVP actually satisfies the brief, the specs, and the implementation plan.
LLM judge summary: The QA report reproduced 33 interactive checks, covered all MVP flows, and reached a “ship with conditions” release recommendation that the evaluator considered directionally correct. The larger scoring losses came from not measuring performance latencies, not running a dependency vulnerability scan despite surfaced advisories, and missing the required BENCHMARK VERDICT block in the report template.
Human notes: This phase felt weaker than the earlier ones, and the report itself seemed leaner than reviewer outputs from some other runs. The presence of several “manual (passed)” items lowered confidence enough that the evaluator’s conclusions felt more trustworthy than the raw reviewer artifact on its own.
Practical takeaway: Grok 4.5’s reviewer was good enough to pass, but this was the least confidence-inspiring phase of the run.
Token and Cost Analysis
The economics matter here because the whole point of the article is whether Grok 4.5 delivers strong results given its retail price. In this specific run, however, token data was unavailable because the workflow was completed on the free Grok tier, so no honest realized-cost estimate can be produced from the run artifacts.
| Metric |
Grok 4.5 |
| Token usage |
Unavailable on free tier |
| Estimated run cost |
Unavailable |
| Practical cost caveat |
Free tier extended the run over more than a week because of daily limits |
That means the price/performance argument here is qualitative rather than metered. The result was strong enough to make Grok 4.5 look compelling on value grounds, but this article cannot claim a real cost-per-point figure without data the harness never exposed.
App Comparison
The screenshot set for this run includes article list, article detail, and edit views, which is enough for a basic visual check even if it is not a full UX comparison set.
Screenshots
Subjective UX review
Grok 4.5 UI
Grok 4.5 Article View
Grok 4.5 Editor
Subjectively, the delivered app looks coherent and complete enough for the benchmark’s calm, information-first knowledge-base target. The visual system appears consistent, the layout is clean, and the overall result looks like a real working internal app rather than a broken prototype. The edit page could use a little polish, however.
Interpretation
Grok 4.5 and Grok Build sit in a very interesting place in the frontier landscape. As model sizes inflate, thinking and reasoning levels burn more tokens, and pricing goes up, Grok 4.5 offers a very compelling alternative for teams that want strong coding performance and a credible end-to-end SDLC result without paying premium-model prices.
That is especially relevant for organizations that cannot or do not want to depend on foreign LLMs. Based on this run, I would still consider splurging on a larger model for the highest-stakes upfront architecture, design, and planning work, but Grok 4.5 looks like a very strong option to carry the actual iterative coding loop, where operator experience, speed, and recovery matter just as much as raw benchmark intelligence.
Verdict
This run showed that Grok 4.5 is absolutely worth trying for an end-to-end agentic SDLC workflow, especially if price/performance and a strong coding experience matter more than squeezing out the last bit of reasoning quality.
If the goal is the strongest possible upfront thinking work, I would still consider a larger premium model for the early phases and then rely on Grok 4.5 for the iterative coding work, where it felt fast, capable, and operationally practical.
What's Next?
What should the next Ship-Bench matchup test?
Are you more interested in seeing how far the large frontier models have come?
Or would you rather explore how cost-effective we can get with open-weight and other more economical models?
Is the more interesting question raw capability, practical coding experience, or total price/performance across the full workflow?
That feedback helps shape the next run.
