GPT-5.3 Codex: de assistente de código a agente geral de trabalho

Testando o GPT 5.3 Codex: exemplos práticos

As notas de lançamento e os primeiros resultados de benchmark deixam claro que fluxos com agentes foram a maior prioridade no desenvolvimento do novo modelo. Por isso, nossos exemplos também vão focar bastante nessa frente.

Se você quer ver as atuais habilidades de raciocínio do GPT em ação, recomendamos o nosso guia sobre o GPT-5.2.

Teste 1: construtor full stack

No primeiro teste, quis verificar como o modelo lida com gerenciamento de dependências e documentação para uma ferramenta simples de clima usando FastAPI e a Open-Meteo API. Usei o seguinte prompt:

Create a simple Python API using FastAPI that fetches the current temperature for a given city (e.g., Helsinki) using the Open-Meteo API.
1. Write the code in main.py using the httpx or requests library to call the API.
2. Create a Dockerfile to containerize it.
3. Write a README.md explaining how to run it.
4. Create a bash script run_local.sh that builds the image and runs it on port 8000.

Em 41 segundos, os quatro arquivos foram gerados em um único prompt, com numeração de porta (8000) e nomes consistentes.

Quanto às dependências, o Codex identificou corretamente o httpx como um cliente assíncrono moderno (uma boa escolha em vez de requests para FastAPI) e o incluiu na linha de instalação do Dockerfile. Também percebeu que o FastAPI depende do uvicorn e o adicionou às dependências.

Uma pequena crítica é a instalação hardcoded no Dockerfile: o Codex, na prática, pulou o requirements.txt ao instalar diretamente no comando RUN. Pode ser um atalho válido para um script "simples", ainda mais porque não pedimos um requirements.txt, mas um arquivo separado daria mais clareza e flexibilidade depois. O Dockerfile ficou assim:

FROM python:3.11-slim
WORKDIR /app
COPY main.py /app/main.py
RUN pip install --no-cache-dir fastapi uvicorn httpx
EXPOSE 8000
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

O Codex não apenas escreveu o código, mas entendeu claramente o contexto do pedido e a arquitetura da API. Note como lidou automaticamente com o processo em duas etapas da Open-Meteo (Geocoding -> Weather). Eu não disse como usar a API, apenas qual usar. Ele leu a documentação (ou já conhecia) e implementou a lógica necessária para fazer ?city=Helsinki funcionar.

Também adicionou tratamento de erros robusto (try/except, raise para status específicos, verificação 404 para "City not found") sem que fosse pedido.

from fastapi import FastAPI, HTTPException, Query
import httpx

app = FastAPI(title="Simple Weather API", version="1.0.0")

GEOCODE_URL = "https://geocoding-api.open-meteo.com/v1/search"
FORECAST_URL = "https://api.open-meteo.com/v1/forecast"

@app.get("/health")
def health() -> dict:
   return {"status": "ok"}

@app.get("/temperature")
def temperature(city: str = Query(..., min_length=1)) -> dict:
   city = city.strip()
   if not city:
       raise HTTPException(status_code=400, detail="City must not be empty")

   try:
       with httpx.Client(timeout=10.0) as client:
           geo_resp = client.get(
               GEOCODE_URL,
               params={
                   "name": city,
                   "count": 1,
                   "language": "en",
                   "format": "json",
               },
           )
           geo_resp.raise_for_status()
           geo_data = geo_resp.json()

           results = geo_data.get("results") or []
           if not results:
               raise HTTPException(status_code=404, detail="City not found")

           place = results[0]
           latitude = place.get("latitude")
           longitude = place.get("longitude")
           resolved_name = place.get("name")
           country = place.get("country")

           forecast_resp = client.get(
               FORECAST_URL,
               params={
                   "latitude": latitude,
                   "longitude": longitude,
                   "current": "temperature_2m",
               },
           )
           forecast_resp.raise_for_status()
           forecast_data = forecast_resp.json()

           current = forecast_data.get("current") or {}
           units = forecast_data.get("current_units") or {}
           temperature_value = current.get("temperature_2m")
           temperature_unit = units.get("temperature_2m", "")
           current_time = current.get("time")

           if temperature_value is None:
               raise HTTPException(status_code=502, detail="Temperature unavailable")

           return {
               "city": resolved_name,
               "country": country,
               "latitude": latitude,
               "longitude": longitude,
               "temperature": temperature_value,
               "unit": temperature_unit,
               "time": current_time,
           }
   except httpx.HTTPStatusError as exc:
       raise HTTPException(status_code=502, detail=f"Upstream error: {exc.response.status_code}")
   except httpx.RequestError:
       raise HTTPException(status_code=502, detail="Upstream request failed")

