Estou dividido entre o Claude e o Codex

Estou dividido entre o Claude e o Codex porque cada plataforma ganha numa parte diferente do meu trabalho. O Codex dá-me mais tempo útil, controlos mais simples, respostas mais claras e melhores resultados de frontend. O Claude transforma os meus planos multiagente em alterações concluídas muito mais depressa, o que pesa mais quando uma funcionalidade abrange vários sistemas.

Parte do trabalho	Claude	Codex
Visão geral da arquitetura	A minha primeira escolha	Competente, mas perde o foco mais cedo
Orquestração de grandes funcionalidades	Costuma chegar primeiro ao fim	Muitas vezes transforma-se numa execução muito mais longa
Implementação de frontend	Fiável, mas muitas vezes previsível	Melhor adaptação ao produto, espaçamento e critério visual
Comunicação escrita	O Fable vê o sistema com clareza	O Sol costuma explicá-lo melhor
Utilização incluída	O Fable para a meio da quota semanal	Os resets fazem a quota parecer muito maior
Interrupções de segurança	Mais falsos positivos no meu trabalho	Não é perfeito, mas está melhor ajustado às minhas tarefas
Fluxo entre telemóvel e computador	Funciona, mas está repartido por vários modos	Mais coerente no dia a dia

A tabela mostra por que razão continuo dividido. O Codex ganha em mais partes da experiência, mas o Claude ganha no trabalho com grandes funcionalidades, que ocupa os maiores blocos do meu tempo. Na minha utilização, nenhum dos modelos é claramente mais inteligente. São os sistemas à volta deles que determinam qual deles abro.

Porque pago pelos dois? Cada um ganha no trabalho de que preciso

Pago os dois porque o Claude se adapta ao meu processo para grandes funcionalidades, enquanto o Codex é o produto que prefiro usar em muitos trabalhos mais pequenos. Se cancelasse qualquer um deles, perderia algo que uso todas as semanas. É uma resposta incómoda, porque as duas subscrições estão entre as minhas maiores despesas recorrentes com software.

Uso assistentes de programação desde os primeiros tempos do GitHub Copilot, incluindo o período em que programar com o ChatGPT significava copiar excertos de código de uma conversa no browser. Durante anos, mantive uma configuração estável: Claude Max 20x para programação e um plano mais barato do ChatGPT para investigação. Costumo investigar antes de tomar decisões técnicas ou pessoais, e a experiência de investigação da OpenAI sempre se adaptou melhor à minha forma de trabalhar.

O GPT-5.6 alterou este equilíbrio. No meu trabalho, o Sol parece-me tão capaz como o Fable 5, por isso passei para o plano Pro 20x da OpenAI e mantive o Claude Max 20x. [4] [9] Utilizo estas ferramentas o suficiente para, por vezes, precisar de uma segunda subscrição Claude Max. Quando a quota de um plano se esgota mais depressa ou me corta o acesso mais cedo, isso altera o trabalho que consigo concluir nesse dia.

Na prática, a quota da OpenAI parece muitas vezes mais generosa. Vi mais três resets globais entre 26 de agosto e 1 de setembro de 2026, além da campanha de resets sobre a qual escrevi em agosto. A minha leitura é que as celebrações também servem de marketing para um modelo que pode consumir a quota depressa. O efeito na minha conta é mais simples: os resets deram-me mais capacidade, o que torna difícil abandonar o Codex.

O que faz o Codex melhor? Frontend e utilização diária

O Codex é melhor nas partes do trabalho diário que noto de imediato: o design de frontend à primeira tentativa, as explicações por escrito, o controlo remoto e a forma como os limites interrompem uma tarefa. É mais fácil conviver com o produto de uma tarefa delimitada para a seguinte, embora o Sol nem sempre escreva melhor código de backend.

O frontend é onde noto a diferença de qualidade mais clara. À primeira tentativa, o GPT-5.6 tende a produzir layouts com melhor espaçamento, alinhamento e hierarquia visual. A própria OpenAI afirma que o modelo melhora a estética do frontend e o critério de design. [1] Isto confirma essa capacidade, mas não compara o Sol com o Fable 5. A comparação vem da minha experiência: o Codex cria com maior frequência um design adequado ao produto existente, enquanto o Claude costuma devolver uma estrutura visual convencional, a menos que eu descreva a direção em pormenor.

