Migrando agentes do GPT-5.6 Terra para o GPT-6.1 Terra no Bedrock

O cenário que uso como referência é comum em ambiente financeiro: um agente interno que lê políticas, consulta dois ou três sistemas por tool-use e devolve JSON estruturado para um fluxo em Step Functions. Ele roda em bedrock-runtime com o perfil us.openai.gpt-5.6-terra, porque a área de risco não aceita roteamento global, e o perfil geográfico dos EUA, com origem na Virgínia, fica restrito a us-east-1, us-east-2 e us-west-2.

Uma execução típica tem cerca de 40 mil tokens de entrada, dos quais 30 mil são prefixo estável (instruções, definição das ferramentas, trechos de política), e 3 mil tokens de saída. Com o preço de tabela do 5.6 Terra em US CRIS (US$ 2,20 por milhão de entrada, US$ 0,22 por milhão de leitura de cache e US$ 13,20 por milhão de saída), essa execução custa perto de US$ 0,068 em regime estável. Parece pouco até multiplicar por 200 mil execuções por mês: são cerca de US$ 13,6 mil só de inferência.

Esses números são conta sobre preço publicado, não medição de cliente. Servem para dimensionar a decisão. O que pesa de verdade é o calendário: o model card do 5.6 Terra garante EOL não antes de 13/07/2027, com período legado de pelo menos seis meses. Há tempo, mas não há folga para uma migração feita às pressas no último trimestre, que é exatamente quando o time está ocupado com outra coisa.

O anúncio fala de capacidade, velocidade e preço. O model card fala de operação, e é nele que mora o risco da migração. Comparando os dois cards lado a lado, quatro diferenças mudam o desenho.

Região no bedrock-mantle: o 5.6 Terra roda in-Region no endpoint bedrock-mantle em us-east-1, us-east-2, us-west-2 e nas duas regiões GovCloud. O 6.1 Terra, no lançamento, só em us-east-1. Quem usa o SDK da OpenAI apontado para bedrock-mantle.us-west-2.api.aws não migra trocando uma string.

Região de origem no bedrock-runtime: a tabela do 6.1 Terra não lista sa-east-1 nem me-central-1 como origem do perfil global, e não traz o perfil geográfico in. que o 5.6 Terra oferece para Mumbai e Hyderabad. Para quem chama de São Paulo, isso decide onde o cliente da carga precisa rodar.

API Invoke: a tabela de APIs do 6.1 Terra marca InvokeModel como suportado no bedrock-runtime; a do 5.6 Terra marca como não suportado. Isso abre caminho para quem tem código legado em Invoke, mas não muda as restrições de Guardrails e de perfis de aplicação, que continuam presas ao Converse.

Tiers de serviço: só Standard. Sem Priority, Flex ou Reserved. Se o seu plano de capacidade dependia de reservar throughput, ele não existe para este modelo hoje.

Nada disso aparece no What's New. Anúncio é gatilho; o contrato operacional está na documentação.

No bedrock-runtime, o model card do 6.1 Terra amarra recursos a APIs diferentes, e eles não se somam. Guardrails só funcionam pelo Converse. Perfis de inferência de aplicação, que é como você atribui custo por time com tags, também só pelo Converse. Já o cache explícito só existe no Responses. No Converse você fica com o cache implícito, que a própria documentação chama de best effort.

Há duas restrições a mais no Converse: ele não aceita bloco document e rejeita imagem dentro de toolResult com ValidationException. Um agente que devolve captura de tela de uma ferramenta para o modelo quebra na primeira chamada.

O custo dessa escolha é calculável. No cenário de referência, o prefixo de 30 mil tokens custa US$ 0,033 sem cache e US$ 0,00165 com leitura de cache, a US$ 1,10 e US$ 0,055 por milhão. Cada miss custa 20 vezes mais no prefixo. Se o cache implícito acertar 60% e o explícito 95%, a diferença em 200 mil execuções por mês fica perto de US$ 2,2 mil.

Use o Converse quando Guardrails da AWS e alocação de custo por perfil de aplicação forem exigência de auditoria, e meça o acerto real por cacheReadInputTokens antes de aceitar a perda. Use o Responses quando o prefixo for grande e estável e a filtragem de conteúdo já acontecer em outra camada que você controla. Fazer metade da frota em cada API sem decidir é o pior caso: duas trilhas de auditoria, dois modelos de custo.

O desconto de preço é a parte fácil. O que derruba a migração é a quota. No bedrock-runtime, o limite é medido em tokens por minuto com burndown de 10x na saída: cada token de saída consome 10 da quota. Tokens lidos do cache não contam na quota de entrada. No cenário de referência, uma execução consome 10 mil tokens de entrada sem cache mais 30 mil equivalentes de saída. Três quartos da quota vão para a saída.

Isso cria um modo de falha silencioso. Se o modelo novo responder com 20% mais tokens de saída, porque raciocina mais ou escreve mais, o custo ainda cai bastante e nenhum alarme de FinOps dispara. A quota, porém, sobe 15% por execução, e o primeiro sinal é ThrottlingException no pico da manhã. Por isso o canário observa OutputTokenCount e InvocationThrottles no CloudWatch, não só a fatura.

O segundo custo tardio é o contexto longo. O 6.1 Terra aceita 1.050.000 tokens de contexto (a página da OpenAI fala em 922 mil de entrada máxima), mas acima de 272 mil tokens de entrada a requisição inteira muda de faixa: entrada a US$ 2,20 e saída a US$ 8,25 por milhão em US CRIS. Um agente que acumula histórico sem resumir atravessa essa linha na vigésima volta e dobra o custo de entrada daquela chamada em diante. Coloque um teto explícito de histórico, perto de 250 mil tokens, e resuma acima dele. Ter 1 milhão de tokens de contexto não obriga ninguém a usar 1 milhão.