Como escolher o modelo: com a mesma frase, qual modelo realmente deve rodar
📚 Navegação da série: O anterior 〔29 Integração com Slack / Linear e SDK〕 abordou o uso avançado de 'chamar o Codex de outros locais e integrá-lo ao seu próprio produto'. Este artigo traz o foco de volta para a decisão mais cotidiana no ambiente local — no momento em que você pressiona Enter, qual modelo está nos bastidores e com quanta força ele está trabalhando para você. O próximo artigo 〔31 Dicas avançadas e aceleração〕 explicará como tornar todo o fluxo mais rápido e econômico.
Dizem que "escolher o modelo mais forte nunca falha", e eu acreditei nisso por um bom tempo.
Houve um tempo em que eu travei o modelo padrão no gpt-5.5 e levei o esforço de raciocínio ao máximo em xhigh, buscando "resolver tudo de uma vez e não ter mais dor de cabeça". Até o dia em que pedi para ele alterar o nome de uma variável de data para payload — um trabalho manual de trinta segundos. Ele "pensou profundamente" por quase um minuto antes de começar a agir. Enquanto eu olhava para aquela animação giratória do raciocínio, pela primeira vez achei que o "mais forte" parecia um pouco bobo.
Para ser sincero, o modelo não precisa ser o mais forte, mas sim o mais adequado. Usar o modelo topo de linha com raciocínio máximo para corrigir um erro de digitação é o mesmo que dirigir uma escavadeira para arrancar uma erva daninha — é lento, caro e faz parecer que você não sabe usá-lo. Por outro lado, se você enfrentar o desafio de refatorar um módulo inteiro e usar um modelo leve buscando rapidez, ele poderá lhe entregar uma solução que parece funcionar, mas que na verdade esconde três armadilhas. O tempo necessário para refazer o trabalho seria suficiente para rodar cinco vezes usando um bom modelo.
Este artigo vai esclarecer completamente a questão de "quem enviar": quais modelos o Codex tem atualmente, um botão que traz resultados ainda mais imediatos do que trocar de modelo (o esforço de raciocínio) e uma tabela comparativa de "cenário → modelo + esforço" que eu mesmo utilizo todos os dias. Depois de ler, você não ficará mais confuso ao abrir o painel /model.
Ao terminar de ler este artigo, você obterá:
- Um framework de decisão sem precisar decorar parâmetros: escolher um modelo consiste essencialmente em alinhar "o quão difícil é a tarefa" com "quanta capacidade computacional deve ser dedicada"
- O posicionamento de cada um dos modelos atualmente disponíveis no Codex: qual é o padrão e quais dois já foram descontinuados
- Um botão que os iniciantes costumam ignorar, mas que traz resultados mais imediatos do que trocar de modelo — o esforço de raciocínio (reasoning effort)
- Uma tabela comparativa pronta para usar de "qual modelo enviar para qual tarefa + qual esforço de raciocínio configurar"
- Quatro formas de alternar: alterar o padrão, definir na inicialização, alternar temporariamente na sessão e configurar individualmente para subagentes
- Um guia prático passo a passo para sentir na pele a diferença entre "a mesma frase sob diferentes configurações"
⚠️ Os nomes dos modelos e a disponibilidade variam de acordo com as versões e os planos (por exemplo, qual é o topo de linha mais recente e quais a sua conta permite escolher). Este artigo aborda os métodos de "como avaliar e como alternar". Quais modelos específicos estão disponíveis depende estritamente do que é exibido no seu painel
/modellocal; não decore os nomes. Os comandos e itens de configuração correspondentes devem seguir a documentação oficial do Codex.
01 Pense bem primeiro: escolher um modelo não significa "escolher o mais caro"
A conclusão antecipada: escolher um modelo consiste essencialmente em alinhar "o quão difícil é a tarefa" com "quanta capacidade computacional deve ser dedicada" — qualquer excesso é desperdício, e qualquer falta causará falhas.
Muitas pessoas (incluindo eu no passado) assumem que "escolher o mais forte é sempre a decisão certa, já que o limite de capacidade não falhará". A falha nessa linha de raciocínio é que ela só calcula se o modelo "pode fazer o trabalho corretamente", sem considerar "quanto tempo vai demorar" e "quanto vai custar". Mas no desenvolvimento real, esses dois fatores afetam você diariamente —
- Você interage com o Codex dezenas de vezes por dia. Se esperar trinta segundos a mais em cada rodada, passará quase meia hora por dia esperando a animação girar.
- Se usar planos de assinatura, há um limite de cota; se usar uma chave de API, consumirá saldo diretamente. O preço por token dos modelos topo de linha é várias vezes maior do que o dos modelos leves.
Portanto, antes de escolher um modelo, considere três variáveis em mente:
Quão complexo é este trabalho? Quanto tempo posso esperar? Eu me importo com este custo adicional? Ao ponderar esses três pontos, você saberá exatamente quem enviar.
| Sua situação | Direção a escolher |
|---|---|
| Trabalho difícil (arquitetura, refatoração de vários módulos, bugs complexos) | Vá com o topo de linha, dê bastante esforço de raciocínio, priorize a precisão |
| Trabalho simples (renomear, adicionar comentários, escrever uma função curta) | Use modelos leves, baixo esforço de raciocínio, buscando rapidez e economia |
| Respostas instantâneas (programação em par em tempo real, perguntas e respostas rápidas) | Use modelos otimizados para resposta imediata, sem fazê-lo "pensar demais" |
💡 Resumo em uma frase: Escolher um modelo não é escolher o mais forte, mas sim fazer com que a "capacidade computacional" atenda à "dificuldade da tarefa".
02 Quais modelos o Codex permite escolher atualmente
Ao abrir o painel /model, você verá uma lista de nomes. A primeira reação de um iniciante costuma ser de confusão. Não se preocupe, grave o posicionamento deles e não os parâmetros.
Analogia: escolher um modelo é como delegar tarefas a pessoas. Para tarefas de arquitetura complexas, você escala o profissional mais experiente e com pensamento mais profundo (o topo de linha); para pequenos ajustes cotidianos, um estagiário ágil é o suficiente (o modelo leve); para programação em par presencial, em que você pergunta e ele responde em segundos, escale aquele com a resposta mais rápida (o modelo de tempo real). Escalar a pessoa certa traz o dobro do resultado com metade do esforço; escalar errado significa subutilizar um talento ou sobrecarregar quem não é capaz.
Quais modelos do Codex estão disponíveis atualmente e qual o seu posicionamento geral:
| Modelo | Posicionamento | Ideal para | Velocidade / Custo |
|---|---|---|---|
gpt-5.5 | Topo de linha, recomendado por padrão | Programação complexa, operações de computador, trabalho de conhecimento, fluxos de pesquisa | Mais lento / Mais alto |
gpt-5.4-mini | Leve, rápido e econômico | Tarefas de programação leves, uso em subagentes | Rápido / Baixo |
gpt-5.3-codex-spark | Tempo real (pré-visualização de pesquisa) | Iterações de programação de alta frequência quase em tempo real (focado em texto simples, menor capacidade) | Extremamente rápido / Baixo |
Alguns pontos fundamentais para evitar problemas:
- Se não for especificado, usará o padrão. Se você nunca fez nenhuma configuração, o Codex (App / CLI / extensão de IDE) usará automaticamente o modelo topo de linha recomendado, o que é suficiente para a maioria dos casos.
- O
gpt-5.3-codex-sparké uma pré-visualização de pesquisa (research preview) e atualmente está disponível apenas para assinaturas do ChatGPT Pro. Se você não o vir, é perfeitamente normal, não significa que instalou algo errado. - Existem dois nomes que você pode ter visto em tutoriais antigos, mas que não devem mais ser usados:
gpt-5.2egpt-5.3-codexforam marcados oficialmente como obsoletos (deprecated) sob o método de login do ChatGPT. Se os seus scripts,config.tomloucodex exec --modelainda fizerem referência a eles, substitua-os pelos mais recentes o quanto antes. Alguns modelos obsoletos ainda podem ser acessados via API, mas isso exige o login com uma chave de API, estando sujeito ao que é indicado na página oficial de modelos de API.
A combinação que eu pessoalmente mais uso é: a sessão principal roda com o topo de linha, enquanto tarefas repetitivas em lote são delegadas a subagentes rodando o gpt-5.4-mini. No mês passado, ao limpar imports expirados em mais de vinte arquivos de um projeto, pedi para o agente principal dividir o trabalho e acionei mais de dez subagentes executando em paralelo com o mini para realizar as alterações. Tudo ficou pronto em poucos minutos — para tarefas volumosas e simples como essa, a vantagem do mini em velocidade e custo é evidente, e usar o modelo topo de linha seria apenas desperdício de dinheiro para esperar pelo mesmo resultado.
💡 Resumo em uma frase: Memorize o posicionamento e não os parâmetros — o topo de linha resolve tarefas difíceis, o mini cuida do rápido e econômico, e o spark lida com respostas em segundos; não escreva os dois nomes obsoletos nos seus arquivos de configuração.
Ao colocar os três modelos neste gráfico de "Dificuldade da tarefa × Velocidade e Custo", tudo fica claro: quanto mais à direita e abaixo, mais difícil é a tarefa e mais forte — porém mais lento e caro — é o modelo (topo de linha gpt-5.5); quanto mais à esquerda e acima, mais rápido e econômico ele se torna (mini, spark) — escolher o modelo ideal é apenas encaixar a tarefa atual na sua posição correspondente.
03 Um botão mais imediato do que trocar de modelo: o esforço de raciocínio
Enquanto os iniciantes se concentram em "qual modelo escolher", os usuários experientes também ajustam outro botão — o esforço de raciocínio (reasoning effort). Muitas pessoas nem sequer notam esse ajuste, mas o impacto dele na experiência costuma ser mais direto do que trocar de modelo.
Analogia: o esforço de raciocínio é como o tempo de reflexão dado a alguém antes de responder a uma pergunta. Mesmo para o melhor aluno (o mesmo modelo), responder após uma leitura rápida gera um resultado muito diferente de deixá-lo fazer rascunhos e revisar as contas antes de entregar — embora o último caso demore visivelmente mais. O esforço de raciocínio ajusta exatamente "quanto tempo deixamos o modelo pensar antes de agir".
O esforço de raciocínio do Codex é dividido em cinco níveis (aplicável apenas aos modelos compatíveis e à Responses API):
| Nível | Significado | Indicado para |
|---|---|---|
minimal | Praticamente sem pensamento extra, respostas em segundos | Tarefas muito simples, perguntas e respostas de alta frequência |
low | Análise leve | Pequenas alterações, iterações rápidas |
medium | Equilíbrio entre velocidade e profundidade (nível padrão comum) | Maioria da programação diária |
high | Raciocínio profundo | Refatorações complexas, bugs difíceis |
xhigh | Raciocínio máximo (depende do suporte do modelo) | Projetos de arquitetura e depurações mais complexos |
Observe dois pontos: medium geralmente é o ponto de partida padrão (o valor padrão exato depende da sua versão local); xhigh não é aceito por todos os modelos — para testar a compatibilidade, tente selecioná-lo diretamente no painel /model. Se não for suportado ou gerar um erro, o painel costuma exibir um aviso; você também pode consultar a página oficial de especificações do modelo atual para confirmar.
Essa é a verdade por trás do caso de "esperar um minuto para alterar o nome de uma variável" citado no início — não era porque o modelo era incapaz, mas sim porque eu configurei o esforço de raciocínio em xhigh. Ele estava pensando demais em um trabalho simples que não exigia raciocínio nenhum. Por outro lado, em uma ocasião em que eu investigava um bug de concorrência intermitente, o modelo ficou perdido por um bom tempo no nível comum. Aumentei o esforço para high e executei a tarefa novamente; só então ele conseguiu se aprofundar e mapear com precisão a origem da condição de corrida.
Portanto, se não estiver satisfeito com o resultado, não se apresse em mudar para um modelo mais forte — em muitos casos, aumentar o esforço de raciocínio em um nível resolve o problema; se achar que está lento, reduza-o em um nível. Este botão é mais leve e traz resultados mais rápidos do que trocar de modelo.
💡 Resumo em uma frase: Antes de trocar de modelo, pense no esforço de raciocínio — se achá-lo insatisfatório, aumente um nível; se achar lento, diminua um nível. Geralmente, basta um ajuste para resolver.
04 Tabela de referência prática: qual tarefa enviar para qual modelo + qual esforço
Explicar apenas os conceitos não é tão bom quanto dar uma receita direta. A tabela abaixo é o guia de "cenário → modelo + esforço de raciocínio" que uso no meu dia a dia; você pode copiá-la e ajustá-la aos seus hábitos:
| Cenário | Modelo recomendado | Esforço de raciocínio |
|---|---|---|
| Design de arquitetura, seleção de tecnologias | gpt-5.5 | high / xhigh |
| Refatoração de vários módulos, alterações complexas | gpt-5.5 | high |
| Depuração de bugs complexos / intermitentes | gpt-5.5 | high |
| Desenvolvimento de funções rotineiras, adição de lógica | gpt-5.5 | medium |
| Correção de bugs simples, formatação, adição de comentários | gpt-5.4-mini | low |
| Subagentes processando tarefas simples em lote | gpt-5.4-mini | low / medium |
| Programação em par em tempo real, perguntas e respostas rápidas | gpt-5.3-codex-spark | minimal |
Como usar esta tabela? Não se preocupe muito no início. Comece com as configurações normais (topo de linha + medium) e ajuste pontualmente conforme encontrar gargalos específicos:
- Se a solução entregue for muito superficial ou ignorar casos de borda → aumente o esforço para
high. - Se um volume grande de tarefas mecânicas simples estiver atrasando você → mude para o
gpt-5.4-minie execute em lote em um nível menor. - Se você quer apenas fazer uma série de perguntas curtas de forma consecutiva e não quer esperar que ele pense → use um modelo de tempo real com nível
minimal.
Meu hábito real é: deixar a configuração padrão como "topo de linha + medium". Não altero isso para a grande maioria das tarefas. Eu só mudo manualmente ao entrar nos modos de "resolver problemas difíceis" ou "processar trabalhos repetitivos em lote". Pense nessa alternância como uma chave de fenda na caixa de ferramentas que você usa apenas quando necessário, e não como um martelo que carrega o tempo todo — use-a quando se lembrar, sem precisar se estressar a cada comando.
💡 Resumo em uma frase: Use o padrão "topo de linha + medium" para a maior parte das tarefas e mude manualmente apenas nos momentos de "resolver problemas difíceis" e "processar tarefas repetitivas em lote".
05 Quatro formas de alternar: padrão, inicialização, sessão e subagente
Saber qual escolher é uma coisa, mas você também precisa saber como alternar. O Codex oferece quatro formas de fazer isso, atendendo desde necessidades de "configuração definitiva" até "apenas desta vez".
① Configurar o modelo padrão (definitivo). Escreva uma linha no arquivo de configuração ~/.codex/config.toml e as inicializações futuras usarão esse modelo:
# ~/.codex/config.toml
model = "gpt-5.5"
model_reasoning_effort = "medium"② Especificar temporariamente na inicialização (apenas nesta sessão). Use a tag -m / --model :
# 用指定模型起一个新会话
codex -m gpt-5.5
# codex exec 非交互模式同样适用
codex exec -m gpt-5.4-mini "把这个文件里的过期 import 清理掉"③ Alternar durante a sessão em andamento (mudar no meio do caminho). Digite o comando de barra diretamente na sessão do Codex para abrir o seletor e escolha o modelo para o qual deseja alternar:
/modelNo novo painel /model, geralmente é possível escolher o esforço de raciocínio ao mesmo tempo em que seleciona o modelo. A aparência exata depende do seu painel local.
④ Configurar individualmente para subagentes (divisão de trabalho). O agente principal usa o modelo topo de linha para a coordenação geral e delega tarefas simples em lote para subagentes executando o gpt-5.4-mini — esta é a estratégia com melhor custo-benefício. Para mais detalhes, consulte 〔21 Subagentes (Subagents)〕.
Compare as quatro formas de alternar:
| Método | Como fazer | Escopo de efeito | Quando usar |
|---|---|---|---|
| Alterar padrão | Escrever model no config.toml | Todas as sessões futuras | Quando você tem um modelo principal estável |
| Especificar na inicialização | codex -m <模型> | Apenas a sessão atual | Para iniciar um trabalho trocando temporariamente de modelo |
| Alternar na sessão | /model | Após o ponto de transição | Quando percebe no meio do caminho que deve mudar de modelo |
| Configurar no subagente | Especificar nas configurações do subagente | Aquele subagente específico | Coordenação principal, terceirização de tarefas secundárias |
⚠️ Uma exceção: as tarefas do Codex Cloud na nuvem atualmente não permitem alterar o modelo padrão, este ponto está sujeito às instruções oficiais.
💡 Resumo em uma frase: Altere o config em definitivo, use
-mpara trabalhos temporários, digite/modelpara mudar no meio do caminho e terceirize tarefas secundárias para subagentes com o mini.
06 Dois pequenos seletores para melhorar a experiência
Com o modelo e o esforço definidos, ainda existem dois pequenos seletores que podem tornar a experiência mais prática. É bom saber que eles existem, mas você não precisa se preocupar com eles logo no início.
① Resumo de raciocínio (model_reasoning_summary) — o quanto você deseja ver do "processo de pensamento" dele. Os valores aceitos são auto / concise / detailed / none. Se quiser ver como ele pensa passo a passo, configure para detailed; se achar que está poluindo a tela, defina como none para desativar:
# ~/.codex/config.toml
model_reasoning_summary = "concise"② Nível de serviço (service_tier) — define a prioridade da sua requisição. Opções integradas: flex (flexível, otimiza custos, pode ser um pouco mais lento) e fast (prioriza velocidade). Se você estiver com pressa e não se importar com o custo extra, pode testar o fast — note que a documentação oficial exige a inclusão de uma feature flag correspondente para ter efeito:
# ~/.codex/config.toml
# 弹性模式（默认）
service_tier = "flex"
# 快速模式：需同时开启 feature flag，否则不生效
service_tier = "fast"
[features]
fast_mode = trueAmbos são detalhes para ajustar quando você estiver mais familiarizado; os iniciantes podem manter as configurações padrão sem problemas.
💡 Resumo em uma frase: O resumo de raciocínio controla "se exibe ou não o processo de pensamento", e o nível de serviço controla "se a fila tem prioridade ou não". Os iniciantes podem usar os padrões.
07 Prática: sinta a diferença de "a mesma frase sob diferentes configurações"
Olhar as tabelas não é suficiente; você só notará a diferença quando ajustar os botões por conta própria. Siga estas três etapas rápidas de cinco minutos.
Etapa 1: veja quais modelos a sua conta pode escolher.
Entre em uma sessão do Codex e digite:
/modelRetorno esperado: um seletor de modelos será exibido, listando os modelos disponíveis para a sua conta/plano atual (é normal que o que é exibido varie para cada pessoa). Identifique quais modelos estão disponíveis e qual deles está selecionado no momento.
Etapa 2: defina uma configuração padrão.
Abra o arquivo ~/.codex/config.toml (crie um novo se não existir) e adicione:
model = "gpt-5.5"
model_reasoning_effort = "medium"Após salvar, abra uma nova sessão e digite /model para confirmar que o modelo e o esforço atuais correspondem ao que você acabou de configurar.
Etapa 3: envie a mesma frase com dois esforços de raciocínio diferentes e compare a diferença.
Escolha uma solicitação que tenha um nível moderado de complexidade, como: "Ajude-me a refatorar esta função para torná-la mais testável e explique suas escolhas."
- Execute a tarefa primeiro usando o nível padrão
mediume observe: quanto tempo demorou e quão abrangente foi a solução proposta. - Altere o
model_reasoning_effortna configuração parahigh, abra uma nova sessão e execute a mesma frase novamente.
Como esperado, você observará que: a execução com high é visivelmente mais lenta, mas a solução costuma ser mais profunda — por exemplo, considerando mais casos de borda, fornecendo alternativas ou explicações sobre as escolhas de design. Ao sentir na prática essa relação de compromisso entre "mais lento e mais profundo", você terá mais facilidade para ajustar os níveis no futuro, sem precisar decorar tabelas.
💡 Resumo em uma frase: Veja o que está disponível no seletor, defina o padrão no arquivo de configuração e depois execute a mesma frase em dois níveis para comparar — a prática é muito melhor do que tentar decorar os parâmetros.
Resumo
Este artigo dividiu a decisão de "quem enviar para trabalhar" em dois botões de ajuste e uma estratégia de uso:
- A essência da escolha de modelos: alinhar a dificuldade da tarefa com a capacidade computacional — não se trata de escolher o mais forte, mas sim o mais adequado.
- Conhecendo os modelos antigos e atuais: o topo de linha
gpt-5.5resolve tarefas difíceis, ogpt-5.4-minicuida de tarefas simples com rapidez e economia, e ogpt-5.3-codex-sparké ideal para respostas imediatas;gpt-5.2egpt-5.3-codexestão obsoletos e não devem ser escritos nas configurações. - O esforço de raciocínio é a carta na manga: se achar insatisfatório, aumente um nível; se achar lento, diminua um nível. Geralmente é mais rápido do que trocar de modelo.
- Uma tabela de referência + um hábito: use o padrão "topo de linha +
medium" para a maior parte das tarefas e mude manualmente apenas em tarefas complexas ou em lote. - Quatro formas de alternar: alterar o padrão, especificar na inicialização, alternar na sessão e configurar individualmente no subagente; use conforme a necessidade.
Agora você deve ser capaz de: abrir o painel /model sem ficar confuso, identificar qual modelo e qual esforço usar apenas olhando para a tarefa e saber como fazer a alternância de quatro maneiras diferentes.
No próximo artigo 〔31 Dicas avançadas e aceleração〕, daremos um passo além de "quem enviar e com qual intensidade": discutiremos técnicas avançadas que tornam todo o fluxo de trabalho mais rápido, econômico e com menos retrabalho. Deixo uma pequena reflexão — você já notou que, em muitas situações, o que atrasa o seu desenvolvimento não é a falta de capacidade do modelo, mas sim o contexto desorganizado fornecido por você, que o faz tomar caminhos errados? É exatamente este o problema que abordaremos no próximo artigo.