Como trocar de modelo em uma tarefa do agente Fable 5.2 sem perder progresso

Quando um agente deixa o Fable 5.2 e passa a outro modelo, preserve seu estado verificado da tarefa separadamente do histórico da conversa. O novo modelo precisa das entradas, dos resultados de ferramentas já concluídas, do trabalho pendente e das condições de aceitação. Um resumo legível do que o modelo anterior “estava pensando” não é um substituto confiável.

Testamos esse padrão pela Ofox em 10 de novembro de 2026: o Fable 5.2 solicitou uma consulta de estoque somente de leitura, recebeu três linhas sintéticas e concluiu seu ciclo nativo de ferramenta. Depois iniciamos uma nova conversa com Opus 5.5, usando um checkpoint gerado pela aplicação. O JSON final passou por verificações independentes de cada SKU e quantidade. Isso demonstra um pequeno fluxo de transferência de estado, não um benchmark de agente com horas de duração nem preservação de raciocínio oculto.

Por que um fallback bem-sucedido ainda pode perder estado útil

A documentação oficial de preserved thinking diferencia compatibilidade do modelo de progresso da aplicação. Nas rotas documentadas da Claude API e gerenciadas pelo Google, modelos antigos não leem blocos de thinking do Fable 5.2; blocos incompatíveis podem ser descartados mesmo quando a requisição tem sucesso. O vínculo com a conta cria outra fronteira quando uma conta diferente processa a continuação.

Essas regras não tornam toda troca de modelo um erro. Elas significam que sucesso HTTP não comprova continuidade do raciocínio. O catálogo da Ofox lista capacidades de roteamento, mas não comprova o comportamento de toda transferência de histórico assinado entre provedores ou contas. Não testamos reprodução entre contas, e nossa transferência evita depender disso deliberadamente.

Há duas estratégias distintas. Continue uma conversa sem alterações por uma rota compatível e verificada quando for apropriado preservar esse histórico. Ou abra uma nova conversa com estado controlado pela aplicação ao mudar deliberadamente modelos, ferramentas ou configuração da tarefa. Este tutorial implementa a segunda estratégia; não modifica assinaturas nem reconstrói thinking privado.

Baixe o pequeno exemplo reproduzível

Baixe checkpoint_demo.py. Ele usa Python 3.9 ou posterior e a biblioteca padrão. As verificações padrão não fazem chamadas de API. Coloque o arquivo em uma pasta vazia para que os arquivos gerados não sobrescrevam uma tarefa existente.

Para o fluxo completo de requisição de ferramenta ao Fable → continuação com resultado → nova sessão Opus, baixe também run_handoff.py na mesma pasta. Execute python3 run_handoff.py apenas para verificações locais. Depois de configurar OFOX_API_KEY, python3 run_handoff.py --live faz explicitamente até três requisições pagas, salva requisições e respostas em uma nova pasta handoff-run e valida o resultado final. Não há tentativas automáticas, e o programa se recusa a reutilizar essa pasta de saída. Inspecione tentativas falhas ou incertas antes de iniciar outra execução.

Cada requisição é limitada a 4.096 tokens de saída e a um pequeno corpo sintético. Esses limites restringem a demonstração; não são um teto universal de gasto em dólares nem garantia de que uma requisição com timeout foi gratuita. O programa publicado segue a sequência de requisições testada; suas verificações locais e a serialização foram verificadas separadamente.

python3 checkpoint_demo.py self-test
python3 checkpoint_demo.py prepare

O primeiro comando executa testes positivos e negativos. O segundo cria checkpoint.json e handoff.txt, recusando substituir arquivos existentes. Os dados são uma massa sintética de estoque, não estoque de clientes nem recomendação de negócio:

A tarefa é informar max(target − available, 0) para cada linha. Fazer pedidos é explicitamente proibido. Manter a linha com falta zero faz parte da tarefa: uma resposta que liste apenas produtos que precisam de reposição está incompleta neste caso.

Salve evidências antes de pedir que outro modelo continue

O checkpoint registra o objetivo, um hash das linhas de origem, uma operação de leitura concluída, seu resultado real e hash, o trabalho pendente e a proibição de escritas externas. A aplicação cria esse registro a partir do resultado da ferramenta. Não pede ao modelo que certifique suas próprias ações.