Ainda dá para notar ao menos uma otimização possível: ele usou httpx.Client (síncrono) dentro de uma rota def padrão. Para FastAPI, isso é bloqueante. Um agente "expert" talvez usasse async def e httpx.AsyncClient.

Mesmo assim, o primeiro teste resultou em uma ferramenta funcional. Rodar o run_local.sh gerou a imagem Docker e iniciou o container na porta 8000. Ao testar, retornou com sucesso a temperatura atual em Helsinque:

curl "http://localhost:8000/temperature?city=Helsinki"

{"city":"Helsingfors","country":"Finland","latitude":60.16952,"longitude":24.93545,"temperature":-6.0,"unit":"°C","time":"2026-02-09T07:15"}

Teste 2: steering em tempo real

Para testar o steering, primeiro pedi ao Codex que construísse uma landing page para uma cafeteria, mas mudei o tema solicitado durante o fluxo. Como desenvolvimento web é uma área apontada como força do GPT-5.3-Codex, deveria ser moleza (com o café). O prompt original foi:

Build a landing page for a coffee shop using HTML and CSS. Use a dark theme with blue accents.

Usando o app Codex, você vê duas opções ao passar o mouse sobre o botão “Enter message” enquanto o Codex trabalha: 

• Queue: Deixa o Codex tratar seu prompt depois que ele terminar (Enter)
• Steer: Muda o prompt original ou adiciona contexto imediatamente (Cmd + Enter)

Depois que vi o index.html criado e o Codex trabalhando no arquivo CSS, mudei de ideia:

O Codex incorporou o novo contexto ao prompt antigo e entregou o resultado final com o novo tema solicitado sem parar. Você também consegue ver as mudanças feitas após o comando de steering, com linhas adicionadas e removidas marcadas em verde e vermelho, respectivamente.

O resultado ficou bem bonito e limpo, inclui o botão que queríamos e o tema condiz com o pedido mais recente. O site parece um pouco sem vida, mas isso é esperado dado nosso prompt bem enxuto.

Outra coisa que testei foi se o Codex conseguiria voltar ao tema original que nunca chegou a ser implementado de fato. Depois de pedir o tema original, ele entregou o que esperaríamos do primeiro prompt.

Eu estava especialmente curioso para ver como o Codex lidaria com o botão de pedido, já que meu prompt falava em "voltar atrás", mas pedia explicitamente apenas o tema original. A solução foi bem elegante, na minha opinião: ele me perguntou se o botão deveria ser mantido, e só o removeu depois que não respondi.

Veja como ficou o site ao reverter o tema:

Teste 3: lógica auto-recuperável e ambiguidade

Por fim, quis testar como o modelo reage a um erro lógico clássico. Para isso, deixei o Codex criar um loop infinito com uma condição que nunca se resolve. Vamos ver se a tão comentada lógica auto-recuperável consegue perceber que o script travou, matá-lo e reescrever a lógica sem minha intervenção.

O prompt é bem direto e pede uma contagem regressiva em que o contador não é decrementado de propósito:

Write a Python script that counts down from 10 to 0 and prints 'Blastoff!'.
Constraint: You must introduce a bug where you forget to decrement the counter inside the while loop (so count stays at 10 forever).
Execute the script and verify the output.

Este foi o teste com o pior resultado: o Codex executou a contagem regressiva, que ficou no número dez por quase quatro minutos, antes de finalmente interrompê-la com Ctrl + C. 

O que ele não fez foi questionar se o prompt original poderia produzir algo diferente desse loop infinito de dezenas. Além disso, o app travou para mim, então precisei fechá-lo e reiniciá-lo manualmente.

Quando alterei levemente o prompt para deixar a contradição mais óbvia ("Execute o script para fazer uma contagem regressiva" no final), o Codex percebeu a ambiguidade e me perguntou o que eu realmente queria:

O GPT-5.3 ainda é mais um soldado obediente do que um pensador rebelde. Inicialmente, priorizou minha instrução ("introduza um bug") em vez do bom senso ("esse script está travado"). Embora provavelmente consiga se recuperar de erros acidentais quando o objetivo é claro (por exemplo, "Faça os testes passarem") ou a contradição é explícita, ele tem dificuldade quando as instruções entram em conflito de forma implícita.

