Grok 4.6 is now in the Amazon Bedrock model catalog, and the interesting part is not the model card. It is that the same model is reachable through two different endpoints with two different feature sets. If you are wiring an agent, that choice will shape your integration more than the benchmark table will.
Two endpoints, two model IDs, two feature sets
According to the AWS Machine Learning Blog announcement, Grok 4.6 launched on Bedrock on August 18, 2026, and the post was published September 21, 2026. It is xAI’s second model on Bedrock, after Grok 4.3.
The packaging is where the decision lives. On bedrock-mantle the model ID is xai.grok-4.6. On bedrock-runtime it is us.xai.grok-4.6 for Geo cross-Region inference or global.xai.grok-4.6 for Global. Same model, different surface.
Feature support splits along the same line. The AWS post lists client-side tool calling, reasoning, structured outputs, prompt caching, response streaming, projects, and abuse detection on bedrock-mantle. On bedrock-runtime it lists reasoning, prompt caching, response streaming, invocation logs, and projects (default project only). Structured outputs, server-side tool use, intelligent prompt routing, count tokens, and application inference profiles are not supported on bedrock-runtime.
So the practical rule from the supplied material: if your application depends on JSON Schema structured output, that points you at bedrock-mantle. If you want the Converse API or invocation logging, that points you at bedrock-runtime. Tool calling works on both, so function-calling agents are not locked to one side.
What runtime support actually buys you
The Converse API is the headline addition for teams already standardized on AWS SDKs. Both converse and converse_stream are available, which means one message shape across models and streaming through the usual Converse events (messageStart, contentBlockDelta, contentBlockStop, messageStop, metadata) instead of hand-rolled SSE parsing.
This is the same class of problem as owning your own serving container: the endpoint contract, not the weights, determines how much glue code you maintain. That tradeoff showed up in our earlier post on AgentCore Runtime and what changes when you stop owning the agent container, and it applies here in miniature.
Two other runtime details matter for unattended agents. Amazon Bedrock Guardrails now supports Grok 4.6 on bedrock-runtime across its APIs, with content filters, denied topics, PII redaction, and word policies attached by guardrail ID and version, evaluated against both prompt and response. And with model invocation logging enabled, calls are captured as CloudWatch records including request body, response body, token counts with reasoning tokens, and the inference profile used.
Reasoning effort, context, and the cost levers
Grok 4.6 offers a 500K token context window and configurable reasoning effort at four levels: low, medium, high, and xhigh. The xhigh level is new relative to the earlier Grok launch. On Converse you set it through additionalModelRequestFields={"reasoning_effort": "xhigh"} rather than a reasoning parameter.
Prompt caching is billed at roughly a quarter of the standard input rate, which matters for agents that resend a large system prompt every turn. Caching applies to a repeated prefix, so stable content belongs at the front of the request, and the AWS post suggests reading the cached token count in the usage block to confirm the discount is landing before you build it into a cost model.
Cross-Region inference is also new in shape. Grok 4.3 used in-Region inference only, with no Geo or Global cross-Region option. Grok 4.6 on bedrock-runtime is invoked through inference profiles instead. Geo keeps traffic within a geography for residency requirements; Global routes worldwide for the widest capacity pool and is cheaper, at $2.00 per million input tokens against $2.20. Absent a residency constraint, Global is usually the better default.
Service tiers add another lever: Standard is pay-per-token, Priority runs at 1.75x for faster processing, and Flex at 0.5x for work that is not time-sensitive. The supplied material does not give per-token prices across all tiers, only the multipliers and the two cross-Region input rates.
What the benchmarks do and do not tell you
xAI reports Grok 4.6 High reaching an AA Intelligence Index of 61, GDPVal-AA v2 of 1753, CursorBench v3.2 at 69.9%, DeepSWE v1.1 at 65.9%, APEX-Agents at 57.5%, and Terminal-Bench v3.0 at 26%, among others. These are xAI’s published figures from its launch announcement, not independent verification.
Several of those come from Artificial Analysis, whose Intelligence Index is a composite of nine evaluations covering agentic tool use, reasoning and knowledge, long context reasoning, and quantitative analysis over spreadsheets and documents. Artificial Analysis also tracks cost and latency, and its cost-per-task metric is a weighted average derived from input, cache hit, cache write, reasoning, and answer token prices. That is the number worth watching if your workload is reasoning-heavy, because reasoning tokens are a real line item and the headline intelligence score will not tell you what a task costs.
The decision to make first
Before benchmarking anything, decide which endpoint your application can live with. Structured output requirements push you to bedrock-mantle; Converse, guardrails, and invocation logging push you to bedrock-runtime. Then check the Regional availability page, because bedrock-runtime offers no in-Region inference for this model and the Global profile list runs past 30 Regions.
One limitation worth naming: the supplied material does not specify pricing across all three service tiers, so treat the tier multipliers as the only confirmed cost signal until you read the Bedrock pricing page. Pick the endpoint, confirm the Region, then measure cached-token hit rate on a real agent run before you commit to a cost model.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.