Meus agentes de código usaram Claude Fable 5 e a família GPT-5.4, GPT-5.5 e GPT-5.6 da OpenAI em trabalho real ao longo de 2026: sites, aplicativos iOS, e-commerce, CRM, ferramentas de música, sistemas de SEO e meus próprios fluxos de trabalho de agentes. Quando somei os logs de sessão locais ainda restantes no meu Mac, o número chegou a 21,54 bilhões de tokens.
Esse número é absurdo. E também precisa de contexto.
A maior parte disso não são 21,5 bilhões de novas palavras escritas para mim. Sessões longas de agentes enviam grandes bases de código e instruções através do contexto múltiplas vezes. Uma grande parte é lida do cache. A contagem de tokens mostra principalmente quanto contexto meus agentes de código processaram.
Minha conclusão após este período ainda é clara: evoluímos. Os modelos conseguem manter tarefas mais longas coesas, usar ferramentas e corrigir erros em um nível que parecia distante há um ano. No entanto, o modelo em si continua sendo a parte menos interessante de um sistema confiável.
O que 21,5 bilhões de tokens dizem sobre agentes de código
Contei o uso da OpenAI a partir de cada valor `last_token_usage` em logs preservados do Codex. Contei o Fable a partir de mensagens únicas de assistente em logs do Claude, usando entrada normal, criação de cache, leitura de cache e saída. O resultado é uma medição de atividade local — não uma fatura da OpenAI ou da Anthropic.
| Model | Logged activity tokens | Unique usage events / model replies |
|---|---|---|
| --- | ---: | ---: |
| GPT-5.5 | 12,96 bilhões | 95.930 |
| GPT-5.6 Sol, Terra e Luna | 1,88 bilhão | 12.370 |
| GPT-5.4 incluindo Mini | 3,43 bilhões | 26.624 |
| Claude Fable 5 | 3,27 bilhões | 16.878 |
| Total | 21,54 bilhões | 151.802 |
Usando o método de pico máximo (high-water), o GPT-5.4 representou cerca de 3,21 bilhões de tokens de entrada em cache, o GPT-5.5 teve 12,30 bilhões e a família GPT-5.6 cerca de 1,82 bilhão. Os logs do Fable continham cerca de 3,05 bilhões de leituras de cache e 181 milhões de tokens de criação de cache.
É por isso que comparar o total à quantidade de texto que um humano poderia ler é enganoso. O trabalho do agente reutiliza grandes contextos. A pergunta relevante é se o sistema fez a coisa certa com eles.
A base de código por trás do uso: 59 projetos no GitHub
No momento da medição, minha conta no GitHub tinha 59 repositórios: 50 privados e 9 públicos. Eles se dividem aproximadamente assim:
Nos 26 repositórios do GitHub que tinham um checkout local com exatamente o mesmo nome, encontrei 6,90 milhões de linhas de código fonte rastreadas após filtrar arquivos de fornecedores, build, cache e minificados. Esse número é dominado por três grandes plataformas legadas em PHP. Se eu remover essas, restam cerca de 357.000 linhas na superfície mais moderna e mais construída internamente, que inclui TypeScript, Python, Swift, Shell e Astro.
Isso não é uma tentativa de vencer uma competição de linhas de código. Um milhão de linhas ruins ainda é dívida técnica. As estatísticas mostram a amplitude do ambiente onde os modelos foram testados: mobile, backend, frontend, automação, conteúdo, operações e lógica de negócios.
Fable 5 e GPT-5.6 são melhores — de maneiras diferentes
A Anthropic descreve o Fable 5 como seu modelo para grandes projetos de código, migrações e sessões autônomas longas. A OpenAI descreve o GPT-5.4 como uma fusão de codificação de fronteira, trabalho de conhecimento e uso de computador. A família GPT-5.6 levou o foco ainda mais para o trabalho de agentes de longa duração.
Isso corresponde bastante bem à minha experiência. O Fable é frequentemente melhor em entender a forma de um problema difícil antes de começar a alterar o código. O GPT-5.6 Sol é mais propenso a pegar o problema, usar as ferramentas e levar o trabalho adiante.
O debate no X mostra a mesma divisão:
Essa crítica é justa. Um modelo melhor ainda pode criar um dia de trabalho pior se o roteamento, preços, limites de contexto ou políticas de segurança forem difíceis de entender.
O modelo é o motor, não o carro
Um modelo de linguagem pode raciocinar sobre código. Um agente de código também precisa operar dentro de um sistema real.
Minha pilha prática se parece com isso:
Cada parte resolve um problema diferente. Uma skill sem ferramentas é documentação. Uma ferramenta sem política é um risco. Memória sem controle de fonte torna-se folclore antigo. Um build sem verificações ao vivo ainda pode deixar a produção quebrada.
Fluxos de Trabalho de Desenvolvedor MCP: A Camada de Controle Real→ importa especialmente porque move a integração de prompts personalizados para um contrato que múltiplos clientes podem entender. Meu MCP de página pessoal pode, por exemplo, pesquisar, criar um rascunho, gerar imagens, analisar SEO e publicar. O mesmo agente ainda precisa saber quando parar em um rascunho não publicado.
O grande salto são cadeias de trabalho mais longas
No meu teste anterior do GPT-5.5 no Codex→, vi a mesma mudança. Há um ano, uma boa sessão de codificação era frequentemente: perguntar, obter um bloco de código, copiar, testar você mesmo. Agora um agente pode ler regras do projeto, encontrar o repositório certo, inspecionar uma rota, alterar o código, fazer o build, resolver um conflito, fazer push e verificar a produção.
Isso é uma mudança qualitativa.
Ao mesmo tempo, tenho visto modelos:
O último passo ainda é o mais caro: provar que o resultado existe no lugar certo e funciona para um usuário real.
O que ainda nos falta
Melhor roteamento automático de modelos
Não quero escolher nomes de modelos e níveis de raciocínio para cada subtarefa. O sistema deve enviar revisão de arquitetura para o modelo que é melhor na visão geral, alterações mecânicas para um modelo mais rápido e verificação final para um verificador separado.
Memória de trabalho portável
O contexto ainda está preso dentro de um cliente, modelo ou arquivo de sessão específico. Skills e MCP reduzem a dor, mas um agente deveria ser capaz de trocar de modelos sem perder a maneira comprovada de trabalhar do projeto.
Verificação como um recurso de primeira classe
A maioria dos agentes de demonstração recompensa a produção de código. Quero medir a parcela de tarefas que terminam em estado externo correto verificado: rota ao vivo, linha de banco de dados, aplicativo instalado, mensagem enviada ou build aprovado.
Custo mais claro
Tokens em cache são mais baratos e às vezes relatados de forma diferente, mas o usuário muitas vezes vê apenas uma barra que desaparece rapidamente. O agente deveria ser capaz de dizer: esta tarefa usou X novos tokens de entrada, Y leituras de cache, Z tokens de saída e criou o seguinte resultado verificado.
Minha recomendação: construa o sistema antes do super-prompt
Comece com uma tarefa estreita que possa ser verificada. Dê ao agente um pequeno conjunto de ferramentas, escreva uma skill para o fluxo de trabalho e defina o que conta como concluído. Em seguida, adicione memória e mais ferramentas quando vir uma necessidade recorrente.
Um agente de código útil não precisa de acesso livre a tudo. Ele precisa do acesso certo, da ordem certa e de uma regra de parada.
Agora uso modelos Fable e OpenAI menos como oráculos e mais como componentes. O Fable pode revisar um design difícil. GPT-5.6 Sol, Terra e Luna→ podem ser divididos por perfil de trabalho, e o GPT-5.6 pode conduzir um longo fluxo de ferramentas. Um modelo menor pode traduzir ou classificar. O MCP os conecta a sistemas reais. Skills dão ao Codex uma maneira reutilizável de trabalhar→. Git e testes decidem se o resultado pode avançar.
21,54 bilhões de tokens depois, a maior melhoria não é que os modelos escrevam código mais bonito. Eles podem permanecer no trabalho por mais tempo. Nosso trabalho é construir guardrails, memória e verificação que tornem esse tempo valioso.