Fable 5.1 ou GPT-6 Astra: qual sai mais barato em agente que roda por horas?

Preço de tabela igual não significa conta igual no fim do mês

Fala aí, beleza? O Claude Fable 5.1 saiu no dia 1 de setembro de 2026 e o GPT-6 Astra chegou dois dias depois, em 3 de setembro de 2026. Os dois cobram exatamente US$ 10 por milhão de tokens de entrada e US$ 50 por milhão de tokens de saída na API padrão

Quem abre as duas páginas de preço lado a lado fecha o navegador achando que deu empate técnico

Só que agente não é chat. Ele roda por horas, e a cada passo o histórico inteiro volta pra dentro do request. Aí a conta sai da linha de entrada e vai morar na linha de cache, que é justamente onde os dois divergem

Bora ver os números?

Fable 5.1 x GPT-6 Astra: preços, cache e limites lado a lado

Olha o detalhe que a tabela esconde: no Fable 5.1 a leitura de cache equivale a 2,5% do preço base de entrada, enquanto os demais modelos Claude cobram 10% por isso. É uma queda de 75% em relação ao US$ 1,00 por milhão que o Fable 5 cobrava

Resultado: com o MESMO preço base de entrada, a leitura de cache do Fable 5.1 sai 4x mais barata que a do GPT-6 Astra 😀

Por que o cache decide a conta de um agente que roda por horas

Primeiro o porquê, depois o como

Em execução longa, cada passo do agente reenvia todo o contexto acumulado: instruções, histórico de ferramentas, arquivos lidos, resultado dos passos anteriores. O que é novo naquele passo costuma ser um pedacinho, tipo o retorno de um comando

Então o volume de tokens que passa pela leitura de cache cresce MUITO mais rápido que o volume de entrada nova

Se você conhece build com cache de dependências, é a mesma lógica: o que decide o tempo total não é compilar o arquivo que você mudou, é o que você consegue reaproveitar do que já estava pronto

A própria Anthropic estima que o corte no cache read reduz o custo em torno de 25% para cargas típicas e até cerca de 45% para cargas altamente agênticas. Isso bate com a natureza do problema: quanto mais o agente roda, mais a linha de cache domina a fatura, e a leitura de cache mais barata no Fable 5.1 pesa mais que qualquer outra linha

Onde essa diferença aparece de verdade:

• loop de código, com o agente lendo, editando e rodando teste em ciclo
• computer use, onde cada passo carrega o estado anterior
• pesquisa longa, com o histórico só engordando a cada fonte lida

E onde ela quase não aparece:

• chamada única de alto volume, sem reuso de prefixo

Nesse último caso os dois empatam mesmo, porque a conta fica quase toda em entrada e saída, e ali o preço é idêntico

Duas armadilhas que mudam o resultado: o limite de 272 mil tokens e o turno extra

Antes de você sair migrando tudo pro Fable 5.1, tem duas coisas que podem inverter a comparação

A primeira é do lado do GPT-6 Astra. Requisições acima de 272 mil tokens de entrada são cobradas a 2x na entrada e nas taxas de cache, e 1,5x na saída. E vale para a requisição INTEIRA, não só para o excedente

Ou seja: agente que deixa o contexto inflar sem poda passa a pagar dobrado até no que veio do cache. Tome cuidado com isso, porque o estouro é silencioso, ele não te avisa antes de virar a chave

A segunda é do lado do Fable 5.1. Em agentes de código customizados, harnesses bash/editor e computer use, chamadas independentes implícitas podem sair uma por turno

E cada turno extra custa tokens, um round trip e tempo

Sacou o problema? Um modelo com cache read 4x mais barato pode acabar entregando a mesma tarefa em mais idas e voltas, e cada ida reenvia contexto. Preço por token e número de turnos são duas variáveis diferentes, e as duas caem na mesma fatura

Como instrumentar sua aplicação para medir cache de verdade

Não dá pra decidir isso no chute. As duas APIs devolvem os campos que você precisa, então bora ligar o medidor

1. Do lado da Anthropic, leia os três campos de uso em cada resposta. São eles: cache_read_input_tokens (tokens lidos do cache), cache_creation_input_tokens (tokens escritos no cache) e input_tokens (tokens depois do último breakpoint)

