How to Run Grok 4.6 in Codex and Claude Code on Amazon Bedrock

Sam, Dario, and Elon can keep arguing. At Elevata, we’re much more interested in making state-of-the-art AI work however engineers want it to.

The model market moves too quickly for every launch to require a new engineering tool. Grok 4.6 is a strong, cost-efficient coding model. Codex and Claude Code are both excellent ways to work with code. The useful question was whether an engineering team could use Grok inside either workflow without creating another identity system, another set of provider keys, or another path for cost control.

We made that work in production through Amazon Bedrock. Engineers could select Grok in Codex or Claude Code, keep the local tools and approval flows of each client, and remain inside the same AWS governance boundary.

One engineer then used Grok across 334 substantial coding requests: implementing features, debugging, investigating repositories, reviewing code, and validating production changes. The work cost about $48. At current Bedrock rates, the same recorded token mix would cost roughly $91 with GPT-5.6 Sol or $114 with Claude Opus 5. For this workload, Grok cost 47% less than Sol and 58% less than Opus.

That cost profile makes Grok practical across daily engineering work—not just as a reviewer or an occasional experiment.

Why the Bedrock path differs by client

Codex and Claude Code do not speak the same protocol. Codex uses OpenAI Responses. Claude Code uses Anthropic Messages. Bedrock exposes Grok through OpenAI-compatible Responses and Chat Completions, so each client needs a different route to the same model.

The Bedrock endpoint documentation distinguishes Runtime from Mantle and shows that API support varies by model. The implementation below uses Bedrock Runtime for both clients.

1. ClientCodexSends Responses, tools, streaming, local approvals, and a session cache key.
2. AccessDirect connection or gatewayAuthenticates the user, applies model policy, and preserves the Responses request.
3. InferenceBedrock Runtime Responses → Grok 4.6Grok chooses tools; Codex runs approved actions on the workstation.

1. ClientClaude CodeSends Anthropic Messages, tools, tool results, and streaming.
2. AdaptationGateway + LiteLLMConverts Messages to Chat Completions, adds the cache-routing header, and signs the request.
3. InferenceBedrock Runtime Chat Completions → Grok 4.6The gateway returns the stream and usage in the format Claude Code expects.

In both cases, Grok proposes tool calls; it does not receive direct shell access. Codex or Claude Code applies its own sandbox and approval rules, runs the permitted action locally, and returns the result to the model.

1. Enable Grok on Amazon Bedrock

For a US deployment, the geographic inference profile is us.xai.grok-4.6. We used us-east-1 as the source Region. Query the profile during deployment to see the foundation models it can route to:

aws bedrock get-inference-profile \
  --region us-east-1 \
  --inference-profile-identifier us.xai.grok-4.6

The principal that invokes Bedrock needs bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream on the inference profile and its destination model ARNs. The Responses route also uses the account’s project/default resource, which can be restricted to the approved profile with bedrock:ModelArn.

Where those permissions live depends on your environment. A developer can connect directly with a Bedrock API key or temporary AWS credentials. A team can place them on a gateway workload role and let engineers authenticate to the gateway instead. The second pattern centralizes identity, model allow-lists, budgets, and usage; our Bedrock gateway article explains that wider control plane.

If you deploy outside the US geography, change the profile and source endpoint together. Bedrock’s inference-profile matrix lists the source and destination Regions that IAM policies and service control policies must allow.

2. Keep Codex on Responses

Our first Codex implementation translated Responses into Converse. Inference, streaming, and command execution worked, but prompt caching did not. Adding Converse cache markers then caused Grok requests to fail. The fix was simpler: stop translating a protocol that Codex and Bedrock already shared.

Codex supports custom model providers with their own base URL and authentication. A direct Bedrock API-key configuration looks like this:

model = "us.xai.grok-4.6"
model_provider = "bedrock-grok"

[model_providers.bedrock-grok]
name = "Grok 4.6 through Amazon Bedrock"
base_url = "https://bedrock-runtime.us-east-1.amazonaws.com/openai/v1"
env_key = "AWS_BEARER_TOKEN_BEDROCK"
wire_api = "responses"
requires_openai_auth = false

