Sam, Dario e Elon podem continuar discutindo. Na Elevata, estamos muito mais interessados em fazer a IA de ponta funcionar da forma que os engenheiros preferirem.
O mercado de modelos muda rápido demais para que cada lançamento exija uma nova ferramenta de desenvolvimento. O Grok 4.6 é um modelo forte e econômico para programação. Codex e Claude Code são duas excelentes formas de trabalhar com código. A pergunta útil era se uma equipe de engenharia poderia usar o Grok nos dois fluxos sem criar outro sistema de identidade, distribuir novas chaves de provedor ou abrir mais um caminho para controlar custos.
Colocamos isso em produção pelo Amazon Bedrock. Os engenheiros passaram a selecionar o Grok no Codex ou no Claude Code, mantendo as ferramentas locais e os fluxos de aprovação de cada cliente dentro da mesma fronteira de governança na AWS.
Um engenheiro usou o Grok em 334 requests relevantes de desenvolvimento: implementação de funcionalidades, depuração, investigação de repositórios, revisão de código e validação de mudanças em produção. O trabalho custou cerca de US$ 48. Pelas tarifas atuais do Bedrock, a mesma combinação de tokens custaria aproximadamente US$ 91 com o GPT-5.6 Sol ou US$ 114 com o Claude Opus 5. Nessa carga de trabalho, o Grok custou 47% menos que o Sol e 58% menos que o Opus.
Esse perfil de custo torna o Grok uma opção prática para o trabalho diário de engenharia — não apenas para revisão ou experimentos ocasionais.
Por que o caminho no Bedrock muda conforme o cliente
Codex e Claude Code não usam o mesmo protocolo. O Codex usa OpenAI Responses. O Claude Code usa Anthropic Messages. O Bedrock expõe o Grok por APIs compatíveis com OpenAI Responses e Chat Completions, portanto cada cliente precisa de uma rota diferente até o mesmo modelo.
| Cliente | O que envia | Rota até o Grok no Bedrock |
|---|---|---|
| Codex | OpenAI Responses | Bedrock Runtime POST /openai/v1/responses |
| Claude Code | Anthropic Messages | Adaptador no gateway para Bedrock Runtime POST /openai/v1/chat/completions |
A documentação de endpoints do Bedrock diferencia Runtime de Mantle e mostra que o suporte às APIs varia por modelo. A implementação abaixo usa o Bedrock Runtime para os dois clientes.
- ClienteCodexEnvia Responses, ferramentas, streaming, aprovações locais e uma chave de cache por sessão.
- AcessoConexão direta ou gatewayAutentica o usuário, aplica a política de modelos e preserva o request Responses.
- InferênciaBedrock Runtime Responses → Grok 4.6O Grok escolhe as ferramentas; o Codex executa as ações aprovadas na estação de trabalho.
- ClienteClaude CodeEnvia Anthropic Messages, ferramentas, resultados de ferramentas e streaming.
- AdaptaçãoGateway + LiteLLMConverte Messages para Chat Completions, adiciona o header de cache e assina o request.
- InferênciaBedrock Runtime Chat Completions → Grok 4.6O gateway devolve o stream e os dados de uso no formato esperado pelo Claude Code.
Nos dois casos, o Grok propõe chamadas de ferramentas; ele não recebe acesso direto ao shell. Codex ou Claude Code aplica as próprias regras de sandbox e aprovação, executa a ação permitida localmente e devolve o resultado ao modelo.
1. Habilite o Grok no Amazon Bedrock
Para uma implantação nos Estados Unidos, o perfil de inferência geográfico é us.xai.grok-4.6. Usamos us-east-1 como região de origem. Consulte o perfil durante a implantação para ver os foundation models aos quais ele pode rotear:
aws bedrock get-inference-profile \
--region us-east-1 \
--inference-profile-identifier us.xai.grok-4.6O principal que chama o Bedrock precisa de bedrock:InvokeModel e bedrock:InvokeModelWithResponseStream no perfil de inferência e nos ARNs dos modelos de destino. A rota Responses também usa o recurso project/default da conta, que pode ser limitado ao perfil aprovado com bedrock:ModelArn.
O local dessas permissões depende do seu ambiente. Um desenvolvedor pode se conectar diretamente com uma API key do Bedrock ou credenciais AWS temporárias. Uma equipe pode atribuí-las à role de workload de um gateway e autenticar os engenheiros no próprio gateway. O segundo padrão centraliza identidade, allow-list de modelos, orçamento e uso; nosso artigo sobre o gateway Bedrock explica esse plano de controle mais amplo.
Se a implantação estiver fora da geografia dos Estados Unidos, altere juntos o perfil e o endpoint de origem. A matriz de perfis de inferência do Bedrock lista as regiões de origem e destino que as políticas IAM e as service control policies precisam permitir.
2. Mantenha o Codex em Responses
Nossa primeira implementação do Codex traduzia Responses para Converse. Inferência, streaming e execução de comandos funcionavam, mas o prompt caching não. Quando adicionamos os marcadores de cache do Converse, os requests do Grok começaram a falhar. A correção foi mais simples: parar de traduzir um protocolo que o Codex e o Bedrock já tinham em comum.
O Codex aceita provedores personalizados com base URL e autenticação próprias. Uma conexão direta com API key do Bedrock fica assim:
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 = falseDefina AWS_BEARER_TOKEN_BEDROCK e inicie codex --model us.xai.grok-4.6. Com um gateway, substitua a base URL e o mecanismo de autenticação, mas preserve wire_api = "responses". A referência de configuração do Codex documenta provedores personalizados, base URLs, chaves em variáveis de ambiente e autenticação por comando.
Para incluir as instruções estáveis do Codex no prefixo reutilizável do Grok, o gateway precisa de uma normalização adicional. O Codex coloca essas instruções no campo superior instructions; o gateway as move para o primeiro item developer, remove o campo original e preserva o prompt_cache_key da sessão. A conversa e os resultados de ferramentas que mudam a cada turno permanecem depois desse prefixo estável.
Antes de encaminhar o request, remova ferramentas hospedadas que o Bedrock Runtime não consegue executar e mantenha os requests do Grok síncronos, pois esse endpoint não oferece execução em background. Schemas de funções, IDs de chamadas, configurações de raciocínio, eventos de streaming e uso continuam no contrato Responses nativo.
3. Ofereça ao Claude Code um gateway compatível com Bedrock
O modo Bedrock do Claude Code envia Anthropic Messages, não Responses. Para usar o Grok, o cliente precisa de um gateway com formato Bedrock que aceite seus caminhos Invoke normais, autentique o engenheiro e traduza o tráfego do Grok antes de assinar o request upstream.
Uma configuração gerenciada mínima no cliente é:
{
"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"
}
}O helper de identidade depende do seu ambiente. O requisito de protocolo é estável: o gateway aceita os caminhos Bedrock /model/{model_id}/invoke e /invoke-with-response-stream e devolve o event stream esperado pelo Claude Code. A Anthropic documenta esse padrão nos guias de integrações com terceiros e LLM gateway.
Somente os requests destinados ao Grok precisam de tradução. Nosso gateway os envia por um adaptador LiteLLM com versão fixada que converte Anthropic Messages para OpenAI Chat Completions. O adaptador preserva mensagens de sistema, ferramentas, chamadas, resultados, streaming e uso. Também remove campos exclusivos do Anthropic e controles de amostragem rejeitados pelo perfil do Grok. Os modelos Claude podem permanecer em sua rota nativa no Bedrock.
4. Coloque a chave de cache no request HTTP real
O Grok usa controles de cache diferentes nas duas APIs. Responses recebe prompt_cache_key no corpo do request. Chat Completions usa x-grok-conv-id como header HTTP. A xAI documenta os dois em seu guia de prompt caching.
No Claude Code, derive uma chave opaca e estável a partir do modelo, do system prompt e das definições de ferramentas reutilizáveis — não do turno variável do usuário:
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,
)O defeito mais difícil não aparecia no payload intermediário. Nosso primeiro adaptador colocou x-grok-conv-id dentro do JSON. A saída do transformador parecia correta, mas o request HTTP assinado não continha o header. O Bedrock, portanto, nunca recebia a chave de roteamento.
A correção extrai a chave de cache permitida antes da serialização, adiciona-a aos headers HTTP antes da assinatura SigV4 e remove os campos internos de roteamento do corpo JSON. O teste de regressão agora inspeciona o request final preparado, não apenas o objeto intermediário.
Na volta, preserve os dados de uso do cache durante o streaming e traduza-os para o campo esperado por cada cliente. Tokens em cache são um subconjunto dos tokens de entrada; subtraia-os antes de contabilizar a entrada comum ou o gateway contará os mesmos tokens duas vezes. Depois dessa correção, Codex e Claude Code registraram leituras de cache do provedor pelo caminho de produção.
A escolha do modelo não deveria impor a ferramenta
Depois da implantação, os engenheiros passaram a usar o Grok no Codex ou no Claude Code sem mudar seus fluxos de repositório, ferramentas ou aprovação. A equipe de plataforma manteve um único ponto para identidade, política de modelos, orçamento e contabilização de uso. O Amazon Bedrock permaneceu como fronteira de inferência.
Esse é o resultado que vale a pena projetar. O engenheiro escolhe o cliente mais adequado ao trabalho, a equipe ganha um modelo capaz com custo menor e um novo modelo não exige outra implantação de ferramenta.
Se você quer oferecer o Grok no Codex e no Claude Code em seu ambiente AWS, a Elevata pode projetar e validar o acesso ao Bedrock, o gateway, a tradução de protocolos e a implantação nos clientes.