O erro comum deste passo: logar só o total de tokens da requisição. Total não distingue token lido de cache de token novo, e é exatamente essa proporção que decide a sua conta

2. Abra o usage.cache_creation para separar as durações. Ele traz os subcampos ephemeral_5m_input_tokens e ephemeral_1h_input_tokens, que são cobrados em taxas diferentes

O erro comum: somar tudo como "escrita de cache" e aplicar uma taxa só, quando o cache de 5 minutos custa 1,25x o input base e o de 1 hora custa 2x

3. Ative o cache estendido quando o agente passa dos 5 minutos padrão. Sem o campo ttl dentro de cache_control, a vida mínima é de 5 minutos

"cache_control": { "type": "ephemeral", "ttl": "1h" }

O erro comum: agente que fica 15 minutos numa etapa pesada e reescreve o cache do zero toda vez, porque ninguém mexeu no ttl

4. Use a página de diagnóstico da plataforma quando o número não fechar. A documentação do Claude tem uma página dedicada a isso, a Cache diagnostics, em platform.claude.com/docs/en/build-with-claude/cache-diagnostics

5. Do lado da OpenAI, entenda que o cache é automático. Ele ativa a partir de 1.024 tokens, os acertos acontecem em incrementos de 128 tokens e o prefixo repetido precisa ser idêntico

O erro comum: variar o começo do prompt a cada passo (timestamp, id de sessão, qualquer coisinha) e matar o cache hit sem perceber. Prefixo estável é regra, não sugestão

6. Leia usage.prompt_tokens_details.cached_tokens em cada requisição. É o campo que te diz quanto veio do cache

resp = client.responses.create(model="gpt-6-astra", input=mensagens)
print(resp.usage.prompt_tokens_details.cached_tokens)

O erro comum: ver zero e achar que o cache está quebrado. Em requisições com menos de 1.024 tokens o valor É zero, ponto

7. Não confie no prompt_cache_key como garantia. Ele ajuda requisições com o mesmo prefixo a chegarem no mesmo cache, mas influencia roteamento e não garante cache hit

O erro comum: setar a chave, parar de medir e assumir que está tudo cacheado

8. Se você veio do GPT-5.5 ou anterior, troque o campo de retenção. O prompt_cache_retention está descontinuado e foi substituído pelo prompt_cache_options.ttl, cujo único valor suportado e padrão é "30m". O prefixo cacheado fica elegível por 30 minutos após a última escrita ou reuso

O erro comum: migrar o modelo, esquecer o campo antigo no payload e ficar caçando fantasma no log

Como estimar a conta antes de rodar o agente por horas

Com os campos instrumentados, a estimativa vira aritmética. Vamos ver na prática?

1. Separe os quatro baldes de token de uma execução: entrada nova, leitura de cache, escrita de cache e saída. Sem essa separação a estimativa não existe, ela vira achismo

2. Multiplique cada balde pela taxa do modelo. No Fable 5.1: US$ 10 por milhão de entrada nova, US$ 0,25 por milhão de leitura de cache, US$ 12,50 por milhão de escrita no cache de 5 minutos ou US$ 20,00 no de 1 hora, e US$ 50 por milhão de saída. No GPT-6 Astra: US$ 10 de entrada nova, US$ 1,00 de leitura de cache, US$ 12,50 de escrita e US$ 50 de saída

3. Aplique os multiplicadores antes de fechar a conta. No Astra, se a requisição passar de 272 mil tokens de entrada, dobre entrada e cache e multiplique a saída por 1,5 no request inteiro. Se você usa Batch ou Flex, corte 50% do Standard; no Fast, dobre

O erro comum deste passo: calcular no preço Standard e rodar no Fast

4. Converta para real por último, usando US$ 1 = R$ 5,13. Some tudo em dólar primeiro e só então aplique o câmbio, senão o arredondamento vaza pra cada linha da conta. E repare que a diferença que sobrevive à conversão é sempre a mesma: leitura de cache a US$ 0,25 por milhão de um lado, US$ 1,00 do outro, com saída idêntica nos dois

Lembrando que os dois faturam em dólar, então esse valor em real é conversão, não preço oficial

5. Não esqueça a escrita de cache. Esse é o erro que mais dói: escrever no cache é MAIS caro que a entrada normal nos dois lados, 1,25x, e 2x no cache de 1 hora do Fable 5.1

