Use Grok 4.7 on Amazon Bedrock to create long-horizon agents

SpaceXAI's Grok 4.7 is now available on Amazon Bedrock, and for teams building tool-calling agents, the most practical question is not whether the model is smarter than Grok 4.6, but which reasoning effort level to run per request. A recent agent evaluation put all four levels to the test across 72 runs and three search-heavy tasks, and the results offer a concrete trade-off: at `xhigh`, the agent answered all 18 runs correctly; at `low`, it answered 15 of 18 while using roughly one-eighth of the output tokens.

That gap matters because reasoning tokens are billed as output tokens. Every level of deliberation draws down `max_completion_tokens` before any answer text is produced, so choosing an effort level is a direct cost decision, not just a quality dial.

What SpaceXAI says about Grok 4.7

According to SpaceXAI, Grok 4.7 uses a larger base model than Grok 4.6 and was trained with a longer reinforcement learning run on a harder mix of tasks, weighted toward problems that take many hours to complete. The company reports the model is better at verifying its own work and at managing longer context.

The published benchmark results reflect that emphasis. The largest gains over Grok 4.6 appear in categories measuring sustained work rather than single-turn answers:

SpaceXAI lists a 500K token context window for Grok 4.7, with text and image input and text output. On Amazon Bedrock, the model supports configurable reasoning effort, tool calling, and structured output.

Accessing Grok 4.7 on Amazon Bedrock

Grok 4.7 runs on the `bedrock-runtime` endpoint through a cross-Region inference profile. Two profiles are available: `us.xai.grok-4.7` for US data residency requirements, and `global.xai.grok-4.7` for teams without residency constraints that want the widest capacity. Cross-Region inference routes requests across multiple AWS Regions, giving higher throughput without managing capacity Region by Region.

The model supports the OpenAI-compatible Chat Completions and Responses APIs, plus the Amazon Bedrock Converse API. On Converse, reasoning returns as a `reasoningContent` block alongside the text block. In `inferenceConfig`, set `maxTokens` only, and place model-specific parameters such as reasoning effort in `additionalModelRequestFields`.

Prerequisites include an AWS account with model access enabled for Grok 4.7, Python 3.9 or later with `openai`, `boto3`, and `aws-bedrock-token-generator` installed, and an IAM identity with `bedrock:InvokeModel` on both the inference profile and the account's default project.

For production, generating a short-term bearer token from existing AWS credentials keeps authentication tied to the IAM identity without storing a long-lived secret. Reasoning tokens count as output tokens and draw down `max_completion_tokens` before the answer text is produced, so size the limit to leave room for both. If the limit is reached during reasoning, the response returns without answer text — agent code should check for empty content and raise the limit if it appears. The evaluation runs used a limit of 32,768 tokens, which left headroom at every effort level.

Grok 4.7 supports four effort levels: `low`, `medium`, `high`, and `xhigh`. Because effort levels can change between model versions, it is worth confirming them against the service rather than hardcoding a list.

Why the test tasks required search, not lookup

Many agent evaluations test diligence: read a record, filter it, add it up. Those tasks are worth having, but to see what reasoning effort contributes, a task has to require search — the answer cannot be read off the data, it has to be proposed and then checked.

The evaluation built a synthetic environment of 20 services exposed through seven tools, with three tasks on top:

• two_fault_diagnosis: Two services failed silently at 03:00 and 12 others raised alerts. Identify the two that failed. Failed services raise no alerts, so the answer is not among the alerting services. There are 190 possible pairs, and only one explains exactly the alerts observed.
• maintenance_schedule: Patch eight services over four nights, two per night, under ten constraints and a rule that two services from the same team never share a night. There are 2,520 possible schedules, one valid.
• migration_budget: Choose candidates to migrate that maximize risk reduction within a budget, including transitive prerequisites. There are 53 feasible sets, one optimal. Picking the best ratio first gives a set nine points short of the optimum.

Four practices kept the measurement trustworthy. Every rule the grader relies on was stated in the prompt — the diagnosis prompt explicitly says a failed service raises no alert of its own. Each task was proven to have exactly one answer by brute-force enumeration before any run. The grader read only a required final line, so a response discussing other candidates while explaining its reasoning was graded on its conclusion. And tool parameters were constrained with enums where valid values were known, so every tool call targeted a real resource. All 72 responses included a gradeable final line.

The system prompt was deliberately short, asking the agent to gather facts with tools, never guess a value it can look up, check its answer against every rule before answering, and end with the specified final line.

Results: accuracy and token cost by effort level

Six runs of each task at each effort level, 72 runs in total. The agent answered 67 correctly.

Three observations stand out. First, `xhigh` answered every run correctly, while `medium` and `high` answered 17 of 18 each. With six runs per task and level, the differences between levels are indicative rather than statistically conclusive, but the direction was consistent across all three tasks.

Second, effort changes how much the agent reasons, not how much it explores. Tool calls stayed essentially flat, between 17.2 and 18.7 per run at every level. The agent gathered the same facts regardless of effort; what changed was how much deliberation happened before each response.

Third, the cost curve is steep. Moving from `low` to `xhigh` multiplies output tokens by 7.7x, while median elapsed time rises from 18 seconds to 106 seconds. The jump from `low` to `medium` alone is 5.4x in tokens.

What this means for your own agent workloads

The practical takeaway is that reasoning effort is a tunable per-request parameter, not a fixed model property. A team running high-volume, low-stakes agent tasks may find `low` acceptable if the task shape resembles these search-heavy ones — 15 of 18 correct at one-eighth the token cost is a real trade-off. For tasks where a wrong answer is expensive, `xhigh` delivered perfect accuracy in this evaluation.

Token counts were reported rather than currency throughout, because token prices change and the counts are what costs derive from. A measurement expressed in tokens stays valid even as pricing shifts.

The useful next step for any team is to measure on tasks shaped like their own. The evaluation design here — state every grading rule, prove each task has one answer by brute force, grade a required final line rather than the whole response, track format separately from correctness, and constrain tool parameters with enums — applies to most agent evaluations and can be adapted directly. Effort levels should also be confirmed against the service rather than hardcoded, since they can change between model versions.

For the current list of supported Regions, service tiers, and token prices, see the Grok 4.7 model card in the Amazon Bedrock User Guide and the Amazon Bedrock pricing page.