{
  "schema_version": 1,
  "task_id": "synthetic-stock-20261110",
  "objective": "Report shortage=max(target-available,0) for every SKU. Do not place orders.",
  "completed": [{
    "operation_id": "read-stock-1",
    "operation": "read_stock",
    "status": "verified"
  }],
  "pending": ["Produce all three SKU shortage rows", "Pass independent validator"],
  "side_effects": []
}

O trecho omite hashes de origem e linhas de resultado para facilitar a leitura; o arquivo gerado contém esses dados. Use o arquivo completo na execução. Um hash detecta divergências em relação à fonte em que você confia; não comprova autoria, atualização do estoque nem segurança de um checkpoint não confiável. Em produção, preserve também a versão oficial da entrada e os controles de acesso.

Em um agente real, persista o checkpoint ao concluir uma operação de ferramenta. Registre o ID da chamada para associá-la à conversa e um ID de operação estável separado para o registro da aplicação. Eles têm funções diferentes. Um novo modelo pode criar outro ID de chamada para a mesma operação lógica; portanto, um ID gerado pelo provedor, sozinho, não impede ações duplicadas de forma geral.

O ciclo de ferramenta do Fable que foi testado

A primeira requisição usou anthropic/claude-fable-5.2, o endpoint Messages nativo da Ofox, output_config.effort: "low", max_tokens: 4096 e uma única ferramenta read_stock com esquema de entrada de objeto vazio. A escolha de ferramenta foi auto.

A resposta terminou com tool_use e solicitou read_stock com {}. Nosso programa verificou nome e argumentos, retornou as três linhas sintéticas com o tool_use_id correspondente e preservou todo o conteúdo do assistente. A segunda requisição ao Fable terminou com end_turn e informou faltas de 3, 0 e 4.

Essa continuação nativa importa: um checkpoint não corrige um loop de ferramentas quebrado. Se a requisição ao mesmo modelo falhar por ID sem correspondência, corrija primeiro a associação de resultados de ferramentas, guia em inglês. Se a falha mencionar histórico assinado, use o diagnóstico de assinaturas de thinking, em inglês e as verificações de atualização para 5.2.

Usamos esforço baixo intencionalmente nessa conta pequena com dados sintéticos. Isso não indica o esforço necessário para uma tarefa longa e difícil. Além disso, o catálogo listar aws_bedrock como provedor não comprova uma conta upstream específica em uma resposta específica; o que registramos foi o endpoint nativo da Ofox e o ID do modelo retornado.

Inicie o modelo de destino com uma transferência explícita

O arquivo gerado handoff.txt contém:

Resume this read-only task from verified application state.
Do not claim access to prior reasoning.
Do not call tools or place orders.
Return only a JSON object with key rows, containing every SKU
and integer shortage. No Markdown.
Checkpoint: [the complete generated checkpoint JSON]

Crie a requisição ao modelo de destino a partir desse arquivo. Executar este exemplo consome créditos de API; os comandos de preparação local acima não consomem.

import json
from pathlib import Path

request = {
    "model": "anthropic/claude-opus-5.5",
    "max_tokens": 4096,
    "output_config": {"effort": "low"},
    "messages": [{"role": "user", "content": Path("handoff.txt").read_text()}],
}
Path("handoff-request.json").write_text(json.dumps(request))

curl --fail-with-body --max-time 180 \
  https://api.ofox.ai/anthropic/v1/messages \
  -H "x-api-key: $OFOX_API_KEY" \
  -H 'anthropic-version: 2023-06-01' \
  -H 'content-type: application/json' \
  --data-binary @handoff-request.json > handoff-response.json

Essa requisição não contém mensagens anteriores do assistente nem blocos de thinking assinados. Ela retoma a tarefa, não a mesma conversa do provedor. Por isso, a troca de modelo aqui não exige editar o prefixo antigo. Uma tarefa maior precisa de um conjunto de evidências mais rico, com localização das fontes e perguntas pendentes, em vez de uma narrativa enorme e não verificada.

Valide o resultado entregue de forma independente

Extraia apenas o texto concluído, interprete-o como JSON e execute o validador fornecido:

