Codex vs Gemini CLI: Um Caso Real de Eficiência em Tokens

Photo by @willacosta on Unsplash

TL;DR

Problema: imagens não renderizam em determinado componente após a atualização das bibliotecas do projeto, antes dessa atualização tudo funcionava perfeitamente, então provavelmente a causa é alguma breaking change.

Resultados Obtidos:

Análise de Eficiência:

• Codex além de ter sido mais eficiente com um consumo de 87% a menos de tokens ainda resolveu o problema 68.8% vezes mais rapidamente.
• Enquanto a sessão no Gemini levou um tempo maior gerando um consumo de 7.27x a mais do que o Codex e no final das contas não resolveu o problema de fato.

Para esse experimento utilizei os seguintes modelos, ambos utilizando os planos pagos de cada plataforma.

• Google One AI Pro — Gemini 3 Flash Preview
• OpenAI Go — GPT-5.3 Codex

O problema é um caso simples, mas em que pude testar a eficiência, consumo e "inteligência" de cada um dos agentes para encontrar a solução.

Antes de falarmos sobre o problema e como os agentes se saíram, aqui está o prompt que foi utilizado em ambos:

Investigate the blogpost content at `.../ai-coding-assistant.mdx`, It isn't rendering the `ImageLayout` component properly. The images property is being received as an `undefined`, so there was an exception at the line 52 on `image-layout.tsx` file.

I've updated some app's packages, maybe it has something to do with the new "next-remote-mdx" version or other peer-dependencies.

This is the error output: """
src/components/layout/image-layout.tsx (52:15) @ map
x TypeError: Cannot read properties of undefined (reading 'map')
at ImageLayout (./src/components/layout/image-layout.tsx:40:26)
at stringify (<anonymous>)
digest: "1222779921"
"""

Estava com um problema no componente de ImageLayout que após a atualização de algumas dependências do projeto passou a dar problemas. O caminho das imagens era informado através de uma lista usando a sintaxe do JSX:

<ImageLayout
	images={[{ ... }, {...}]}
/>

Como você pode imaginar, esse componente renderiza imagens em um grid dinâmico, imagens são informadas através de parâmetros específicos como caminho, qualidade, tamanho, etc.

Cenário do Gemini

Comecei a implementação pelo Gemini e logo no início percebi que o processo de reasoning não foi muito bom, a primeira coisa que ele fez foi adicionar um console.log na função que renderiza o componente:

export function ImageLayout({ images }: ImageLayoutProps) {
  console.log('ImageLayout received images:', images)

  return (
    <div className='flex flex-wrap gap-4 my-6 m-auto py-1 w-fit-content'>
      {images?.map((image, index) => { ... }
	)

Após isso, o agente se perdeu em várias execuções sem sentido, editou arquivos completamente distintos do objetivo inicial, como por exemplo:

• lib/get-posts.ts
• lib/get-posts-by-slug.ts

Esses arquivos lidam com a busca de posts para o blog e não possuem nenhuma relação com o problema que solicitei ao Gemini para resolver.

Ele também executou várias vezes comandos de build sem muito sentido:

pnpm-check \
pnpm run build > build_output.txt 2>&1
...

Após alguns bons minutos, temos o código final gerado pelo Gemini:

As correções sugeridas acima não fazem o menor sentido para a solução do problema, o Gemini simplesmente adicionou uma validação para saber se o valor informado na propriedade images era realmente um array.

Além de fazer edições em arquivos completamente distintos do objetivo inicial, em nenhum momento ele se propôs a buscar a raiz do problema de fato. Que em contraste com o Codex foi muito mais rápido e assertivo.

Cenário do Codex

Inicialmente o Codex começou a explorar as dependências usadas no repositório, como eu já suspeitava ser o problema (inclusive citei isso no prompt inicial). Abaixo o comando utilizado pelo agente:

 pnpm list next-mdx-remote @mdx-js/mdx @mdx-js/react

Após algumas interações o Codex utilizou um artifício bem interessante para tentar encontrar a solução:

Criou duas versões de um componente MDX simulando o mesmo comportamento do ImageLayout, um que recebia as imagens via sintaxe JSK, usando {} e outro usando um JSON string.

<ImageLayout images={[...]} /> → component received {} (prop missing)
<ImageLayout images="abc" /> → component received { images: "abc" }

Ao compilar ambos componentes, o agente percebeu que a versão usando a sintaxe JSX retornava undefined, mas a versão usando string funcionava corretamente.

<ImageLayout images='[{ ... }, { ... }]' />

Então o agente escreveu um código para fazer o parse do JSON string para um objeto, permitindo usar a mesma estrutura do código existente. Tudo isso de maneira rápida e direta, sem precisar alterar arquivos diferentes desse contexto. Ele ainda adicionou uma nova função para fazer a normalização da propriedade referente às imagens, uma estratégia defensiva eu diria:

E também ajustou a maneira em que o componente é usado para refletir as recentes mudanças:

-<ImageLayout images={[{ ... }, { ... }]} />
+<ImageLayout images='[{ ... }, { ... }]' />

Resultados

Após os testes com ambos agentes, cheguei aos seguintes resultados:

Lembrando que fora o utilizado o mesmo prompt e cenário para ambos agentes objetivando uma comparação justa.

• Codex além de ter sido mais eficiente com um consumo 86% a menos de tokens ainda resolveu o problema 68.8%x mais rápido.
• Enquanto a sessão no Gemini levou um tempo maior gerando um consumo de 7.27x a mais do que o Codex e no final das contas não resolveu o problema de fato.

Isso nos exemplifica que usar o modelo correto para determinado caso de uso não apenas resolve o problema de maneira eficiente como também ajuda a economizar tempo e tokens (que são recursos caros).

Não estou dizendo aqui que você não deve utilizar o Gemini, nem que deve usar Codex para tudo, cada modelo possui seus pontos fortes e fracos para determinadas tarefas. Você precisa testar e tirar suas próprias conclusões baseando-se em seu caso de uso.

Referências

• Gemini 3 Flash Preview Model
• GPT-5.3-Codex Model