Set AWS_BEARER_TOKEN_BEDROCK, then start codex --model us.xai.grok-4.6. With a gateway, replace the base URL and authentication mechanism but keep wire_api = "responses". The Codex configuration reference documents custom providers, base URLs, environment-backed keys, and command-backed authentication.

To include Codex’s stable agent instructions in Grok’s reusable prefix, the gateway needs one additional normalization. Codex places those instructions in the top-level instructions field; the gateway moves them into the first developer input item, removes the original field, and preserves the session’s prompt_cache_key. The changing conversation and tool results remain after that stable prefix.

Before forwarding the request, remove hosted tools that Bedrock Runtime cannot execute and keep Grok requests synchronous because this endpoint does not support background execution. Function schemas, call IDs, reasoning settings, streaming events, and usage remain in the native Responses contract.

3. Give Claude Code a Bedrock-compatible gateway

Claude Code’s Bedrock mode sends Anthropic Messages, not Responses. To use Grok, the client needs a Bedrock-shaped gateway that accepts its normal Invoke paths, authenticates the engineer, and translates Grok traffic before signing the upstream request.

A minimal managed client configuration is:

{
  "apiKeyHelper": "your-gateway-token-command",
  "availableModels": ["us.xai.grok-4.6"],
  "enforceAvailableModels": true,
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "CLAUDE_CODE_SKIP_BEDROCK_AUTH": "1",
    "ANTHROPIC_BEDROCK_BASE_URL": "https://gateway.example.com/bedrock",
    "AWS_REGION": "us-east-1"
  }
}

The identity helper is specific to your environment. The protocol requirement is stable: the gateway accepts Bedrock-style /model/{model_id}/invoke and /invoke-with-response-stream paths and returns the event stream Claude Code expects. Anthropic documents this pattern in its third-party integration and LLM gateway guides.

Only requests for Grok need translation. Our gateway sends them through a pinned LiteLLM adapter that converts Anthropic Messages to OpenAI Chat Completions. The adapter preserves system messages, tools, tool calls, tool results, streaming, and usage. It also removes Anthropic-only fields and sampling controls that the Grok profile rejects. Claude models can remain on their native Bedrock route.

4. Put the cache key on the actual HTTP request

Grok uses different cache-routing controls for the two APIs. Responses carries prompt_cache_key in the request body. Chat Completions uses x-grok-conv-id as an HTTP header. xAI documents both in its prompt-caching guide.

For Claude Code, derive an opaque, stable key from the reusable model, system prompt, and tool definitions—not from the changing user turn:

material = {
    "model": "us.xai.grok-4.6",
    "system": anthropic_request.get("system"),
    "tools": anthropic_request.get("tools"),
}
cache_key = "org:claude:grok:v1:" + sha256(canonical_json(material)).hexdigest()

chat_request = translate_messages_to_chat_completions(anthropic_request)
headers = {"x-grok-conv-id": cache_key}

post_signed(
    "https://bedrock-runtime.us-east-1.amazonaws.com/openai/v1/chat/completions",
    headers=headers,
    json=chat_request,
)

The hardest defect was invisible in the intermediate payload. Our first adapter placed x-grok-conv-id inside JSON. The transformer output looked correct, but the signed HTTP request contained no header, so Bedrock never received the routing key.

The fix extracts the allow-listed cache key before serialization, adds it to the HTTP headers before SigV4 signing, and removes internal routing fields from the JSON body. The regression test now inspects the final prepared request, not just the intermediate object.

On the return path, preserve cached-token usage through streaming and translate it into the field each client expects. Cached tokens are a subset of input tokens, so subtract them before settling ordinary input or the gateway will count the same tokens twice. After this fix, both Codex and Claude Code reported provider cache reads through the production path.

Model choice should not force tool choice

After rollout, engineers could use Grok in Codex or Claude Code without changing their repository, tool, or approval workflows. The platform team kept one place for identity, model policy, budgets, and usage accounting. Amazon Bedrock remained the inference boundary.

That is the outcome worth designing for. Engineers choose the client that fits their work, teams get a capable model at a lower cost, and a new model does not trigger another tool rollout.

If you want to offer Grok across Codex and Claude Code in your AWS environment, Elevata can design and validate the Bedrock access, gateway, protocol translation, and client rollout.