import json
from pathlib import Path

r = json.loads(Path("handoff-response.json").read_text())
if r.get("stop_reason") != "end_turn":
    raise SystemExit("Incomplete response; inspect before accepting.")
text = "\n".join(b["text"] for b in r.get("content", []) if b.get("type") == "text")
result = json.loads(text)  # Reject prose and Markdown instead of guessing.
Path("result.json").write_text(json.dumps(result, indent=2))

python3 checkpoint_demo.py validate result.json

Nossa resposta real do Opus foi interpretada como:

{"rows":[{"sku":"DEMO-001","shortage":3},{"sku":"DEMO-002","shortage":0},{"sku":"DEMO-003","shortage":4}]}

O validador aceitou três linhas com falta total de 7. Ele verifica cobertura exata de SKUs, IDs duplicados, tipos inteiros e cada quantidade recalculada. Rejeita strings como "3", booleanos, SKUs ausentes ou extras e valores incorretos. O verificador do checkpoint rejeita separadamente hashes de origem ou resultado alterados, operação de leitura não verificada e efeitos colaterais inesperados.

Essas verificações determinísticas são evidências mais fortes para essa tarefa do que perguntar a qualquer um dos modelos: “Tem certeza de que a resposta está completa?”. Ainda assim, são intencionalmente limitadas: o script não valida um fluxo comercial arbitrário, não consulta estoque atual nem fornece um sistema transacional de produção.

O que a execução demonstrou — e o que não demonstrou

As três respostas informaram zero tokens de leitura e criação de cache. Aplicando os preços de lista padrão verificados, o total dessas três requisições é $0.022008: $0.004816, $0.014024 e $0.003168, respectivamente, em USD. É um cálculo baseado no uso, não uma fatura conciliada separadamente. O artigo comparativo explica as tarifas e por que um teste tão pequeno não serve para classificar os modelos.

Não provocamos uma indisponibilidade real do serviço, não testamos reprodução de thinking entre contas, não comparamos muitas tarefas nem comprovamos a confiabilidade do fallback automático. A origem era sintética, a ferramenta de leitura rodou localmente e nenhum pedido foi enviado. As respostas dos modelos foram respostas reais de API.

Captura em inglês do nosso registro de teste renderizado localmente, preenchido com respostas reais da API. Não é uma captura da interface do produto Ofox.

Trate de outra forma as interrupções durante uma escrita

Em operações somente de leitura, repetir uma consulta pode ser aceitável quando atualização dos dados e custo estão claros. Em uma escrita, o timeout deixa uma pergunta mais perigosa: o sistema externo concluiu a ação antes de o cliente perder a resposta?

Um registro de operações de produção deve distinguir ações planejadas, em andamento, confirmadas, falhas e incertas. Após um timeout, consulte o destino usando sua chave estável de operação antes de tentar novamente. Se o destino suporta chave de idempotência, use-a e preserve a resposta. Caso contrário, você não consegue garantir entrega exatamente uma vez apenas salvando um arquivo JSON local.

Não marque uma escrita incerta como concluída porque o resumo de um modelo diz que aconteceu. Não deixe o modelo de destino repeti-la “por segurança”. Retome a partir de resultados verificados e encaminhe operações não resolvidas para conciliação. O padrão também vale para formulários enviados, tickets criados, e-mails e pagamentos, embora cada destino precise de controles próprios.

Adapte o checkpoint ao resultado esperado

Em um relatório de pesquisa, carregue URL da fonte, evidência recuperada, status da afirmação e perguntas sem resposta. Em uma planilha, carregue versões de entrada, identificadores das linhas, regras de transformação e verificações de saída. Em uma alteração de código, carregue commit ou diff, testes realmente executados, falhas e trabalho restante. Preserve evidências de trabalho concluído, não apenas uma porcentagem de progresso.

Comece com uma migração pequena: uma tarefa somente de leitura, uma troca de modelo e uma condição independente de aceitação. Amplie somente depois de compreender os casos de falha. O guia de API cobre a conexão inicial, enquanto Messages nativo da Ofox e roteamento de provedores descrevem a integração. A continuidade do estado continua sendo responsabilidade da aplicação mesmo quando a próxima requisição tem sucesso.