Uma execução de 3 min 59 s terminou com 10/10 na verificação de entrega; a outra passou por 9 testes e deixou intacto o arquivo solicitado.
Quando o Codex terminou a tarefa, não olhei primeiro para o contador de testes. Abri um terminal e comparei o hash de inventory_service.py. Essa decisão transformou uma demonstração aparentemente perfeita em um teste útil: o agente havia passado na suite, sim, mas também havia modificado exatamente o arquivo que precisava ser reparado.
O detalhe importa porque uma execução de referência, que chamarei de DSH, obteve o mesmo 9/9 com deepseek-v4.1-flash e não tocou esse arquivo. Criou uma cópia do pacote em outro caminho e a suite importou essa cópia. O código testado estava correto; a entrega não correspondia ao solicitado.
Não apresento isso como uma competição entre modelos. É uma história sobre o fluxo de trabalho do Codex e sobre a diferença entre “a suite está verde” e “a mudança chegou ao lugar certo”. Também é o motivo pelo qual achei útil conectar o DeepSeek ao Codex: o custo baixo permite investigar uma segunda hipótese sem transformar cada nova tentativa em uma decisão orçamentária. O barato não conserta a entrega, mas facilita exigir mais uma verificação antes de aceitá-la.
O reparo que parecia concluído
O repositório continha um serviço de inventário pequeno e vários caminhos de falha em torno da mesma operação de compra. Era preciso descontar vários itens de forma atômica, unir SKUs repetidos antes de calcular o estoque e rejeitar quantidades inválidas de maneira uniforme. Também era preciso evitar que snapshot() devolvesse uma referência capaz de alterar o estado interno e proteger a venda da última unidade contra duas threads simultâneas.
A suite oculta não ficava no caminho feliz. Disparava cinquenta threads contra sete unidades e quarenta compradores que solicitavam dois produtos com estoque limitado. Verificava que uma compra com falha não deixasse uma parte descontada, que os SKUs duplicados fossem consolidados antes do desconto e que uma cópia do snapshot não modificasse o inventário real.
Esse material dá ao Codex um sinal concreto. Ele lê a saída do teste, volta ao projeto, propõe uma edição, executa de novo e usa o novo erro para ajustar a próxima edição. Não é preciso copiar a falha em uma janela à parte: o resultado da ferramenta volta ao mesmo contexto que contém o código.
O Codex completou esse percurso em 3 min 59 s. Os nove testes de comportamento passaram e o arquivo-alvo mudou. A verificação somou um ponto por essa modificação, chegando a 10/10. Até aqui, o resultado era o que qualquer um gostaria de publicar como captura de tela.
O valor do agente aparece quando a saída de uma ferramenta pode mudar a próxima edição; o verde da suite é apenas uma parte desse ciclo.
O import que resolveu a dúvida
A execução DSH serviu como controle. Passou nos nove testes de comportamento, mas seu resultado de entrega foi 9/10. O arquivo pedido mantinha o hash inicial. O Python havia encontrado outro módulo com o mesmo nome no diretório de trabalho, e os testes estavam exercitando essa implementação.
Isso não significa que os testes estivessem mal escritos em abstrato. Significa que uma importação pode resolver um nome para um caminho diferente do esperado. Para quem revisa o patch, a ordem das perguntas muda:
-
O processo terminou sem erros?
-
O diff ficou dentro dos arquivos permitidos?
-
O arquivo indicado mudou?
-
O teste importou esse mesmo arquivo?
São quatro respostas distintas. Um código de saída correto não garante um diff limpo. Um diff limpo não garante que o alvo tenha sido editado. Uma suite verde não garante que o caminho importado seja o caminho entregue.
Os hashes desta execução foram estes:
antes:
5F8FA06F3A9B9ED7022CE2EEC9158D0139DEC6716872FAC8F9D0E86DDC7C88F8
depois:
008AF21A36C45CDBB9513961DBF52E2E663791EF5CA5A31FB018871F1F4EF66D
O segundo hash não demonstra por si só que o patch seja bom. Demonstra algo mais limitado e muito prático: o arquivo que pedi para modificar já não é o arquivo com que comecei. Essa verificação teria barrado a entrega DSH antes que o 9/9 fosse confundido com um trabalho concluído.
Como conectei o DeepSeek ao Codex
A configuração que usei mantém o loop do Codex e troca o provedor do modelo. Este é o bloco do config.toml:
model = "deepseek-v4.1-flash"
model_provider = "crazyrouter"
[model_providers.crazyrouter]
name = "Crazyrouter"
base_url = "https://api.crazyrouter.com/v1"
env_key = "CRAZYROUTER_API_KEY"
wire_api = "responses"
requires_openai_auth = false
wire_api = "responses" define o formato de requisição que o Codex espera. requires_openai_auth = false evita pedir também um login da OpenAI quando a chave do provedor já autentica a chamada. A variável CRAZYROUTER_API_KEY deve existir no ambiente a partir do qual o Codex é iniciado; se for definida em outro terminal, não serve para esse processo.
Antes de executar o reparo, verifiquei três camadas separadamente. Uma requisição curta confirmou que o gateway respondia com o identificador de modelo solicitado. Um comando sem efeitos colaterais confirmou que o Codex podia executar ferramentas no diretório de trabalho. E um teste que falhava de propósito confirmou que o erro voltava ao loop e que o agente podia tentar outra edição.
Separar as camadas economiza tempo. Uma falha de autorização aparece antes de chegar ao modelo. Um identificador incorreto pode falhar ao selecionar a rota. Se o modelo responde, mas nenhum comando é executado, o problema está na sessão, no diretório ou nas permissões. Mudar a configuração sem saber qual dessas camadas falha só adiciona ruído.
O recibo de entrega que uso agora
Não espero que o agente descreva o próprio sucesso. Depois da execução, reúno quatro sinais no mesmo terminal. Esta é a versão mínima para Python no PowerShell:
python -m pytest -q
$LASTEXITCODE
git diff --stat
git diff -- inventory_service.py
$target = (Resolve-Path .\inventory_service.py).Path
$target
(Get-FileHash $target -Algorithm SHA256).Hash
python -c "import inventory_service; print(inventory_service.__file__)"
Get-ChildItem -Name inventory_service*
A primeira instrução confirma quais testes foram executados e qual foi o código de saída. O bloco de git diff delimita a mudança e mostra se apareceram arquivos inesperados. O hash responde se o alvo mudou. A importação responde a uma pergunta diferente: qual arquivo o Python vê quando resolve o módulo. A última listagem deixa visível a existência de pacotes ou arquivos homônimos que poderiam ter desviado o teste.
O Codex alcançou 10/10 nesta execução; o DSH ficou em 9/10 porque o arquivo-alvo não mudou. A diferença não estava no número de testes, mas no artefato.
Para uma revisão real, eu acrescentaria o conteúdo do diff ao histórico de revisão. O hash detecta que algo mudou, não que a mudança esteja correta. E a suite cobre apenas os casos que alguém escreveu. Em código concorrente, um teste pode ser muito útil e ainda assim deixar de fora uma intercalação perigosa.
Por que 773.893 tokens custaram 0,064 USD
A execução do Codex registrou 773.893 tokens de entrada. Deles, 738.432 vieram do cache e 35.461 não estavam em cache. A saída foi de 24.869 tokens, com 8.033 dedicados a raciocínio.
O volume se entende melhor olhando para o loop de ferramentas. Cada leitura de arquivo, cada saída de teste e cada nova edição ampliam o contexto da próxima chamada. A conversa visível pode parecer breve, embora a API esteja processando muito material repetido.
Com os preços públicos do DeepSeek V4 Flash de 27 de outubro de 2026, a estimativa fica assim:
| Componente | Tokens | Preço de tabela | Estimativa |
|---|---|---|---|
| Entrada sem cache | 35.461 | 0,45 USD / milhão | 0,01596 USD |
| Entrada em cache | 738.432 | 0,02 USD / milhão | 0,01477 USD |
| Saída | 24.869 | 1,34 USD / milhão | 0,03332 USD |
| Total | 0,064 USD |
É aritmética sobre preços públicos, não uma fatura. O valor final pode mudar conforme o plano, as regras de cache, as novas tentativas e o roteamento do provedor usado.
A comparação útil não é “o DeepSeek pensa melhor que outro modelo”, porque este teste não a sustenta. A comparação útil é de custo com o mesmo perfil de tokens. Aplicando às mesmas quantidades os preços de tabela do GPT-6.1 Sol —2 USD por milhão de entrada e 10 USD por milhão de saída—, o resultado seria de aproximadamente 1,797 USD.
A diferença prática não é só um número menor. Muda a política do loop: com um custo estimado de seis centavos, testar outra estratégia depois de um sinal ambíguo é uma decisão razoável. Com um custo próximo de 1,80 USD, a mesma nova tentativa exige justificar melhor por que trará informação nova.
Aí está a vantagem que notei no DeepSeek dentro do Codex. Ele não reduz magicamente o contexto nem transforma um teste incompleto em um teste completo. Torna o trabalho repetitivo do agente barato o suficiente para executá-lo e depois auditá-lo com calma. A economia compra tentativas; a engenharia de entrega continua sendo necessária.
Quando parar o loop
“Barato” não equivale a “repetir sem limite”. Uma nova tentativa vale a pena quando aparece um erro novo, uma asserção diferente, um traceback mais preciso ou uma leitura que muda a hipótese. Se o Codex executa o mesmo comando, recebe a mesma saída e volta a propor a mesma mudança, continuar só infla o contexto.
Eu também pararia ao ver uma modificação fora do escopo, um arquivo novo que a tarefa não pedia ou uma explicação que contradiz a saída do terminal. Nesses casos o problema já não é “dar mais uma volta no modelo”. É preciso voltar ao repositório, corrigir o teste de importação ou reformular a tarefa.
O reparo que descrevo se encaixa em uma categoria concreta: uma suite reproduzível, um arquivo-alvo identificável e um diff que pode ser revisado. Eu usaria esta montagem para falhas de teste, erros de tipos, lint, refatorações pequenas ou geração de casos de teste. Antes de aceitar o patch, revisaria o comportamento, e não só o verde.
Não a usaria como substituta de revisão em migrações de dados, pagamentos, autenticação, permissões ou configuração de produção. Um patch de seis centavos continua sendo caro se o teste importou outro módulo ou se a mudança chegou à produção sem revisão humana. A economia do modelo não muda a economia do incidente.
O que levo deste teste
O DeepSeek foi capaz o suficiente para percorrer este reparo dentro do Codex e barato o suficiente para testar de novo quando o agente precisou de outra passada. Essa combinação é a parte que recomendo. A comodidade não vem de confiar mais no modelo, mas de poder colocar o loop para trabalhar e exigir dele evidências verificáveis no final.
A próxima tarefa que eu testaria seria pequena e falharia hoje de forma reproduzível. Antes de começar, deixaria escrito o arquivo-alvo. Ao terminar, revisaria o código de saída, o diff, o hash e o caminho importado. Se esses quatro sinais concordarem, o resultado passa de “parece que está bem” para uma entrega que posso defender.
A configuração de conexão usada aqui está documentada pela Crazyrouter. O alcance desta observação é um projeto, uma máquina e uma suite concreta; não é uma classificação geral de modelos nem uma promessa de que o mesmo patch sirva em outro repositório.
Transparência: foram utilizadas ferramentas de IA para redigir e editar este texto. Os hashes, tokens, comandos e valores foram conferidos com o registro da execução. Os valores são estimativas de preço público, não faturas.