xAI’s Grok 4.7 is now available on Amazon Bedrock, adding a frontier model built for coding, long-running agents, and knowledge work to the Bedrock model catalog. It offers a 500K token context window and supports configurable reasoning effort at four levels: low, medium, high, and xhigh. Grok 4.7 is served on the bedrock-runtime endpoint through cross-Region inference profiles, and it supports the Responses, Chat Completions, and Converse APIs. According to xAI, it’s their most capable model for coding and knowledge work: it works longer on difficult tasks and verifies its own output more carefully before moving on. This post covers what xAI says Grok 4.7 is designed for, how it is packaged on Amazon Bedrock, and how to send your first request. What Grok 4.7 is built for The capability and training details in this section come from xAI’s launch announcement, Introducing Grok 4.7, published September 21, 2026, and from the Grok 4.7 model documentation. xAI positions Grok 4.7 as its most capable model for coding and knowledge work. The theme is endurance rather than raw speed: the model works longer on difficult tasks and checks its own work more carefully before moving on. On training, xAI reports that Grok 4.7 uses a new and larger base model. It was trained with a longer reinforcement learning run over a harder mix of tasks, deliberately weighted toward problems that take many hours to complete. Two capabilities came out of that: the model is better at verifying its own work, and makes more effective use of its 500K token context window on long tasks. xAI also trained it to natively understand the Grok Bot harness, which it credits for improvements in conversational tasks and general knowledge work. For anyone building agents, the self-verification behavior is the detail worth noting. A model that checks its own output before continuing tends to fail less catastrophically on long trajectories, where an early mistake otherwise compounds through every later step. xAI also calls out stronger document and presentation generation, and describes gains on professional knowledge work of the kind done by lawyers, nurses, and financial analysts. xAI reports gains across its published evaluations. These span software engineering with CursorBench and DeepSWE, multi-hour terminal and office work with Terminal-Bench and AA Briefcase, electrical engineering with EEBench, legal work with the Harvey Legal Agent Benchmark, and clinical reasoning with HealthBench Professional. For the results themselves, see xAI’s announcement. Independent evaluation Artificial Analysis runs its own evaluations rather than relying on developer-reported figures, which makes it a useful second reference alongside xAI’s published results. According to Artificial Analysis, Grok 4.7 improves across its evaluation suite. The largest gains are on long-horizon agentic knowledge work and on coding agents run in xAI’s own harness. The Intelligence Index is a composite built from multiple independent evaluations covering agentic tool use, reasoning and knowledge, knowledge reliability, and long-context work. Measure (Artificial Analysis) Grok 4.7 Grok 4.6 Intelligence Index 46 44 Coding Agent Index 56 47 AA-Briefcase, long-horizon knowledge work (Elo) 1,657 1,546 GDPval-AA, professional work products (Elo) 1,695 1,605 AA-Omniscience Index 32 30 AA-Omniscience hallucination rate 29% 34% Output tokens per Intelligence Index task ~81k ~38k Grok 4.7 is measured at xhigh reasoning effort, and Grok 4.6 at the effort level Artificial Analysis reported for each measure. The final row is the tradeoff to plan for: the gains come with roughly double the output tokens per task. That’s why it pays to set the effort level deliberately rather than inheriting the default. Safety and cyber security According to xAI, Grok 4.7 was built with an entirely new safeguard stack and is the strongest model it has tested on refusals and jailbreak resistance. xAI frames the goal in dual-use domains such as cyber security and biological work as holding two things at once: remaining useful for legitimate tasks while refusing dangerous ones. On cyber security specifically, xAI reports the model allows only a small fraction of risky dual-use prompts through while rarely blocking legitimate security work. xAI has also begun giving selected cyber security partners invite-only access to Grok 4.7’s red-team capabilities for defense research. How Grok 4.7 is packaged on Amazon Bedrock Grok 4.7 accepts text and image input and returns text. The model is served on the bedrock-runtime endpoint through cross-Region inference profiles, so requests name a profile rather than a bare model ID: Inference option Model ID Base URL Geo cross-Region us.xai.grok-4.7 https://bedrock-runtime.{region}.amazonaws.com/openai/v1 Global cross-Region global.xai.grok-4.7 https://bedrock-runtime.{region}.amazonaws.com/openai/v1 Grok 4.7 supports the Responses API, the Chat Completions API, InvokeModel and the Converse API. Because the model is OpenAI-compatible, you have a choice of client. The OpenAI SDK works against the /openai/v1 path with a bearer token, which can be either an Amazon Bedrock API key or a short-term token minted from your AWS Identity and Access Management (IAM) credentials. The AWS SDKs reach the same model through Converse, signing requests with your ordinary AWS credentials. Use the OpenAI SDK if you’re porting an existing integration. Use Converse if you want one message shape across the models in your account, along with invocation logging and response streaming through the standard Bedrock event types. Using Grok 4.7 with Bedrock features Implicit prompt caching applies automatically to repeated prompt prefixes, so agents that resend a large system prompt or reference document on every turn pay the cached rate for that prefix. Amazon Bedrock Guardrails attach by ID and version on the request, applying content filters, denied topics, personally identifiable information (PII) redaction, and word policies to both the prompt and the response. This is useful for a model that might run unattended across many steps. With structured outputs, you can constrain a response to a JSON Schema so downstream code can parse it directly. Invocation logging captures each call in Amazon CloudWatch with the request, the response, and token counts including reasoning tokens. This gives you an audit trail for long agent runs. Regions and inference options Grok 4.7 routes through one of two cross-Region inference profiles rather than pinning to a single Region. The Global profile, global.xai.grok-4.7, routes each request to any supported commercial AWS Region, spreading load across more capacity, and is priced below a geographic profile. The tradeoff is less control over where a given request is served, which can mean more variable latency. The US geographic profile, us.xai.grok-4.7, keeps processing within the US geography, which addresses US data residency requirements. Choose it when you have residency constraints or latency-sensitive traffic, and Global when cost and throughput matter more. Service tier and pricing Standard is pay-per-token with no commitment, selected by setting "service_tier": "default" or omitting the field. Priority delivers faster, prioritized processing for a premium ("service_tier": "priority"). Flex offers lower-cost access for work that isn’t time-sensitive ("service_tier": "flex"). Service tier is a significant cost lever that you control. For per-token pricing across the tiers, see the Amazon Bedrock pricing page. Send your first request Before your first call, confirm that the model is available to you in the Bedrock console for the AWS Region that you plan to use. Install the OpenAI SDK, and boto3 if you plan to use the Converse API: pip install openai pip install boto3 Generate a long-term Amazon Bedrock API key from the Amazon Bedrock console for exploration, then set your environment: export OPENAI_API_KEY="" export OPENAI_BASE_URL="https://bedrock-runtime.us-east-1.amazonaws.com/openai/v1" A first request with the Chat Completions API: from openai import OpenAI client = OpenAI() response = client.chat.completions.create( model="us.xai.grok-4.7", messages=[ {"role": "user", "content": "Can you explain the features of Amazon Bedrock?"} ], ) print(response.choices[0].message.content) The same call through the Responses API: response = client.responses.create( model="us.xai.grok-4.7", input="Can you explain the features of Amazon Bedrock?", ) print(response.output_text) And through the Converse API with boto3. Because reasoning is always active, the first content block carries the reasoning and the answer sits in a later block, so search the blocks for the text rather than indexing content[0]: import boto3 client = boto3.client("bedrock-runtime", region_name="us-east-1") response = client.converse( modelId="us.xai.grok-4.7", messages=[ {"role": "user", "content": [{"text": "Can you explain the features of Amazon Bedrock?"}]} ], inferenceConfig={"maxTokens": 2048}, ) blocks = response["output"]["message"]["content"] text = next(b["text"] for b in blocks if "text" in b) print(text) On Converse, you set the effort level through additionalModelRequestFields rather than a reasoning parameter: response = client.converse( modelId="us.xai.grok-4.7", messages=[{"role": "user", "content": [{"text": "What is 17*23? Number only."}]}], inferenceConfig={"maxTokens": 3000}, additionalModelRequestFields={"reasoning_effort": "xhigh"}, ) Three operational notes. First, requests must name us.xai.grok-4.7 or global.xai.grok-4.7. Second, bedrock:InvokeModel is evaluated against three resources: your account’s default project, the inference profile you name, and the underlying foundation model (FM). The foundation model Amazon Resource Name (ARN) is wildcarded across Regions because cross-Region profiles route outside the calling Region. Bearer-token authentication additionally requires bedrock:CallWithBearerToken, which boto3 and Converse don’t need: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "bedrock:InvokeModel", "Resource": [ "arn:aws:bedrock:{region}:{account-id}:project/default", "arn:aws:bedrock:{region}:{account-id}:inference-profile/us.xai.grok-4.7", "arn:aws:bedrock:*::foundation-model/xai.grok-4.7" ] }, { "Effect": "Allow", "Action": "bedrock:CallWithBearerToken", "Resource": "*" } ] } List every inference profile you plan to call. Profiles are scoped individually, so a policy naming us.xai.grok-4.7 does not cover global.xai.grok-4.7. Third, the two authentication mechanisms cover different code paths. An Amazon Bedrock API key in OPENAI_API_KEY travels as a bearer token and authenticates the OpenAI-compatible calls. The boto3 Converse examples sign with SigV4 instead, drawing on your ordinary AWS credentials from the environment, a profile, or a role. Configure both if you intend to use Converse alongside the OpenAI-compatible APIs. Treat a long-term API key as an exploration-only credential. For production, use short-term bearer tokens generated from your IAM credentials with the aws-bedrock-token-generator package, since they expire automatically and keep access tied to your IAM identity. Working with reasoning effort Reasoning is active on Grok 4.7, and effort level is a primary control you have over its cost and latency. You configure it through the reasoning parameter on the Responses API with low, medium, high, or xhigh, and through additionalModelRequestFields on Converse. The default is high. That’s worth setting explicitly rather than inheriting, because leaving it unset on latency-sensitive or high-volume calls will spend more reasoning tokens than those calls need. Because the model is trained to work longer and verify its own output, higher effort buys more than extra deliberation on a single answer: it buys more self-checking across a long task. Short extraction and classification calls belong at low. Multi-step planning, long agent trajectories, and work where an early error propagates are where high and xhigh earn their tokens. Reasoning content is encrypted. You can have it returned by passing the following on a Responses API request.include: ["reasoning.encrypted_content"] Then send that content back on subsequent turns to give the model its own prior reasoning as context in a multi-turn conversation. The Chat Completions API doesn’t return reasoning tokens. from openai import OpenAI client = OpenAI() # OPENAI_BASE_URL points at the bedrock-runtime endpoint response = client.responses.create( model="us.xai.grok-4.7", reasoning={"effort": "high"}, include=["reasoning.encrypted_content"], input="Explain quantum entanglement simply.", ) print(response.output_text) To find where additional reasoning stops paying for itself, benchmark the levels against your own workload. Get started With Grok 4.7 in Amazon Bedrock, you get a 500K token context window, four reasoning effort levels, image input, tool calling, and Geo and Global cross-Region routing. All of it is reachable through the Responses, Chat Completions, and Converse APIs. To start building, review the Grok 4.7 model card for the current Region list, feature matrix, and parameter details, and check the Amazon Bedrock pricing page for token rates. If you generated a long-term Amazon Bedrock API key for exploration, delete it from the Amazon Bedrock console when you are finished. A standing credential you no longer need only widens your account’s attack surface. Sources Grok 4.7 Model Card xAI, Introducing Grok 4.7 Artificial Analysis, Benchmarking Grok 4.7 xAI, Grok 4.7 model documentation Amazon Bedrock pricing About the authors Suheel Farooq Suheel is a Principal Solutions Architect at AWS, specializing in artificial intelligence, machine learning, and generative AI. He helps Foundation Model Provider customers design, build, modernize, and scale their AI/ML and generative AI workloads on AWS — from bringing foundation models to Amazon Bedrock to optimizing training and inference and building Agentic AI solutions. His experience spans the AWS AI/ML and generative AI portfolio, particularly Amazon Bedrock, Amazon Bedrock AgentCore, and Amazon SageMaker AI. In his free time, Suheel enjoys working out and hiking. William Yap William is Principal Product Manager for Amazon Bedrock. Ikenna Izugbokwe Ikenna is a Principal Solutions Architect at AWS specializing in networking, containers, and AI infrastructure. He guides model providers through scaling their training and inference systems while enabling rapid deployment of evolving frontier models on AWS. His work increasingly spans agentic AI – building reliable, cost-efficient multi-agent systems and the inference infrastructure behind them in production. Anirban Gupta Anirban is a Principal Engineer at AWS based in Seattle, USA, where he focuses on the design of secure, high-scale model-serving infrastructure for Amazon Bedrock. He has driven the technical work behind several foundation-model launches on the platform. Prior to joining Amazon Bedrock, he was a Principal Engineer on AWS Outposts, building hybrid on-premises cloud infrastructure. Fabio Branco Fabio is a Senior Customer Solutions Manager at Amazon Web Services (AWS) and strategic advisor guiding foundational model providers in their go-to-market journey. Prior to AWS, he held Product Management, Engineering, Consulting, and Technology Delivery roles across multiple Fortune 500 companies in industries, including retail and consumer goods, oil and gas, financial services, insurance, and aerospace and defense.