Também considero o Sol mais fácil de ler. Costuma explicar as decisões em linguagem comum, mesmo quando o trabalho técnico é complexo. O Fable dá-me uma visão melhor da arquitetura, mas a sua escrita ainda pode ser mais difícil de acompanhar. Esta diferença importa porque o agente principal passa a maior parte do tempo a discutir compromissos e a comunicar o progresso, não apenas a escrever código.

Essa facilidade mantém-se quando me afasto do computador. A OpenAI documenta o acesso remoto, que permite continuar no telemóvel uma conversa do Codex que está a correr num Mac ou computador Windows associado. A partir do telemóvel, consigo orientar o trabalho em curso e rever aprovações, diffs e o output do terminal. [7] O Codex também oferece tarefas isoladas na cloud, embora eu use sobretudo a ligação a uma máquina. [21]

O Claude cobre os mesmos casos através de vários modos. Permite continuar sessões locais no telemóvel, lançar trabalho no computador através do Dispatch e manter sessões na cloud depois de desligar a máquina. [17] [18] [22] As duas plataformas cobrem os principais casos de uso, mas o Codex apresenta-os de uma forma que considero mais fácil de acompanhar. O Claude distribui trabalho semelhante por Remote Control, Dispatch, sessões locais e sessões na cloud.

Os limites de utilização acentuam a diferença. A documentação atual da OpenAI indica que, no Pro 20x, as mensagens locais e as tarefas na cloud partilham uma janela de cinco horas, e que também podem existir limites semanais. Portanto, o plano não funciona apenas com uma quota semanal. A documentação diz ainda que um turno em curso pode continuar depois de a conta atingir um limite, sujeito às regras de utilização justa. [4] O Claude já consegue esperar e retomar uma tarefa interrompida após o reset da sessão. [20] Na minha utilização, o limite continua a parecer uma paragem brusca no pior momento. As regras exatas do reset importam-me menos do que saber se a alteração desse dia chega a um ponto de controlo seguro.

Porque termina o Claude primeiro? O gestor não perde o foco

O Claude conclui primeiro porque a sua orquestração coincide com a forma como organizo o trabalho de desenvolvimento. Quero que um modelo capaz preserve o plano, tome decisões e comunique comigo, enquanto agentes separados investigam, implementam, testam e auditam. Nos meus projetos, o Claude consegue manter o agente principal concentrado na coordenação de forma mais consistente.

A Anthropic chama a este padrão geral orchestrator-workers, ou orquestrador e executores: um modelo central divide uma tarefa, delega as partes e combina os resultados. A OpenAI documenta a mesma ideia básica como orquestração ao estilo de um gestor. [14] [15] O nome é menos importante do que a separação: o gestor preserva o objetivo e toma as decisões, enquanto os agentes executores recebem tarefas delimitadas e devolvem provas.

Os dynamic workflows do Claude Code tornam esta divisão particularmente explícita. O Claude escreve um script de orquestração, inicia agentes em paralelo e deixa o ambiente de execução gerir as ramificações e os resultados intermédios. Segundo a Anthropic, uma execução pode iniciar dezenas ou centenas de agentes ao longo do tempo, com até 16 a trabalhar em simultâneo quando a máquina tem capacidade de CPU suficiente. [11] [12] Não preciso de centenas, mas valorizo o facto de a conversa principal não ter de guardar cada leitura de ficheiro, resultado de comando e desvio durante a depuração.

No meu processo, o Fable 5 assume a função principal. Define comigo a arquitetura e escreve o plano. Depois, agentes Opus implementam partes delimitadas, enquanto outros testam e reveem o trabalho. O Fable decide quais constatações justificam alterações e faz-me perguntas quando uma mudança se afastaria do plano. Explico os pormenores da implementação no meu processo com planeamento prévio para o Opus 5; aqui, o importante é o Fable continuar responsável pelo resultado completo.

gestor

• Fable 5 mantém o objetivo, o plano, as decisões e a conversa com o utilizador

delega trabalho delimitado

agentes executores

