Atualização — verão de 2026: isso parou de funcionar para mim
Até o verão de 2026, esse workflow deixou de funcionar de forma confiável para mim. O contador da janela de 5 horas desapareceu da minha conta, enquanto o limite semanal permaneceu visível. Na prática, eu perdi a janela de reset mais curta em torno da qual organizava esse método.
A mudança mais importante foi o comportamento das tarefas longas. Quando uma tarefa grande do Codex chegava ao fim do meu limite semanal, eu passei a ver o trabalho parar em vez de continuar até concluir. Com isso, minha antiga regra de “iniciar a tarefa mais pesada nos últimos 3–5%” perdeu grande parte da utilidade: eu já não podia contar com uma tarefa em andamento atravessando o fim do limite semanal.
Quero separar com precisão minha observação de uma regra oficial do produto. Posso confirmar o que vi na minha conta e no meu workflow, mas não provar que a OpenAI removeu permanentemente a janela de 5 horas para todos os usuários. A documentação atual do Codex ainda menciona janelas de 5 horas e semanais e diz que um turno ativo pode, em alguns casos, continuar após atingir um limite, sujeito a regras de fair use. Por isso descrevo a mudança do verão de 2026 como um comportamento real que experimentei, e não como uma regra universal para todas as contas.
O restante do artigo fica preservado como descrição do workflow que funcionava para mim antes dessa mudança. A atualização acima substitui as recomendações no presente do texto original.
Quando o contador de uso do Codex no meu plano ChatGPT Plus cai para cerca de 3–5%, deixo de gastar o restante com prompts pequenos. Faço o contrário: inicio a maior tarefa de engenharia que já deixei preparada.
No meu caso, isso normalmente significa uma migração completa para TypeScript, limpeza de ESLint em todo o repositório, uma revisão profunda de bugs em uma codebase ou uma grande refatoração estrutural. Costumo deixar vários projetos preparados com antecedência, para que a parte final do uso vá para o trabalho pesado que realmente está pronto para começar.
O motivo é uma observação recorrente. Mais de uma vez iniciei trabalho substancial perto do fim do limite visível e depois vi o Codex continuar trabalhando mesmo quando esse limite parecia já ter sido esgotado. Em alguns casos a tarefa avançou o suficiente para terminar. Isso aconteceu vezes suficientes para mudar meu planejamento, mas não para virar uma garantia do produto.
A observação que mudou meu workflow
Perto de um limite de uso, o instinto natural é ficar conservador: gastar o último pedaço em pedidos pequenos porque uma tarefa grande pode ser interrompida. Hoje trato os últimos 3–5% de outra forma. Para mim, eles são uma janela de lançamento.
A pergunta útil deixou de ser “quantos prompts pequenos ainda cabem?” e passou a ser “qual é a tarefa preparada mais valiosa que posso iniciar enquanto ainda tenho uso incluído disponível?”.
Isso só funciona porque o projeto já está pronto e a tarefa claramente definida. Não uso os últimos pontos percentuais para descobrir o que precisa ser feito. Uso para começar a execução.
Uma correção importante sobre nome e limites
Eu chamava isso de “Codex Plus”, mas é um atalho informal, não o nome oficial do produto. A OpenAI descreve Codex como incluído no ChatGPT Plus. Vale corrigir isso para não dar a impressão de que Codex Plus é um plano ou produto separado.
A documentação atual da OpenAI sobre uso do Codex também diz que o consumo varia conforme o tamanho e a complexidade do trabalho, o modelo e onde a tarefa é executada. Ela documenta janelas de uso que incluem uma janela de 5 horas e uma janela semanal. Portanto, quando digo “3–5%”, quero dizer o percentual restante mostrado pela interface de uso, não 3–5% de tempo real, tokens ou uma quantidade garantida de trabalho de engenharia.
Usuários Plus elegíveis também podem estender o uso do Codex com créditos depois de alcançar a cota incluída. Isso não invalida o workflow; apenas deixa o limite conceitual mais claro. Estou descrevendo como distribuo meu uso incluído, não uma forma de contornar quota.
O que inicio nos últimos 3–5%
As tarefas que costumo reservar para esse momento são operações de engenharia amplas:
- migrações completas para TypeScript
- limpeza de ESLint em todo o repositório
- revisões profundas de bugs em codebases grandes
- grandes refatorações estruturais
Prefiro iniciar um desses trabalhos como uma unidade substancial em vez de dividir o restante em uma sequência de pedidos de pouco valor. Nesse tipo de tarefa, um repositório preparado e um objetivo claro importam mais do que uma formulação especialmente esperta do prompt.
Ter vários projetos prontos ajuda pelo mesmo motivo. Se um repositório ainda precisa de decisões ou setup, não desperdiço a última janela preparando-o; posso começar em outro projeto que já esteja pronto.
Preparação é a restrição real
O truque não é “esperar chegar a 3% e colar um prompt enorme”. Se a tarefa é ambígua, um orçamento limitado pode desaparecer em exploração, esclarecimentos ou trabalho na direção errada. Meu padrão só é útil quando o projeto está pronto para execução e a tarefa tem escopo bem definido.
Para quem quiser testar algo parecido, um preflight útil é explicitar o escopo: o que deve mudar, o que não deve mudar, quais constraints existem, como o resultado será validado e qual output se espera do agente. São salvaguardas gerais de engenharia, não prova de que um formato específico de prompt desbloqueia mais uso.
Essa preparação também facilita retomar uma tarefa grande se o limite realmente a interromper. Uma migração ou review parcial é muito mais simples de continuar quando scope e critérios de validação estavam claros desde o início.
O que posso confirmar — e o que não posso
O que posso confirmar pela minha própria experiência é restrito: em várias ocasiões, uma tarefa já iniciada continuou avançando depois que o limite visível parecia esgotado e, às vezes, foi concluída.
O que não posso confirmar é o mecanismo. Não posso afirmar que a OpenAI dá a toda tarefa em execução um grace period oculto, que os últimos 3–5% bastam para concluir qualquer trabalho grande, que o comportamento é estável ou que seja uma forma de contornar o limite. A documentação da OpenAI não promete nada disso.
Essa distinção importa. Eu planejo levando em conta um comportamento que observei repetidamente, mas não dependo dele. Se a tarefa parar no limite, isso não é evidência de que algo quebrou. A estratégia ainda cumpriu seu objetivo se usei o restante incluído em algo mais importante do que alguns prompts minúsculos.
Uma tarefa concluída não é uma tarefa verificada
Quanto maior a tarefa, mais importante fica uma segunda distinção: conclusão não é correção. Uma migração TypeScript que faz build não prova comportamento correto em runtime. Um ESLint limpo não prova lógica de negócio correta. Uma revisão que sinaliza um padrão suspeito não confirmou necessariamente um bug real. Até uma refatoração com testes verdes é tão confiável quanto os testes e checks que a cobrem.
Esse workflow muda quando começo o trabalho. Não reduz o padrão de validação. Grandes mudanças agentic ainda precisam dos controles adequados ao risco: diff review, typecheck, testes, build, runtime checks ou verificação específica do projeto.
Quando esse padrão não encaixa bem
Nem toda tarefa grande é boa para o fim do limite. A abordagem é mais fraca quando o trabalho ainda está indefinido, exige decisões frequentes de produto, envolve operações destrutivas ou sensíveis em produção, ou deixa o repositório em um estado perigoso se for interrompido pela metade.
Nesses casos, uma tarefa menor e bem delimitada ou uma nova janela de uso costuma ser uma escolha de engenharia melhor. O objetivo não é tornar o último prompt dramático, mas investir uso incluído escasso em trabalho que consiga produzir progresso útil com segurança.
Minha regra agora
Quando meu uso incluído do Codex no ChatGPT Plus cai para cerca de 3–5%, paro de otimizar o número de prompts restantes. Olho os projetos que preparei e inicio a tarefa de engenharia mais pesada, claramente delimitada e realmente valiosa.
Se o Codex continuar trabalhando depois que o contador visível chega a zero, trato isso como um comportamento útil que observei, não como um direito. Se parar, não me surpreendo. Não encontrei uma forma de contornar o limite. Encontrei uma forma melhor de decidir o que começar antes de atingi-lo.