Grok 4.5 is now listed in xAI’s developer documentation as a model for coding, agentic tasks, and knowledge work. The release notes say it is available on the xAI API, priced at $2 per 1M input tokens and $6 per 1M output tokens, with configurable reasoning_effort values of low, medium, and high, defaulting to high. The documented model id is grok-4.5, and the xAI chat completions endpoint follows the OpenAI-compatible shape at https://api.x.ai/v1/chat/completions.
Source xAI Grok 4.5 developer overview
Source xAI release notes — July 8 Grok 4.5
That is enough to start a serious evaluation. It is not enough to move production coding agents.
A coding agent is not a chat window. It reads private repository context, edits files, calls tools, installs dependencies, writes pull requests, and sometimes runs destructive commands if the guardrails are loose. Changing its model changes its planning style, its tolerance for ambiguity, its tool-call rhythm, its cost curve, and its failure modes. A frontier model can be better on many tasks and still be worse for your exact automation loop.
This post is a field checklist for developers who already run coding agents and want to evaluate Grok 4.5 without turning the rollout into a belief exercise. It avoids benchmark arguments. Public benchmarks are useful for initial curiosity, but they do not answer the questions that matter in your repo: does the agent preserve your architecture, obey your command policy, write reviewable diffs, avoid unnecessary rewrites, and finish tasks inside your latency and token budget?
For the broader operating model behind this checklist, see /ai-agent-operations/, /developer-tools/, and /start-here/.
What Grok 4.5 changes—and what it does not prove
The practical news for developers is API availability. xAI documents Grok 4.5 as usable from the developer platform and release notes describe it for coding, agentic tasks, and knowledge work. The API path is familiar if your stack already supports OpenAI-style chat completions. The price listed in the release-note snippet is straightforward enough to model before the first experiment: $2 per 1M input tokens and $6 per 1M output tokens. The configurable reasoning_effort setting matters because coding agents often pay heavily for planning, tool-call narration, and repair loops.
Here is a minimal smoke request that keeps the surface area small. It proves connectivity and response shape. It does not prove coding-agent quality.
1curl https://api.x.ai/v1/chat/completions \
2 -H "Authorization: Bearer $XAI_API_KEY" \
3 -H "Content-Type: application/json" \
4 -d '{
5 "model": "grok-4.5",
6 "messages": [
7 {
8 "role": "system",
9 "content": "You are a concise senior software engineer. Answer with implementation risks first."
10 },
11 {
12 "role": "user",
13 "content": "Review this migration plan: move a Node service from callbacks to async/await. List the first five checks before editing files."
14 }
15 ],
16 "reasoning_effort": "medium"
17 }'
The response tells you whether your key works, whether your client can reach xAI, and whether your JSON shape is accepted. Stop there if this fails. Do not hide an API integration problem behind an agent framework problem.
What the smoke test does not tell you:
- whether Grok 4.5 will preserve your repository conventions;
- whether it will call tools in the order your harness expects;
- whether it will over-edit unrelated files;
- whether it handles partial test failures cleanly;
- whether it can recover from package-manager, type-checker, or linter errors;
- whether cost is stable under real context windows;
- whether
highreasoning is worth its extra latency for your class of tasks.
A model migration is only safe when you separate those questions and test them one by one. Treat the model as one replaceable component inside an agent system, not as a magic upgrade pasted over old assumptions.
Start with the contract your agents already rely on
Before you point a coding agent at Grok 4.5, write down the contract your current model satisfies. Most teams skip this because the contract is implicit in wrapper code, shell prompts, and reviewer habits. That makes migration messy: a new model behaves differently, and nobody can tell whether the difference is improvement, regression, or just taste.
At minimum, document five contracts.
First, the tool contract. Which commands can the agent run without asking? Which commands require confirmation? Which commands are banned? If your current agent knows never to run rm -rf, never to push directly to main, and always to use pnpm test instead of npm test, that is not model knowledge. It is an operating rule. Put it in the system prompt and test that it sticks.
Second, the diff contract. Good coding agents minimize unrelated churn. They do not reformat files unless asked. They do not change public APIs without naming the compatibility risk. They do not create helper abstractions just to look busy. The migration test should score diff shape, not only final test status.
Third, the verification contract. A task is not done when the model says it is done. It is done when the agent ran the relevant tests, captured the output, and reported remaining risk. The model must be comfortable saying, “I could not verify this because dependency installation failed,” instead of pretending.
Fourth, the context contract. How much repository context do you feed? Do you include architecture notes, issue text, package manifests, failing logs, and style guides? A model that performs well with a hand-curated prompt can degrade when dropped into an automated retrieval stack that sends stale or excessive context.
Fifth, the handoff contract. Your reviewer needs a clear summary: files changed, tests run, commands that failed, decisions made, and risks left open. A model that writes code but leaves weak handoff notes increases review time.
A simple policy file makes these contracts concrete:
1# .agent/model-migration-policy.yaml
2model_under_test: grok-4.5
3provider: xai
4api_endpoint: https://api.x.ai/v1/chat/completions
5reasoning_effort_default: medium
6
7allowed_commands:
8 - "npm test"
9 - "npm run lint"
10 - "pnpm test"
11 - "pytest"
12 - "go test ./..."
13 - "git diff --check"
14
15requires_confirmation:
16 - "database migrations against shared environments"
17 - "dependency major-version upgrades"
18 - "file deletion outside the requested task scope"
19 - "network calls that upload repository content"
20
21blocked_commands:
22 - "git push --force"
23 - "rm -rf /"
24 - "curl | sh"
25 - "writing secrets to logs"
26
27completion_report_required:
28 - files_changed
29 - tests_run
30 - test_output_summary
31 - unverified_assumptions
32 - rollback_notes
This file is not special. Use JSON, TOML, Markdown, or code comments if that fits your stack. The important part is that your migration harness can read the same rules for both the incumbent model and Grok 4.5.
Build a small migration harness before changing defaults
A migration harness is a repeatable way to run the same tasks against two or more models under the same constraints. It does not need to be fancy. It needs to be boring, versioned, and honest.
Create a task set from work your team already understands. Ten to twenty tasks are enough for a first pass. Include a mix of languages and failure types if your agents support multiple stacks. Keep the expected outcome written in human terms rather than exact patches, because two valid implementations can differ.
Example task inventory:
1# agent-evals/grok-4-5/tasks.toml
2[[task]]
3id = "ts-null-guard-001"
4repo = "services/billing-api"
5branch = "eval/ts-null-guard-001"
6prompt = "Fix the failing TypeScript test for missing customer email. Preserve the public API."
7verify = ["npm test -- --runInBand customer-email.test.ts", "npm run lint"]
8max_files_changed = 3
9risk = "low"
10
11[[task]]
12id = "py-regression-002"
13repo = "workers/invoice-parser"
14branch = "eval/py-regression-002"
15prompt = "Add a regression test for invoices with an empty tax_id field, then fix the parser."
16verify = ["pytest tests/test_invoice_parser.py", "ruff check ."]
17max_files_changed = 4
18risk = "medium"
19
20[[task]]
21id = "docs-config-003"
22repo = "platform/docs-site"
23branch = "eval/docs-config-003"
24prompt = "Update the deployment docs after the config key was renamed from site_id to project_id. Do not touch unrelated pages."
25verify = ["npm run build"]
26max_files_changed = 2
27risk = "low"
Run each task in a clean branch or disposable worktree. Keep the agent’s prompt fixed except for the model id and provider-specific fields. Save raw transcripts, tool calls, diffs, and command output. If privacy policy allows it, save token usage and latency by request.
A tiny Python runner can capture the metrics that matter before you integrate with a larger eval platform:
1# agent-evals/run_smoke_eval.py
2import json
3import subprocess
4import time
5from pathlib import Path
6
7TASKS = [
8 {
9 "id": "ts-null-guard-001",
10 "repo": "services/billing-api",
11 "verify": ["npm test -- --runInBand customer-email.test.ts", "npm run lint"],
12 },
13]
14
15
16def run(command: str, cwd: Path) -> dict:
17 started = time.time()
18 proc = subprocess.run(
19 command,
20 cwd=cwd,
21 shell=True,
22 text=True,
23 capture_output=True,
24 timeout=900,
25 )
26 return {
27 "command": command,
28 "exit_code": proc.returncode,
29 "seconds": round(time.time() - started, 2),
30 "stdout_tail": proc.stdout[-4000:],
31 "stderr_tail": proc.stderr[-4000:],
32 }
33
34
35def changed_files(cwd: Path) -> list[str]:
36 proc = subprocess.run(
37 "git diff --name-only",
38 cwd=cwd,
39 shell=True,
40 text=True,
41 capture_output=True,
42 check=False,
43 )
44 return [line for line in proc.stdout.splitlines() if line.strip()]
45
46
47results = []
48for task in TASKS:
49 repo = Path(task["repo"]).resolve()
50 checks = [run(command, repo) for command in task["verify"]]
51 results.append({
52 "task_id": task["id"],
53 "changed_files": changed_files(repo),
54 "checks": checks,
55 })
56
57Path("agent-evals/results").mkdir(parents=True, exist_ok=True)
58Path("agent-evals/results/latest.json").write_text(json.dumps(results, indent=2))
59print(json.dumps(results, indent=2))
This runner does not call the model. That is intentional. Keep model execution and verification separable. Most coding-agent wrappers already know how to run a prompt. What teams often lack is a consistent post-run audit.
Score each task across four dimensions:
- Correctness: Did the requested behavior change land? Did the relevant tests pass?
- Containment: Did the agent stay inside the expected files and scope?
- Operational discipline: Did it run the right commands and report failures honestly?
- Reviewability: Would a senior engineer understand the diff and the handoff in under ten minutes?
A migration earns attention when it wins or ties on correctness while improving cost, latency, reviewability, or recovery behavior. A model that passes tests by producing a sprawling rewrite is not an obvious upgrade.
Cost, latency, and reasoning effort deserve separate gates
The release-note pricing gives you a starting point for cost modeling: $2 per 1M input tokens and $6 per 1M output tokens. Use the live billing page for final numbers before procurement, because pricing pages can change. For planning, treat output tokens as the expensive side and focus on reducing unnecessary narration, repeated file dumps, and long self-analysis in final reports.
reasoning_effort deserves its own experiment. Do not assume high is always the right default just because it is the documented default. For coding agents, some tasks need careful planning; others need fast, disciplined edits. If a low-risk docs task takes twice as long because the model is thinking deeply about a two-line wording change, the default is wrong for that task class.
Use a routing table instead of one global setting:
1{
2 "model": "grok-4.5",
3 "routing": [
4 {
5 "task_type": "docs_only",
6 "reasoning_effort": "low",
7 "max_output_tokens": 1800,
8 "requires_full_test_suite": false
9 },
10 {
11 "task_type": "single_file_bugfix",
12 "reasoning_effort": "medium",
13 "max_output_tokens": 3500,
14 "requires_full_test_suite": false
15 },
16 {
17 "task_type": "cross_module_refactor",
18 "reasoning_effort": "high",
19 "max_output_tokens": 7000,
20 "requires_full_test_suite": true
21 }
22 ]
23}
Track latency in wall-clock time, not only API time. Developers experience the full loop: prompt construction, model response, tool execution, test failures, repair attempts, and final report. A slower first answer can be acceptable if it reduces repair loops. A faster first answer can be worse if it produces brittle patches.
Your budget gate should include:
- median and p90 total task time;
- input and output tokens per successful task;
- repair attempts per task;
- tool calls per task;
- number of failed runs that required human rescue;
- review minutes per accepted pull request;
- rollback frequency after merge.
Do not evaluate cost without quality. A cheap run that creates cleanup work is expensive. Do not evaluate quality without cost. A beautiful patch that consumes the budget for ten routine fixes is not the right default.
What you should do Monday morning
If you want a useful Monday morning plan, keep it small enough that a busy engineering team can actually do it before standup ends.
08:30 — Freeze the current baseline. Pick the incumbent model and agent configuration. Save the prompts, model id, command policy, retrieval settings, and tool permissions. If you cannot reproduce the old setup, you cannot measure the new one.
09:00 — Run five tasks on the incumbent model. Use the eval set described above. Save transcripts, diffs, test output, token usage, and elapsed time. Do not cherry-pick the tasks after seeing results.
10:30 — Run the same five tasks on Grok 4.5. Keep the harness identical except for provider and model settings. Start with reasoning_effort: medium unless your current agent tasks are mostly deep refactors. Then run one or two tasks at low and high to see whether effort changes behavior in a way your team cares about.
12:00 — Review diffs, not summaries. Model-written summaries can be useful, but they are not evidence. Look at the patch. Ask whether the agent changed the right files, preserved style, kept tests narrow, and reported uncertainty accurately.
14:00 — Classify failures. Use practical buckets: API integration failure, prompt-following failure, tool-use failure, code-quality failure, test-repair failure, cost failure, or handoff failure. Different buckets have different fixes. Do not blame the model for a broken wrapper, and do not blame the wrapper for a model that ignores clear rules.
15:00 — Choose one limited production lane. If Grok 4.5 passes the initial gate, route one low-risk class of work to it: docs-only fixes, test generation for already failing cases, dependency PR explanation, or small bugfixes in a non-critical service. Keep automatic merge disabled.
Friday — Decide with evidence. Promote only if the lane shows stable acceptance rate, contained diffs, understandable handoffs, and acceptable cost. Otherwise keep it in evaluation and update the harness.
A good first rollout is not dramatic. It creates enough signal that the next decision is easier.
Verification checklist before the switch
Use this checklist before moving coding-agent defaults to Grok 4.5 or any new frontier model.
API and provider readiness
- The xAI API key is stored in the same secret manager pattern as other model providers.
- The endpoint is configured as
https://api.x.ai/v1/chat/completionsfor chat completions clients. - The model id is set to
grok-4.5in a provider-specific config, not hardcoded across the codebase. - Timeouts and retry rules are explicit. Long reasoning tasks need longer timeouts, but retries must not duplicate destructive tool calls.
- Logs capture request ids or equivalent provider metadata when available, without leaking prompts or secrets beyond policy.
Prompt and tool policy
- The system prompt states allowed commands, blocked commands, and confirmation-required actions.
- The agent is instructed to report verification output, not just success claims.
- The prompt tells the model to minimize unrelated diffs.
- The wrapper enforces the policy in code; the prompt is not the only guardrail.
A concise migration prompt can look like this:
1You are operating as a coding agent inside a repository sandbox.
2
3Rules:
41. Change only files required for the user's task.
52. Before editing, identify the smallest likely files to inspect.
63. Do not run destructive commands or network install scripts.
74. Prefer existing project scripts over invented commands.
85. After editing, run the narrowest relevant test first, then a broader check if available.
96. If verification fails because of environment setup, report the exact command and error.
107. Final response must include: files changed, tests run, remaining risks, and rollback notes.
11
12Task:
13Fix the failing regression described by the issue. Preserve public APIs unless the issue explicitly requires a breaking change.
Repository behavior
- The model has passed tasks in the languages and frameworks you actually use.
- It respects formatting and lint rules without full-file churn.
- It handles monorepo package boundaries correctly.
- It does not invent non-existent scripts when
package.json,pyproject.toml,go.mod, or equivalent files provide real commands. - It produces reviewable diffs for both small fixes and medium refactors.
Verification behavior
- It runs tests that match the change.
- It reports failed tests honestly.
- It does not claim to have run commands that are absent from the transcript.
- It can stop and ask for human input when credentials, migrations, or external systems are required.
Cost and latency
- You have measured token usage on real tasks.
- You have compared
low,medium, andhighreasoning effort for at least two task classes. - You have p90 task time, not only average response time.
- You know the cost per accepted PR, not only cost per API call.
Rollback
- The agent config can return to the previous model with one deploy or feature-flag change.
- Open PRs created by the experiment are labeled.
- Reviewers know which model produced each PR.
- A failed rollout does not strand half-completed branches without owners.
The most important item is the boring one: rollback. A model migration without rollback is not an evaluation. It is a bet.
Further reading
Start with the official sources, then test in your own environment:
- xAI Grok 4.5 developer documentation
- xAI developer release notes
- xAI reasoning controls documentation
- Internal operating guides: /ai-agent-operations/, /developer-tools/, and /start-here/.
A practical reading order for a team lead is: official API docs first, pricing and rate-limit pages second, your existing agent wrapper code third, and public benchmark commentary last. Benchmarks can suggest what to inspect. They cannot replace repository-level verification.
The conclusion is simple: Grok 4.5 is worth evaluating if you run coding agents, because the documented API availability, model id, pricing, and reasoning-effort controls give developers enough surface area to build a real test. The safe path is not to ask whether it is generally smarter. The safe path is to ask whether it completes your work, inside your rules, with diffs your reviewers trust.