Ou seja, cache que nunca é reusado sai mais caro do que não cachear nada. Se o seu prefixo muda toda hora, você está pagando 12,50 pra guardar algo que ninguém vai ler 😛

O que eu vi acompanhando um agente rodando de ponta a ponta

Aqui eu preciso ser honesto sobre o que é e o que não é: no vídeo abaixo eu testo Fable 5 e GPT-5.6 Sol, outra geração de modelos, não o Fable 5.1 e o GPT-6 Astra deste post. Nada ali é benchmark de custo dos dois modelos comparados aqui

Mas o que eu vi acompanhando aquilo rodando explica bem POR QUE a linha de cache importa tanto

Eu montei o teste com o mesmo projeto, os mesmos prompts e configurações equivalentes, as duas ferramentas no nível máximo de raciocínio. Deixei de ativar um recurso extra de entrega rápida que só uma delas tinha, pra não desequilibrar, e rodei ignorando permissões pra não travar em confirmação

A ferramenta da OpenAI concluiu a primeira etapa, a landing page, em 11 minutos

O acompanhamento seguiu com a tarefa ainda rodando aos 12 minutos

E passados mais de 20 minutos, a concorrente ainda não tinha entregue o resultado final pra teste

No meio disso, uma única etapa consumiu cota de 100% para 83%

É isso que você sente na pele quando o agente roda por horas: tempo de execução e cota derretendo, sem visibilidade nenhuma do que ainda falta. Uma delas informa o que está fazendo, mas não mostra a fila do que ainda vai executar, e você fica no escuro

Minha opinião depois daquele teste: raciocínio máximo nem sempre compensa o tempo gasto. No dia a dia eu prefiro um nível acima do normal, não o topo

Veredito: quando escolher Fable 5.1 e quando o GPT-6 Astra faz sentido

Sem enrolação, por perfil de carga

Fable 5.1 leva em agente de execução longa com prefixo estável. Leitura de cache 4x mais barata com o mesmo preço base de entrada é uma vantagem que só cresce com o tempo de execução, e a opção de cache de 1 hora cobre etapa pesada que estoura os 5 minutos padrão

GPT-6 Astra faz sentido em carga com pouco reuso de prefixo. Se a linha de cache quase não é acionada, o preço base empata e a discussão acaba. Some a isso Batch e Flex a 50% do Standard, que é um corte direto pra quem processa em lote e não precisa de resposta na hora

E tem o que a tabela NÃO decide: qualidade da saída e número de turnos. Um modelo que resolve a tarefa em menos idas e voltas pode sair mais barato mesmo com token mais caro, e antes de comparar topo de linha vale checar quando um modelo mais barato basta pra mesma tarefa

Se você está migrando pro Fable 5.1, duas mudanças de API que quebram código na hora:

• escolha forçada de ferramenta não é mais suportada: tool_choice do tipo any ou tool retorna erro 400. A orientação é usar auto com instrução explícita, ou saídas em JSON
• thinking: {type: "disabled"} retorna 400 em claude-fable-5-1

Já me ferrei com esse tipo de coisa antes: o modelo troca, o payload continua igual e você passa a tarde caçando um 400 que estava documentado o tempo todo

Conclusão

A resposta do Fable 5.1 vs GPT-6 Astra não está na tabela de preço, ela está no seu log de cache

Os dois cobram US$ 10 de entrada e US$ 50 de saída por milhão. O que muda a fatura de um agente que roda por horas é quanto do seu contexto é lido do cache (US$ 0,25 contra US$ 1,00 por milhão), quanto você escreve nesse cache sem reusar, e quantos turnos a tarefa leva

Próximo passo prático: instrumente cache_read_input_tokens, cache_creation_input_tokens e input_tokens de um lado e usage.prompt_tokens_details.cached_tokens do outro, deixe rodar uma semana de execução real, calcule a proporção entre leitura de cache e entrada nova

Com esse número na mão a escolha se faz sozinha

Ah, e uma nota pra fechar: Fable 5.1 e Mythos 5.1 são o mesmo modelo com níveis diferentes de salvaguardas. O Fable 5.1 é o de disponibilidade geral, o Mythos 5.1 só sai via programas de acesso confiável para organizações de cibersegurança e ciências da vida

Então é o Fable 5.1 que vai estar na sua conta mesmo, beleza? até o próximo post!