Planeje no ChatGPT Pro, Execute no Codex: O Playbook de Transferência de Documentos de Design

O fluxo de trabalho que vale a pena copiar este mês não é um modelo, é uma divisão de trabalho. Você entrega GPT-6 Pro no ChatGPT a URL de um repositório, pede a ele um documento de design em vez de um patch, e entrega esse documento ao Codex ou ao Claude Code para implementar. O planejador roda no GPT-6 Astra — GPT-6 Pro é o nome que os limites de uso do ChatGPT usam para ele — e o Astra é um modelo de 2026-09-03, então nada aqui é cobertura de lançamento nem uma alegação de lançamento. O que mudou nos últimos sete dias é mais restrito, e vale enunciar com exatidão: em 2026-09-17, profissionais relataram que o plugin oficial do GitHub no ChatGPT Chat comum, não no ChatGPT Work e não no Codex, pode editar arquivos de repositório, fazer commit e abrir pull requests sem consumir a cota do Codex/Work. Isso é uma alegação da comunidade, não documentação do fornecedor — as páginas de ajuda oficiais ainda descrevem o app do GitHub como somente leitura e encaminham toda escrita pelo Codex — e as ressalvas associadas a ela importam tanto quanto a própria alegação. Tudo abaixo está rotulado como relatado pelo fornecedor, relatado pela comunidade, ou lido nas páginas oficiais em 2026-09-19.

O fluxo de trabalho, em uma única passagem

Profissionais descrevem o mesmo ciclo com pequenas variações. O que se repete: colar um endereço do GitHub no ChatGPT, pedir que ele leia o código e produza um documento de design, depois baixar esse documento e alimentar um agente de execução com ele. Alguns também pedem um pull request; outros param no documento e deixam a escrita por conta do executor. De qualquer forma, o formato é idêntico — planejar no produto de chat, construir no produto de agente — e a razão pela qual vale a pena copiá-lo é que as duas metades são medidas separadamente.

• Artefacto de planeamento — um documento de design: as interfaces a adicionar, os ficheiros a alterar identificados por caminho, a ordem de migração, os testes de aceitação e o que fazer se algo correr mal.

• Artefato de execução — um branch e um pull request, produzidos por um agente capaz de executar os testes que acabou de escrever.

• Artefato de revisão — o diff, que é a única coisa que deveria chegar a um revisor.

O documento de design é a peça de sustentação, e merece seu lugar por dois motivos. Primeiro, um documento é portátil: o mesmo texto funciona quer o executor seja o Codex, o Claude Code ou um agente com scripts que você mesmo escreveu, de modo que o planejamento pelo qual você pagou não fica atrelado à ferramenta de um único fornecedor. Segundo, ele é a superfície de revisão que existe antes de qualquer coisa ser escrita no seu repositório — o que importa muito, dado que o caminho de escrita no produto de chat é a parte menos documentada de todo o arranjo.

Por que a estrutura de dois buckets é todo o truque

O ChatGPT não cobra este fluxo de trabalho de uma única verba. Chat, ChatGPT Work e Codex têm cotas separadas, e Work e Codex compartilham um único pool entre si; uma chave da API OpenAI é cobrada separadamente, de novo. É essa estrutura que torna a transferência econômica: o pensamento acontece no pool do Chat, a execução acontece no pool do agente, e um documento de design custa uma mensagem do Chat, enquanto a implementação custa uso do agente.

Os números, tal como a OpenAI os publica para o lado do Chat — valores informados pelo fornecedor na própria documentação do plano do fornecedor, e não medições:

• ChatGPT Pro a $200 por mês — 200 mensagens do GPT-6 Pro por semana; o GPT-5.6 Sol Pro ainda oferece 170 por dia, com os dois modelos juntos limitados a 200 por dia.

• ChatGPT Pro a $100 por mês — 50 mensagens GPT-6 Pro por semana, retiradas de uma cota compartilhada com o GPT-5.6 Sol Pro.

• Business Standard — 15 mensagens GPT-6 Pro por mês, compartilhadas com o Sol Pro; Business Premium — 50 por semana na mesma base compartilhada.

• ChatGPT Plus — não há GPT-6 Pro no Chat, de forma alguma. A Astra só chega ao Plus por meio do ChatGPT Work e do Codex, que é exatamente a categoria que este playbook está tentando proteger.