Grok 4.7 is now available on Amazon Bedrock

How Datacor built self-service rental analytics with Amazon Quick Sight

The most challenging areas in freight are not the highways but the yards and docks across multitudes of shippers and receivers. The battle against utilization entropy is fought on the loading and unloading docks. It mostly happens inside a warehouse fence line, where a driver sits in a line of 10 trucks waiting to talk to one person behind a pane of glass. YardFlow is expanding its yard automation software to all 200+ facilities of a beverage giant after a 26-site deployment. The shipper moved nearly 5% more freight with the same headcount according to a YardFlow analysis. “That’s tens of millions of dollars of incremental profit,” Jake Koppinger, founder of YardFlow, told FreightWaves. The customer is expanding the rollout from its largest facilities down to its smallest. “They’re pushing us into all of their 200+ facilities, including their smallest, so biggest to smallest, because they want to see that standardization,” Koppinger said. YardFlow has processed close to 2 million shipments across the 26 sites. The system runs at three-nines or 99.9% uptime. The Box in the Back of the Warehouse The problem YardFlow originally tackled began with paper. Specifically, the bill of lading handoff that still runs through a printer, a stapler and a slot in a window at thousands of U.S. distribution centers. Koppinger walked through the analog process with a hypothetical example. A dock coordinator prints three copies, collates them, passes them through the glass, takes back a signature, then files the shipper’s copy. “They build up this big pile of paper, rubber band it, put a date on it, and put the pile in the box,” he said. Once the box fills, it goes into storage for seven years to satisfy the statute of limitations. That box becomes a cash problem roughly 60 days later. If a shipper invoices a retailer for 24 pallets and the retailer says it received 23, the dispute surfaces inside a lump-sum payment. “You have like 50 invoices that get paid at once and it comes back in a lump sum of like $1.2 million. Well, I was expecting through those invoices $1.3 million. Now I’ve got to figure out why a hundred thousand’s missing,” Koppinger said. “So now there’s a cash attribution issue.” Resolving it sends a dock coordinator into the warehouse to find the right box and dig out a two-month-old signature. That coordinator is the same person orchestrating forklift drivers, assigning yard spotters, dealing with truck drivers and replacing printer ink. “What I like to equate that process to is like the old airport check-in process,” Koppinger said. Drivers waiting in that line are accruing detention and risking on-time, in-full penalties on the delivery ahead. Why Yard Automation Starts With the Driver, Not the Robot YardFlow’s core product is what Koppinger calls the driver journey: a digitized path from gate check-in through dock assignment to check-out and signed documentation. The system has processed close to 2 million shipments and runs at 99.9% uptime. Drivers need no app download, and QR code check-in is optional. It’s a design choice that reflects a constraint Koppinger calls non-negotiable. “If you have any issues where truck drivers are asked to download an app to get a digital bill of lading or something, they don’t have it and then they’re stuck there trying to download this app, they don’t have connectivity,” he said. “That causes problems with your operations.” The harder obstacle remains organizational. Warehouses run on tribal knowledge, and each one has its own unique operational peculiarities. “You have people that have worked there for 20, 30 years and they’re the ones that keep the lights on,” Koppinger said. “Each warehouse can tend to operate its own silo because they’re big operations.” A single facility at a large retailer or consumer packaged goods company can generate hundreds of millions in revenue, which buys it the autonomy to do things its own way. That level of autonomy makes reporting challenging. Facilities held to the same KPIs collect the data differently, leaving executives comparing the warehouse equivalent of apples to oranges. Koppinger’s counterargument is that every yard shares a few common denominators. Drivers arrive, check in, go somewhere, sign something and leave. “There’s one common theme, one lowest common denominator that exists from an operational perspective that is sort of the heartbeat for how they ship products and generate revenue,” he said. An Eye in the Sky Over the Yard With the driver journey deployed, the customer asked for a yard management system. YardFlow built one and is now deploying it, extending the same standardization to yard spotters, jockeys and trailer inventory. The newer layer leverages machine vision, mounted at the gate and on the spotters themselves. “If I tell a yard spotter to go take something from dock three and put it in spot four, the system has to trust that that’s what they did,” Koppinger said. “But if you can have an eye in the sky to actually validate the fact that they took it from dock three and put it in spot four, now we have something to cross-check that.” Cameras on moving spotters build what Koppinger describes as a digital twin of the yard. Gate cameras read arriving and departing trucks and trailers, validating carrier identity against DOT and MC numbers. That has direct implications for cargo theft and identity fraud, both of which have pushed shippers toward tighter gate controls. The Steak Before the Sizzle Koppinger’s pitch to shippers is deliberately unglamorous. He notes that is the point. “There’s a lot of AI pilot fatigue. You pilot something, it never goes anywhere. It’s hard to scale,” he said. Digital documentation and check-in workflows are “what I call sort of the steak relative to the sizzle.” He calls the sequencing an order of operations. “Let’s get the operations fixed. Let’s standardize your processes and protocols across your yards. Let’s get everything digitized so that you can then be in a position to start layering in these other layers of automation,” he said, rather than dropping an autonomous yard jockey into a facility where drivers still check in on clipboards. Deployment speed reinforces the order. The driver journey and the yard management system go live in 30 minutes remotely. Machine vision requires on-site hardware installation and can take longer. “We’ve seen companies take on yard modernization projects that take years to optimize one facility and then they struggle to get the next one on and scale across the pilot network, because there’s a gap between theory and operational reality or just require too much change management at once,” Koppinger said. The endgame is a yard that can dispatch machines as easily as people, and Koppinger says the paperwork problem is what stands in the way. “You’re not going to be handing paperwork to an autonomous truck, right? You’ve got to be able to orchestrate an autonomous truck in through the gate, through the yard, tell them where to go in whatever the language that autonomous truck speaks,” he said. “You’ve got to deal with both human spotters and autonomous spotters probably for the next 15 years. And so our system is kind of the brain that sits in the middle and orchestrates all of these different things to facilitate that autonomous yard.” The post YardFlow lands over 200-site yard automation deal appeared first on FreightWaves.

Automation & Logistics

Get Automation & Logistics signals in your inbox

Deploy Autonomous AI Capabilities & Skills Runtimes

Related desks