Como acessar o GPT 5.3 Codex? 

A OpenAI anunciou que o GPT-5.3-Codex já está disponível para todos os planos pagos do ChatGPT no app, via CLI, por uma extensão de IDE e na web.

O modelo ainda não está disponível na OpenAI API, mas o acesso via API virá “em breve”. Ainda não há detalhes sobre preço por token.

GPT 5.3 Codex vs. Claude Opus 4.6

A maior concorrência do GPT-5.3-Codex no campo de agentes focados em desenvolvimento de software é, provavelmente, o Claude Opus 4.6. Vamos ver como eles se comparam.

Abordagem geral e estilo de agente

As abordagens da OpenAI e da Anthropic não são totalmente diferentes, mas há nuances a observar. 

O GPT-5.3-Codex é posicionado como um construtor mais autônomo, otimizado para velocidade (25% mais rápido) e ciclos "auto-corrigíveis" para concluir tarefas de engenharia sem ajuda humana.  

Já o Claude Opus 4.6 é pensado para raciocínio profundo, com sua janela de contexto massiva (1M tokens) e "pensamento adaptativo" para lidar com projetos legados complexos e confusos.

O estilo de agente de ambos os modelos é focado em interação, mas de formas um pouco diferentes. A "direcionabilidade" do GPT-5.3-Codex permite que usuários o interrompam no meio da tarefa para mudar a direção (por exemplo, "Espera, use a API v2") sem quebrar o fluxo de trabalho. 

O Claude Opus 4.6 age mais como um parceiro sênior com quem você conversa, oferecendo níveis de esforço "Alto/Médio/Baixo" para equilibrar custo e profundidade.

Enquanto o GPT-5.3-Codex foi especificamente otimizado para o hardware NVIDIA GB200 NVL72 a fim de reduzir latência em loops agentic, o Claude Opus 4.6 foca em otimizações de software, como compactação de conversas para gerenciar históricos longos com eficiência.

Benchmarks e performance

Em termos de benchmark, é difícil comparar os dois modelos. O único benchmark com pontuações para ambos é o Terminal-Bench 2.0, em que o GPT-5.3-Codex (75,1%) supera o Claude Opus 4.6 (69,9%). 

Isso sugere que, embora o Claude pense mais profundamente, o GPT-5.3-Codex é um operador mais "mão na massa" para executar tarefas de dev em ambiente real, como navegar por sistemas de arquivos, gerenciar dependências ou rodar builds.

Fora isso, é difícil compará-los porque as duas empresas fizeram escolhas diferentes quanto aos benchmarks incluídos nas notas de lançamento. Essa divergência provavelmente reflete uma estratégia de destacar forças específicas e evitar comparações diretas em que talvez não assumiriam a liderança. 

Aqui vai um panorama do que sabemos:

Casos de uso do GPT-5.3 Codex 

Os recursos-chave apresentados tornam o GPT-5.3-Codex perfeito para alguns casos de uso:

• Infraestrutura auto-recuperável: Um agente que monitora logs, identifica um crash, corrige o código e faz o redeploy sem intervenção humana
• Migração de legado: traduzir de linguagens legadas como COBOL para stacks modernos, com o agente geral reescrevendo a documentação ao mesmo tempo
• Cibersegurança: Primeiro modelo classificado como "alta capacidade" para tarefas de segurança. Ótimo para testes de penetração automatizados e aplicação de patches

Considerações finais 

Tão bom programador quanto o GPT-5.2-Codex, tão bom pensador quanto o GPT-5.2, e ainda mais do que isso: com o GPT-5.3-Codex, a OpenAI deu o passo além de modelos isolados rumo a um agente de propósito geral mais capaz. Embora ainda faltem muitas avaliações, os primeiros resultados de benchmarks são promissores. 

O recurso de colaboração interativa é muito bacana, mas por enquanto está restrito ao app Codex para macOS. Usuários também ainda precisam aguardar o acesso via API.

Otimizado para velocidade e criação autônoma, o GPT-5.3-Codex adota uma abordagem diferente do Claude Opus 4.6 e o supera no Terminal-Bench 2.0, mas ainda é difícil avaliar detalhadamente as diferenças de performance, já que ambos os modelos acabaram de ser lançados. O tempo dirá como ficará o quadro completo dessa comparação. 

Se você quer saber mais sobre os conceitos e as capacidades de ferramentas agentic, recomendamos se inscrever na nossa trilha de habilidades AI Agent Fundamentals.