• agentes de investigação mapeiam o repositório e as perguntas em aberto
• agentes Opus implementam partes delimitadas
• agentes de teste e auditoria devolvem provas e constatações

devolvem provas

decisão

• revisão do gestor aceita, rejeita, redireciona ou pergunta ao utilizador
• funcionalidade concluída plano cumprido e verificações aprovadas

No Claude Code, o Fable e o Opus suportam uma janela de contexto de um milhão de tokens, mas a maior vantagem está em manter os pormenores dos agentes executores fora da conversa do gestor. [13] Mesmo uma janela grande acaba por encher se cada leitura de ficheiro, registo de agente e resultado de teste entrar nela. Os dynamic workflows mantêm esses dados separados, para que o contexto restante do gestor continue a ser útil.

A OpenAI descreve a mesma separação para o Codex: a conversa principal deve manter os requisitos e as decisões, enquanto os agentes executores tratam da exploração, dos testes e dos registos. [5] Por isso, esperava que o meu processo também funcionasse no Codex. Nas minhas execuções, porém, o agente principal não permanece na função exclusiva de gestor com a mesma consistência que o Claude.

Porque termina o Sol mais tarde? O Codex cria mais trabalho

O Sol pode gerar texto mais depressa e ainda assim demorar mais a terminar, porque a velocidade de output mede apenas uma parte da execução. Numa grande funcionalidade, o agente passa a maior parte do tempo a escolher trabalho, chamar ferramentas, reabrir questões e coordenar outros agentes. Escrever mais depressa não ajuda quando cria trabalho adicional ou volta a decisões já tomadas.

A 1 de setembro de 2026, a Artificial Analysis mediu 77,1 tokens de output por segundo no GPT-5.6 Sol e 66,9 no Fable 5, nas configurações de esforço máximo comparadas. [3] A vantagem de cerca de 15% corresponde ao que sinto quando vejo o Sol responder. Não se reflete nos meus tempos totais, porque o Codex costuma criar mais trabalho para si próprio quando a implementação original já está quase concluída.

O trabalho adicional anula a vantagem de velocidade do Sol

Grande parte do tempo adicional vem do excesso de engenharia. Tenho de indicar com muita clareza que o Codex deve preservar a arquitetura existente, assinalar constatações não relacionadas sem as corrigir e parar quando os critérios de aceitação forem cumpridos. Caso contrário, o Sol pode acrescentar camadas defensivas, novas funções auxiliares ou até um subsistema para um problema que só precisava de uma alteração focada. Medi a mesma tendência durante auditorias, nas quais o Sol encontrou muito mais problemas possíveis do que o Fable, mas a maioria não passou na triagem.

A coordenação acrescenta outro atraso. Nas execuções Codex Ultra que usei, o agente principal teve dificuldade em permanecer na função exclusiva de gestor. Delegava trabalho, mas continuava a inspecionar ficheiros, fazer alterações ou reabrir decisões enquanto os outros agentes executavam as suas tarefas. A OpenAI documenta o Ultra como raciocínio máximo com delegação automática e afirma que a conversa principal reúne os resultados dos agentes executores. [5] [19] Não promete que a conversa principal fique afastada da implementação. As minhas tentativas de impor esse limite reduziram o problema, mas não o eliminaram.

Mais contexto e menos esforço não resolvem o ciclo

As execuções longas exercem mais pressão sobre o contexto, mas aumentar a janela não resolveu a lentidão. Inicialmente, o indicador de estado do meu Codex mostrava 272K tokens, por isso alterei model_context_window para um milhão na configuração. A OpenAI documenta esta opção, e o próprio Sol suporta até 1,05 milhões de tokens. [6] [2] A indicação de 272K tokens descreve o que a minha configuração apresentava, não um valor por omissão universal estabelecido pela OpenAI. A janela maior ajuda, mas o Codex continua a enchê-la depressa durante uma longa execução multiagente. Quando o contexto começa a ser compactado, tenho menos confiança de que uma restrição definida no início mantenha o mesmo peso seis horas depois.

