Opus 5 ou Fable 5: a decisão é de roteamento, não de modelo

O que a tabela oficial diz, e o que ela não diz

Os dois modelos compartilham o essencial da ficha técnica. Janela de contexto de 1 milhão de tokens, 128 mil tokens de saída máxima, e a mesma escala de esforço configurável, de baixo a máximo, segundo a documentação da Anthropic.

A diferença de posicionamento está declarada. A Anthropic descreve o Fable 5 como seu modelo mais capaz de disponibilidade ampla, indicado para o raciocínio mais exigente e para trabalho agêntico de horizonte longo. O Opus 5 é descrito para codificação agêntica complexa e trabalho corporativo, com metade do custo do Fable 5.

O que a tabela não diz é o que decide a conta na operação. Preço por token não é preço por tarefa. Uma tarefa que o modelo mais caro resolve em uma passagem pode custar menos que a mesma tarefa repetida três vezes no modelo mais barato, com revisão humana no fim.

O inverso também é verdade, e é o caso mais comum. Rotinas de classificação, extração e resposta padronizada não melhoram com o topo de linha. Elas só ficam duas vezes mais caras.

O esforço é a alavanca que quase ninguém puxa

Os dois modelos aceitam um parâmetro de esforço, com cinco níveis documentados, de baixo a máximo. Ele controla a profundidade de raciocínio e o volume total de tokens gastos. É a alavanca de custo mais direta que existe, e é a menos usada.

A documentação da Anthropic é explícita sobre a assimetria. Nos níveis baixo e médio, os modelos da geração atual entregam resultado que, em muitos casos, supera o desempenho de topo dos modelos anteriores. Subir o esforço nem sempre melhora a resposta, e às vezes produz deliberação além do que a tarefa pede.

Na prática de operação isso significa uma coisa. A escolha não é binária entre dois modelos. É uma matriz entre dois modelos e cinco níveis de esforço, com dez combinações de custo e latência para a mesma pergunta.

A restrição que elimina a escolha antes do custo

Existe um critério que decide sozinho, e ele não é técnico nem financeiro. É de governança de dados.

A Anthropic documenta que o Fable 5 exige retenção de dados por 30 dias e não está disponível sob retenção zero. Organizações com política de retenção zero recebem erro em toda requisição, independentemente do payload. Não é degradação, é indisponibilidade.

A disponibilidade por plataforma também difere. O Opus 5 é ofertado na API da Anthropic, na Amazon Bedrock, no Google Cloud e no Microsoft Foundry. O Fable 5 é ofertado na API da Anthropic. Para uma operação que já padronizou a nuvem por contrato, isso encerra a discussão.

A ordem correta de decisão inverte o hábito do mercado. Primeiro a restrição de governança, depois o custo por tarefa, e só então a capacidade do modelo.

O que muda no dia a dia da operação

Três diferenças operacionais aparecem na documentação e afetam quem sustenta o sistema em produção.

A primeira é o comportamento de raciocínio. No Fable 5, o raciocínio é sempre ativo e não pode ser desligado, e a cadeia bruta nunca é devolvida. No Opus 5, o raciocínio vem ligado por padrão e pode ser desligado apenas nos níveis mais baixos de esforço. Quem dimensionou o limite de saída sem contar o raciocínio vê resposta truncada.

A segunda é o cache de prompt. No Opus 5, o prefixo mínimo que o sistema aceita cachear cai para 512 tokens, metade do modelo anterior. Prompts antes curtos demais para cachear passam a gerar economia sem nenhuma mudança de código.

A terceira é a recusa. Os dois modelos podem recusar uma requisição por classificador de segurança, devolvendo status de sucesso com motivo de parada declarado como recusa. Código que lê o conteúdo da resposta sem checar o motivo de parada quebra em produção.

• Raciocínio sempre ativo no Fable 5, configurável no Opus 5.
• Cache de prompt a partir de 512 tokens no Opus 5.
• Recusa por classificador exige tratamento e rota de contingência nos dois.

O roteador é a peça de engenharia, não o modelo

Uma operação que trata modelo como decisão única fica presa ao preço do fornecedor e ao ciclo de lançamento dele. Uma operação que trata modelo como insumo constrói a camada que escolhe.

Essa camada tem três responsabilidades. Classificar a pergunta antes de gastar, rotear para o par de modelo e esforço que atende ao requisito, e registrar custo e resultado por tarefa para que a política de roteamento evolua com dado próprio.

Sem ela, a empresa paga o topo de linha para responder pergunta de rotina, e descobre isso na fatura do trimestre seguinte. Com ela, a troca de modelo vira parâmetro de configuração, não projeto.

Na NN, essa camada é o que construímos e mantemos. O modelo é escolhido pela pergunta, não pelo lançamento mais recente do fornecedor, e a operação do cliente comanda o roteamento pelo painel.