Grok 4.3 Joins Amazon Bedrock for Enterprise AI Workloads
xAI's Grok 4.3 has become generally available on Amazon Bedrock, giving teams that build agents and AI workflows a model that reasons reliably over long inputs. With this launch, xAI joins Amazon Bedrock as a model provider. Grok 4.3 is a model with configurable reasoning effort. It offers strong tool use and instruction following for building agents, and token efficiency for high-volume inference. It accepts text and image input, and has a 1 million token context window for long documents and multi-turn sessions. The model runs on Mantle, the next-generation inference engine in Amazon Bedrock.
This post covers what makes Grok 4.3 a great fit for agentic and enterprise workloads, how you access it through Amazon Bedrock, and how to use the capabilities most teams reach for first: a basic chat request, configurable reasoning effort, tool calling, structured output, image input, and stateful multi-turn conversations.
Why Grok 4.3 Is a Great Fit for Agentic and Reasoning Workloads
According to xAI, Grok 4.3 is built for enterprise work where accuracy matters. On its own benchmarks at the time of the model launch, xAI reports it outperforms various industry benchmarks. Grok 4.3 ranked number one on the Artificial Analysis Omniscience benchmark with the lowest hallucination rate among the frontier models it compared. It also placed first on the Artificial Analysis Tau2 Telecom benchmark for tool calling in customer support scenarios, and first on the Vals AI Case Law and Corporate Finance benchmarks for document understanding. xAI also places the model on the intelligence versus cost Pareto frontier, which it describes as 2 to 10 times more intelligence per dollar than other frontier models.
With Grok 4.3, you can control how much the model thinks before answering through an effort level on each request. You configure the effort level (none, low, medium, and high) per request and let one model serve the full range of work. A classification call can run at none effort to keep latency low. A contract analysis or case law task can run at high when depth matters more than response time. Grok 4.3 accepts text and image input and returns text, and its 1 million token context window leaves room for long documents and extended multi-turn sessions. The model handles tool calling and instruction following well, which is what makes it practical for agents that depend on function calls to take action. These traits line up with use cases such as contract review, credit agreement analysis, and financial document question answering. In these cases, the model reasons over long inputs and then calls out to systems of record.
How You Access Grok 4.3 on Amazon Bedrock
Grok 4.3 runs on Mantle, and accessing it differs from models that use the Amazon Bedrock Runtime API. Mantle uses OpenAI compatible APIs. You can invoke Grok 4.3 either with the OpenAI SDK or through direct HTTPS requests to the Chat Completions API or the Responses API.
The Mantle endpoint URL is Region specific and follows this pattern. For example, in us-west-2 the base URL is https://bedrock-mantle.us-west-2.api.aws/openai/v1. Note that the Responses API URL route differs slightly on the Mantle endpoint (openai/v1/) from the Runtime endpoint (v1/responses).
To set up your SDK with Grok 4.3, set the base URL with the correct Region and path as described in the preceding section.
When using Grok, note that the context window is 1 million tokens and that the defaults depart from the standard OpenAI specification in three places: temperature defaults to 0.7 rather than 1, top_p defaults to 0.95 rather than 1, and max_completion_tokens defaults to 131072. Set these explicitly if your application needs different behavior.
Authenticate and Run a First Request
You have two ways to authenticate against the Mantle endpoint, and both work with the same OpenAI SDK. For production, we recommend short term bearer tokens generated from your IAM credentials, because they expire automatically and keep access tied to your IAM identity. Use a long term Amazon Bedrock API key for quick exploration and getting started. Restrict long lived keys to that purpose rather than embedding them in production applications.
The following example shows how to authenticate with a long term Amazon Bedrock API key to access the model. Treat this as an exploration only credential. You can generate one from the Amazon Bedrock console, and then install the OpenAI SDK with pip install openai. Point the client at the regional Mantle endpoint and authenticate with your API key. The model ID is xai.grok-4.3.
When you are ready to incorporate Amazon Bedrock into applications with greater security requirements, we recommend using short term credentials. You can generate a short term bearer token from your existing AWS credentials at request time using the Amazon Bedrock token generator. This keeps authentication tied to your IAM identity and avoids a long lived secret. To get started, install the aws-bedrock-token-generator package with pip install aws-bedrock-token-generator. Use the provide_token function from the aws_bedrock_token_generator library in code.
Configure Reasoning Output
You can control how much reasoning effort the model spends through the reasoning parameter on the Responses API. The effort levels are none (which disables reasoning), low (the default), medium, and high. Higher effort tends to help on multi step problems where a quick answer would be wrong, at the cost of more output tokens.
The Chat Completions API does not return a reasoning trace. If you want the model reasoning available across turns, use the Responses API. In the default stateful pattern, where you set store=True and chain calls with previous_response_id, the service retains each turn reasoning and feeds it back automatically, so you do not manage it yourself. Encrypted reasoning is for the stateless case. If you set store=False (for example, when your workload requires that turns are not persisted server side), request the reasoning with include=["reasoning.encrypted_content"]. Pass it back in your next request input to give the model its own prior reasoning as context.
A practical pattern is to run classification, extraction, and short factual lookups at none or low, and reserve high for planning steps, math, and chains where a single early mistake derails the whole task.
Stay updated
Get the day's AI and automation news in your inbox. No spam, unsubscribe anytime.
Call Tools with Grok 4.3
Tool calling is central to agentic workloads, and Grok 4.3 supports it through the same OpenAI compatible interface. You describe the tools available, the model decides when to call one, and it returns a structured request that your code executes and feeds back. Grok 4.3 follows the standard OpenAI tool calling shape, so you define each tool with a JSON Schema for its parameters.
The model parsed the city out of the question and produced a valid arguments object that matches the schema. From here you run the function in your own code, append a tool role message with the result, and call the model again so it can fold the data into a natural language reply. This is the building block for multi step agents on Grok 4.3.
Structured Output
When you need the model to return data your code can parse directly, use structured output with a JSON Schema. Grok 4.3 supports the json_schema response format with strict mode, so the response conforms to the schema you provide, rather than giving free form text.
Setting strict to True and additionalProperties to False keeps the response constrained to the keys you asked for, which pairs well with tool calling when a downstream system expects a fixed record format. One operational note from testing: requests occasionally return a 400 from an automated content safety check even on benign input, so build a short retry into production calls.
Image Input
Grok 4.3 accepts images as input and returns text, which covers document understanding, chart reading, and visual question answering. You pass an image using the same pattern as the OpenAI Chat Completions API, as a content part with a data URL holding base64 encoded bytes, or a public image URL. The text and image parts go in the same content array so the model sees the question and the picture together.
In testing, the model read a generated test image and named its dominant color correctly. Use a supported image format such as PNG or JPEG and keep the encoding clean: a malformed or truncated image payload returns a validation_error rather than a best guess answer.
Stateful Conversations with the Responses API
The Responses API can hold conversation state on the service side, so you do not need to resend the full message history on every turn. You store a turn by passing store=True, capture the returned response ID, and reference it on the next call with previous_response_id. The model treats the earlier exchange as context.
From the second client.responses.create call in the code example, there is no message being sent except for the previous_response_id. Because the service stores each turn, the model prior reasoning is carried forward automatically to the next call, so you keep both the conversation and the model thinking in scope without managing that state yourself. One thing to know before you turn this on: storing conversation state means the service retains those turns. Review the Amazon Bedrock data protection documentation for details on the security and privacy of your stored data, and how to disable retention if needed.
Service Tiers and Regional Availability
Amazon Bedrock offers multiple service tiers so you can match cost and throughput to each workload. Standard tier on demand inference provides pay per token access with no commitment, Priority offers preferential treatment in the processing queue for a higher per token price, and Flex provides lower cost access for workloads that are not time sensitive. You can use Grok 4.3 with the Standard, Priority, and Flex tiers. For details, see service tiers for inference.
Grok 4.3 uses in Region inference, so you pin your client to a Region where the model is available and set the Mantle base URL to match. Geo and Global cross Region inference are not offered for this model at launch. The examples in this post use us-west-2. For the current list of supported Regions, see the Regional availability documentation, and for pricing across the tiers, see the Amazon Bedrock pricing page.
Conclusion
Grok 4.3 on Amazon Bedrock gives you a reasoning first model with configurable effort, native tool calling, strict structured output, image understanding, and server side conversation state. You can reach the model through the OpenAI SDK pointed at the bedrock-mantle endpoint. The examples in this post do not create billable AWS resources beyond per request token usage. But if you generated a long term Amazon Bedrock API key for exploration, delete it from the Amazon Bedrock console when you are done. A long term key is a standing credential, so removing the ones you no longer need keeps your account attack surface small.
To start building, review the Grok 4.3 model card for the current Region list and parameter details, and see the Amazon Bedrock pricing page for token rates. From there, a few directions are worth exploring: wire the tool calling loop end to end by executing the returned function and feeding the result back, thread encrypted reasoning content across Responses turns to give long running agents continuity in how they think, and benchmark effort levels against your own workloads to find where higher reasoning stops earning its token cost. Join the discussion in the Amazon Bedrock community on AWS re:Post.