GPT-6 Astra no Bedrock: o endpoint decide o que você audita

O model card é mais informativo que o anúncio. openai.gpt-6-astra tem janela de 1.050.000 tokens de entrada, teto de 128.000 tokens de saída e knowledge cutoff em 30 de abril de 2026. Entrada aceita texto e imagem; saída é só texto, quem esperava geração de imagem ou áudio pelo mesmo model ID vai bater numa parede. EOL não antes de 8 de setembro de 2027, com período legacy de pelo menos 6 meses: isso é um ano de piso contratual para planejar migração, e é o tipo de dado que deveria entrar no seu ADR, não no seu slide.

A superfície de API é menor do que parece. No bedrock-runtime, o modelo responde por Converse, Responses e Chat Completions, e não por InvokeModel. Se o seu wrapper interno padronizou tudo em InvokeModel para ter um único ponto de instrumentação, ele não chama Astra. No bedrock-mantle, só Responses e Chat Completions, servidos em /openai/v1/responses e /openai/v1/chat/completions.

Service tier único. Só Standard. Priority, Flex e Reserved aparecem como não suportados. Não existe throughput reservado para segurar latência de pico, e não existe faixa Flex para amortecer lote noturno. Toda a sua carga divide a mesma fila pay-per-token, e o seu controle sobre latência de cauda é escolher a Região e nada mais.

O preço de Astra não é um par de números; é uma matriz de duas dimensões, e as duas são decisão de arquitetura.

Dimensão 1, o perfil de inferência. Global CRIS custa US$ 10,00 por 1M de tokens de entrada e US$ 50,00 de saída. In-Region e Geo CRIS custam US$ 11,00 e US$ 55,00. Você paga 10% a mais exatamente para ganhar controle sobre onde a inferência acontece. É o preço explícito da residência, e é barato perto de uma multa.

Dimensão 2, o corte em 272K. Acima de 272.000 tokens de entrada, a requisição inteira reprecifica: US$ 20,00 de entrada e US$ 75,00 de saída no global, US$ 22,00 e US$ 82,50 no in-Region. Não é o excedente que muda de faixa, é tudo. Um prompt de 280.000 tokens no global custa US$ 5,60 de entrada; o mesmo prompt cortado para 270.000 custa US$ 2,70. Uma diferença de 3,7% no tamanho vira 107% na fatura.

E você não tem CountTokens. A lista do bedrock-runtime marca CountTokens e structured outputs como não suportados para este modelo. Ou seja: existe um penhasco de preço a 272.000 tokens e não existe API oficial para saber de que lado dele o seu payload caiu antes de enviar. A contagem precisa acontecer no seu código, com o tokenizer certo e uma margem de segurança, e o teto tem que ser um parâmetro, não um número solto no meio da função.

A quota é uma terceira moeda. O burndown é 10x: 1 token de saída consome 10 unidades de TPM. Um run que gera os 128.000 tokens de teto queima 1.280.000 unidades: 4,7 vezes o que custa, em quota, ler 272.000 tokens de entrada. Em agente, saída é o recurso escasso, não contexto.

O cache de prompt dos modelos OpenAI no Bedrock não é o mesmo mecanismo dos Claude. Não existe cachePoint no Converse: você marca "prompt_cache_breakpoint": {"mode": "explicit"} num bloco de conteúdo da Responses API, com prefixo mínimo de 1.024 tokens e até 4 breakpoints. O prompt_cache_options.mode decide o comportamento: implicit (padrão) coloca um breakpoint automático na última mensagem além dos seus; explicit desliga o automático, e se você não declarar nenhum breakpoint, a requisição simplesmente não usa cache e nem cobra escrita. TTL mínimo de 30 minutos, controlado por prompt_cache_options.ttl.

A economia é agressiva e o break-even é imediato. Escrita custa 1,25x a entrada não cacheada; leitura custa 10% dela. Num prefixo estável de 40.000 tokens, instruções, definições de ferramenta, documentos de referência, rodando 30 chamadas dentro da mesma janela de 30 minutos no bedrock-mantle: sem cache, 30 × 40.000 × US$ 11,00/1M = US$ 13,20. Com cache, US$ 0,55 de escrita mais 29 leituras de US$ 0,044 = US$ 1,83. Queda de 86%, e a segunda chamada já pagou a escrita.

Tem mais um detalhe que muda capacity planning: tokens lidos do cache não contam contra a quota de input-tokens-por-minuto. Cache aqui não é só desconto, é headroom.

O problema é onde ele mora. Para Astra, o model card lista Implicit e Explicit Prompt Caching apenas no bedrock-mantle, via Responses API. E bedrock-mantle para Astra existe só em us-west-2, sem perfil geográfico e sem perfil global.

Aqui a análise deixa de ser sobre custo. A Responses API guarda estado por padrão: com store em true, que é o default, para bater com a especificação da OpenAI, o Bedrock retém a requisição e a resposta por 30 dias, para permitir previous_response_id. E a documentação é direta sobre onde: a resposta fica na Região que processou a requisição. Com perfil global, isso é qualquer Região comercial para onde o perfil roteou.

Traduzindo para quem opera sob BACEN e LGPD: em sa-east-1, Astra existe apenas por perfil global. Não há in-Region, não há Geo. Uma equipe em São Paulo que chame Astra está aceitando roteamento mundial e, no default, retenção de entrada e saída por 30 dias fora do país. O caminho geográfico us.openai.gpt-6-astra cobre cinco Regiões, us-east-1, us-east-2, us-west-1, us-west-2 e ca-central-1, e nenhuma delas é Brasil. Hoje não existe caminho de residência nacional para este modelo. A mitigação é store explicitamente em false em toda requisição, ou o modo de retenção da conta em none, que rejeita store=true. Mas retenção nula custa a conversa multi-turno stateful, que é justamente por que muita gente foi para a Responses API.

E tem uma armadilha de IAM. Os dois endpoints autorizam ações de namespaces diferentes: bedrock:InvokeModel de um lado, bedrock-mantle:CreateInference do outro. Uma SCP escrita como "Action": "bedrock:" para restringir quais modelos a organização pode invocar simplesmente não casa com bedrock-mantle:. Some a isso o comportamento das condition keys: bedrock:ModelArn vale o perfil que a requisição nomeou, nunca os modelos de destino para onde o CRIS roteou. Você não consegue restringir Região de processamento por policy no alvo; consegue só escolhendo o perfil certo.