Do lado do Work/Codex, a OpenAI publica estimativas em vez de limites, e assume isso: cerca de 5 a 45 mensagens do Astra por janela de cinco horas no Plus, 25 a 225 no Pro 5x, e 100 a 900 no Pro 20x, com a mesma página observando que o consumo real varia conforme a complexidade da tarefa, o contexto, a saída e o uso de ferramentas, e que limites semanais podem ser aplicados por cima. Essas faixas ficam em cerca de metade dos números equivalentes do Sol, que é a razão aritmética pela qual um modelo de fronteira é minimamente viável de executar como agente.

A consequência prática é uma regra de orçamento que você pode anotar num cartão. Reserve mensagens do Chat para decisões e o uso de agentes para código. Uma sessão de planejamento que discute uma interface por vinte minutos custa um punhado de mensagens do Chat e produz um documento que poupa a um agente uma hora de edições exploratórias — que é a troca que os profissionais da thread estão de fato fazendo.

O caminho de escrita: o que o conector faz e o que as pessoas afirmam que ele faz

Aqui as fontes divergem, e a divergência é a parte interessante.

A documentação de ajuda da própria OpenAI é inequívoca: o aplicativo GitHub no ChatGPT lê seus repositórios para análise e pesquisa, e gerar código, editá-lo e enviá-lo ao GitHub é para isso que o Codex serve. Essa é a posição somente leitura, e é com ela que você deve planejar se for incluir isso em um processo de equipe, porque é a que tem um fornecedor por trás.

A posição da comunidade, datada de 2026-09-17, é que o plugin do GitHub da versão web no modo Chat vai editar código, fazer commit e abrir pull requests, e que, por ser um plugin oficial e não um servidor MCP de terceiros, ele não consome cota do Codex nem do Work. O mesmo tópico é cauteloso quanto ao escopo: ferramentas pequenas, edições pequenas, bugs pequenos — grandes refatorações e depuração difícil ainda pertencem ao Codex. Seus próprios comentaristas acrescentam as ressalvas que vale a pena repetir, porque são elas que doem:

• Os limites de uso normais do ChatGPT continuam a aplicar-se. "Não é cota do Codex" não é "grátis".

• A qualidade pode se degradar após várias rodadas sem aviso, com a sessão mudando para um modelo menor no meio da tarefa.

• Os autores do thread aconselham não mudar para o Work quando a interface o oferece, e alertam que sobrecarregar páginas de chat anónimas degrada a experiência web para todos.

Uma análise japonesa independente do mesmo padrão chega a uma conclusão compatível sem a alegação de cota: se uma integração do GitHub oferece suporte a ações de escrita, o chat comum consegue ler um repositório, modificar arquivos, criar um branch e abrir um pull request; aplicam-se os limites de taxa normais do chat; e Codex e Work recorrem ao pool compartilhado de agentes, então o chat comum serve para editar alguns arquivos e o Codex para tarefas longas de software. Onde as duas versões concordam, a concordância é a parte aproveitável: o chat é um canal para pequenas mudanças, o Codex é o canal para sessões longas, e os pools são separados.

Existem servidores MCP de terceiros que expõem um fluxo de trabalho git real — branch, diff, commit, push, abrir um pull request — com permissões que você pode escalonar de somente leitura até push. Se você quer que o caminho de escrita seja determinístico e auditável, em vez de um comportamento que você espera que aconteça, esse é o caminho; se você quer ficar dentro do que a OpenAI documenta, planeje no Chat e escreva no Codex.

De qualquer forma, a transferência do documento de design é o que torna defensável o caminho de escrita do chat. Uma sessão de chat com escopo de escrita num repositório é uma concessão de permissão maior do que uma sessão de chat com escopo de leitura, e o documento é o artefato que você revisa antes de essa concessão ser exercida.

A passagem de bastão, passo a passo

• Aponte o planejador para o repositório — uma URL pública colada no prompt, ou o conector do GitHub, se você o tiver autorizado — e peça que ele leia o código antes de propor qualquer coisa.

• Peça um documento de design, não um patch. Exija os caminhos dos arquivos, as interfaces que estão sendo adicionadas ou alteradas, a ordem em que as mudanças devem ser aplicadas e os testes que comprovam cada etapa.

• Peça-lhe que cite os arquivos que ele realmente leu. Um documento de design que descreve uma interface que o repositório não possui é a forma mais comum de este fluxo de trabalho falhar, e as citações são como você percebe isso em um minuto em vez de um sprint.