Um contexto longo também tem custos. Nos pedidos à API acima de 272K, a OpenAI cobra o dobro pelo input e 1,5 vezes a tarifa pelo output, com essas taxas aplicadas ao pedido completo. [2] A OpenAI não afirma que a quota do ChatGPT Pro usa exatamente os mesmos multiplicadores, portanto não aplico essa fórmula ao contador da minha subscrição. Os preços mostram, porém, por que motivo aumentar a janela não torna automaticamente eficiente um trabalho longo.

Reduzir o nível de esforço do Sol também não resolveu o problema. O Codex fica um pouco mais rápido, mas a redução do tempo não compensa a perda de qualidade no planeamento e na revisão. Definir um objetivo também não chega. A OpenAI descreve os objetivos como uma forma de continuar a trabalhar ao longo de vários turnos até cumprir uma condição de paragem verificável, que é exatamente o que pretendo. [8] Nas minhas execuções longas, o objetivo mantém o Codex ativo sem o ajudar a concluir mais cedo.

O que torna o Claude mais difícil de usar? Limites e segurança

A vantagem do Claude na orquestração vem acompanhada de limites mais apertados e mais interrupções de segurança causadas por falsos positivos. O seu processo para grandes funcionalidades adapta-se melhor ao meu trabalho, mas passo mais tempo a gerir qual dos modelos ainda tem quota e a recuperar quando uma verificação de segurança interrompe trabalho comum.

O limite do Fable é a frustração mais direta. Pago o Max 20x, mas o Fable só pode utilizar metade da quota semanal incluída. [10] Compreendo que um fornecedor com menos capacidade de computação possa controlar de forma mais apertada o acesso ao seu modelo mais dispendioso. Essa justificação não muda o efeito no meu trabalho. Uma grande funcionalidade não se torna menos importante quando essa quota mais pequena se esgota.

As interrupções de segurança são piores, porque quebram a concentração sem fazer avançar o trabalho. A Anthropic reconheceu que o Fable 5 estava a sinalizar pedidos inofensivos durante tarefas comuns de programação e depuração, após o lançamento de junho de 2026 e a retirada temporária do modelo. [16] Agora encontro menos interrupções do que no início, mas continuam a surgir mais vezes do que espero em tarefas inofensivas.

A OpenAI também avisa que as proteções do GPT-5.6 podem intervir em pedidos legítimos. [1] O Codex não está livre de falsos positivos. Nos meus projetos, os seus classificadores estão melhor ajustados: normalmente consigo perceber por que motivo um pedido de dupla utilização provocou uma pausa, e o trabalho normal de desenvolvimento tem menos probabilidade de causar uma interrupção. Esta é a minha experiência, não uma comparação publicada das taxas de erro dos filtros.

Estas queixas não superam a vantagem do Claude na orquestração. Explicam por que continuo a olhar para o Codex mesmo depois de o Claude ganhar outra implementação grande.

Devo usar o Claude ou o Codex? Depende do âmbito

Escolho o Claude quando a funcionalidade exige investigar o repositório, decidir a arquitetura, coordenar vários agentes de implementação e fazer uma auditoria independente. Escolho o Codex para alterações delimitadas, frontend e sessões em que valorizo mais a interface clara e a maior quota prática. Para investigação ampla, continuo a começar pelo ChatGPT, não por estes harnesses de programação.

Esta divisão baseia-se no processo, não na ideia de que o Fable 5 é mais inteligente do que o Sol. Se desse aos dois modelos uma tarefa pequena e clara, confiaria em qualquer um deles para produzir bom código. A diferença aparece quando uma funcionalidade tem de ser dividida em várias tarefas dependentes e uma só conversa precisa de preservar os motivos por trás de todas elas.

O Codex tornar-se-ia a minha escolha por omissão se o gestor conseguisse manter-se fora da implementação, controlar melhor o âmbito, usar contexto longo com maior eficiência e levar uma execução grande até uma conclusão verificada. O Claude seria a escolha mais fácil como subscrição única se a quota incluída do Fable fosse menos restritiva e a programação comum ativasse menos proteções.

Por enquanto, continuo a pagar pelos dois. Começo as grandes funcionalidades no Claude porque a sua orquestração chega ao resultado final que pedi. O Codex é o produto que continuo a querer usar porque o resto da experiência é mais simples. Nenhuma das plataformas me oferece ainda a orquestração do Claude e a experiência de utilização do Codex num só processo.