• Salve o documento no repositório em vez de colá-lo na próxima ferramenta. Um executor que lê um arquivo pode lê-lo novamente; um executor que recebeu um texto colado tem apenas uma chance.

• Inicie o executor com o documento como sua instrução, e limite um pull request a uma seção dele. Sessões longas são onde a qualidade do agente se degrada silenciosamente.

• Mantenha o planejador em um papel apenas de revisão depois disso. Quando o documento estiver errado, replaneje e atualize o documento — não permita que o executor improvise por cima dele, porque o trabalho improvisado é justamente o que o documento existia para evitar.

Onde quebra.

• Estado obsoleto do repositório — o planejador leu o branch padrão enquanto você está trabalhando em um branch de feature, então os caminhos de arquivo no documento estão uma versão atrás. Informe qual branch deve ser lido, ou cole a árvore de branches.

• Desvio do documento de design — o documento e o código divergem, e o executor segue o documento. A etapa dos arquivos citados acima é o seguro barato.

• Surpresa de cota na direção errada — uma conversa de planejamento de vinte minutos é barata em mensagens de Chat e cara em atenção; uma longa execução de agente é o contrário. Orce o bucket que você está realmente gastando.

• Degradação silenciosa — uma sessão de chat que é rebaixada para um modelo menor após várias rodadas ainda produzirá um documento de design confiante. Avalie o documento por seus méritos, e não partindo do pressuposto de que o modelo principal o escreveu.

• Aumento gradual de permissões — o caminho de escrita, seja por meio de um plugin ou de um servidor MCP, concede a uma sessão de chat a capacidade de alterar seu código. Organize as permissões em níveis e revogue-as quando a alteração for aplicada.

Executando a metade do executor através de um endpoint.

A metade do planejamento deste fluxo de trabalho vive dentro de um produto por assinatura, e essa parte é o que é. A metade da execução é uma chamada de API, e é essa a metade que vale a pena ter em mãos. Se você escrever um script para o executor — um pequeno loop de agente, um job de CI que transforma um documento de design aprovado em um branch —, a chamada ao modelo é a única peça que precisa ser trocável, porque o modelo que você vai querer no próximo trimestre não é o modelo em torno do qual você está planejando hoje.

É para isso que serve uma camada de roteamento. openai/gpt-6-astra fica atrás do mesmo endpoint compatível com a OpenAI que mais de 200 outros modelos, com o preço de tabela do provedor repassado com 0% de markup — então, quando um fornecedor altera um preço, o preço do nosso lado muda no mesmo dia, e não na próxima renovação de contrato. O failover automático permite colocar um modelo não comprovado em uma fatia do tráfego com um modelo comprovado por baixo, que é a forma honesta de descobrir se um executor barato é bom o suficiente para seus testes. E a DSL de roteamento compõe vários modelos em uma única chamada, para que um modelo revisor possa verificar o diff do executor na mesma chave, no mesmo caminho da requisição, sem uma segunda integração.

Nada disso muda a estrutura do handoff. Muda o custo de experimentar com a metade que você controla: uma chave, um endpoint e uma string de modelo que você pode alterar sem tocar no pipeline.

Quem deve executar isto agora, e quem deve esperar

Se você já paga por um plano do ChatGPT no nível Pro e já usa o Codex ou o Claude Code, vale a pena adotar o handoff esta semana, porque os dois conjuntos já estão separados na sua fatura e o documento de design é a coisa mais barata do ciclo. Comece com uma mudança que você entende bem o suficiente para identificar um plano ruim: peça o documento, leia os arquivos citados e então faça a entrega.

Se você estiver no Plus, modere a expectativa. O Astra chega até você pelo Work e pelo Codex, mas não pelo Chat, então a metade de planejamento deste playbook não está disponível para você na forma descrita — você estaria planejando e executando a partir do mesmo pool, o que elimina o argumento econômico e deixa apenas a disciplina de escrever o documento primeiro. Essa disciplina ainda vale a pena. O desconto, não.

E se o seu motivo para querer isto for o caminho de escrita no Chat e não a transferência, espere que a documentação da OpenAI se atualize para acompanhar o tópico do fórum. Uma capacidade que as próprias páginas de ajuda do fornecedor contradizem é uma capacidade a manter num repositório de rascunho até que as páginas mudem.

A mesma chave alcança o resto do catálogo, e você pode navegar pelo catálogo completo de modelos para ver o que mais está por trás de um endpoint compatível com OpenAI.