Ultra do GPT: 3 modelos e 2 níveis novos

Uma única execução do Ultra do GPT consumiu um limite de cinco horas em cerca de 20 minutos. O Ultra não é um nível de raciocínio: é um skill que obriga o modelo a gerar subagentes com raciocínio máximo repetidas vezes. Em 2025, a Anthropic mexeu nesse mecanismo no Claude Code, e em 2026 o debate chegou ao consumo de tokens. Abaixo, você vê o que é nível de esforço e o que é instrução de sistema, além de quando vale monitorar o gasto.

O que é o Ultra do GPT e por que ele confunde

O Ultra do GPT é um skill que altera o system prompt para forçar o modelo a criar mais subagentes, e não um nível de raciocínio. Ele aparece no seletor de esforço como se fosse o topo da escala, mas o esforço real que ele usa é o máximo disponível, o que muda completamente o consumo de tokens. Essa confusão nasce do próprio rótulo: o usuário acha que está escolhendo um nível de esforço, quando na prática está ativando uma instrução de sistema.

Vale separar duas coisas que o seletor mistura. O nível de raciocínio define quanto o modelo pensa em cada resposta. O skill define o que ele deve fazer, como disparar subagentes. O Ultra pertence ao segundo grupo, mas é apresentado como se pertencesse ao primeiro. Quando você escolhe o Ultra, o esforço deixa de ser o foco e passa a importar a instrução que o modelo recebe para decompor tarefas.

A confusão tem consequência prática. Quem acredita estar apenas subindo o raciocínio um degrau tende a manter o Ultra ligado para tarefas que não pedem subagentes. O resultado é consumo alto sem ganho proporcional, porque o modelo gasta tokens organizando trabalho paralelo que talvez não fosse necessário.

Níveis de raciocínio x skills: a diferença que muda o consumo

Níveis de raciocínio controlam esforço por resposta; skills injetam instruções no system prompt. Essa distinção explica por que o Ultra do GPT não deveria ocupar o mesmo espaço de low, medium, high, extra high e max. Quando o Ultra é acionado, a mudança não é de intensidade de pensamento, mas de comportamento esperado do agente.

Skills funcionam como um arquivo cujo conteúdo é anexado ao system prompt antes da próxima mensagem. No caso do Ultra, esse conteúdo orienta o modelo a usar muito mais subagentes. Em ferramentas baseadas em CLI, isso reaproveita a mesma lógica de comandos que injetam skills. O efeito é um comportamento mais agressivo de decomposição de tarefas, não um esforço maior por token.

A leitura correta do seletor, então, é esta: se o objetivo é ganhar profundidade de raciocínio em uma tarefa isolada, um nível alto de esforço basta. Se o objetivo é orquestrar muitos fluxos paralelos, aí sim o skill faz sentido. Misturar os dois é o que produziu a maior parte da frustração com o Ultra.

Como a Anthropic estruturou o Ultra Code no Claude Code

No Claude Code, ferramenta de codificação agêntica da Anthropic que roda no terminal, o Ultra Code também é um skill, mas assume explicitamente o esforço extra high, não o máximo. Essa escolha reduz o consumo e mantém o comportamento previsível. O comando de esforço mostra as opções low, medium, high, extra high, max e ultra code, e o Ultra Code aponta para extra high.

O detalhe importa porque, quando você aciona o Ultra Code, o nível de raciocínio cai em relação ao max. Ou seja, é possível ter mais subagentes com menos esforço individual por agente. A implementação usa workflows, que são arquivos JavaScript com fases definidas, cada uma com schema de saída e prompt próprio.

A crítica que se aplica aqui é de ergonomia: é fácil deixar o Ultra Code ligado sem perceber. Ainda assim, a decisão de apontar para extra high em vez de max é o tipo de escolha que evita o pior cenário de consumo.

Como o Codex implementa subagentes em V1 e V2

O Codex tem duas implementações de subagentes, chamadas internamente de V1 e V2. A V1 é a concluída e usada por padrão: o agente raiz dispara subagentes para tarefas específicas e espera o resultado. A V2 é uma reformulação em andamento, com troca de mensagens entre agentes, nomes baseados em caminho e a possibilidade de um subagente criar outros.

Na V2, cada agente recebe um nome de tarefa, e a hierarquia vira um caminho, como uma pasta que contém subpastas. Por padrão, todo o histórico da conversa principal é compartilhado com os subagentes, o que aumenta o contexto de cada um e encarece a execução. Também há um sistema de caixas de mensagem, em que agentes trocam notas e tarefas de acompanhamento.

O problema é que a V2 ainda tem arestas. Se você ativá-la manualmente com a V1 configurada, aparecem erros, porque as duas não convivem bem. Em versões recentes, o próprio cache de modelos define qual versão cada modelo usa, o que empurra os modelos novos para a V2 sem que você escolha.

Por que o Ultra queima limites de uso tão rápido

O Ultra queima limites porque o agente pai e todos os subagentes rodam em raciocínio máximo. O consumo cresce de forma quase multiplicativa, já que cada subagente carrega contexto próprio e repete o ciclo. Uma única execução pode esvaziar um limite de cinco horas em cerca de 20 minutos, sobretudo em modo rápido.

No relato do vídeo, o limite de cinco horas foi atingido duas vezes em menos de uma hora, com um reset manual consumido no processo. O agravante é que o histórico completo é enviado aos subagentes por padrão na V2, ampliando o custo de cada chamada. Não existe limite de profundidade de aninhamento, só um teto de execuções simultâneas, quatro por padrão.

A consequência é um risco maior do que o normal: se o limite de cinco horas for removido temporariamente, como já aconteceu, um consumo acelerado pode comprometer a cota semanal inteira, e não apenas uma fração dela.

Workflows: quando o trabalho tem fim garantido

Workflows definem fases com esquemas de saída e encerram quando a última fase termina, diferente do Ultra, que depende dos agentes decidirem parar. Em vez de o modelo disparar subagentes por chamadas soltas, o fluxo é escrito como código, com fases nomeadas, prompts e validações. Isso cria um limite natural para a execução.

Um fluxo típico pode ter fases como pesquisar, verificar, sintetizar, criticar e finalizar. Cada fase recebe um schema, e a passagem para a próxima depende do resultado anterior. Se um campo indicar que a pesquisa precisa continuar, o código decide o próximo passo em vez de deixar a decisão inteiramente para o modelo.

Isso não elimina picos de uso: uma única fase pode gerar dezenas de subagentes quando encontra muitos itens para tratar. A diferença é que o fluxo sempre chega ao fim, enquanto a abordagem baseada apenas em chamadas de ferramenta pode continuar indefinidamente.

Comparação: Ultra do GPT x Ultra Code

A tabela abaixo resume as diferenças observáveis entre as duas abordagens, com base no que foi descrito na análise do vídeo.

Critério	Ultra do GPT	Ultra Code (Claude Code)
Natureza	Skill que altera o system prompt	Skill que altera o system prompt
Esforço associado	Raciocínio máximo	Extra high
Mecanismo de orquestração	Chamadas de ferramenta para subagentes	Workflows com fases e schemas
Fim da execução	Depende da decisão dos agentes	Depende do fim das fases
Risco de consumo extremo	Alto	Menor, mas ainda exige atenção

As duas abordagens compartilham a mesma ideia de fundo: forçar o modelo a usar mais subagentes. A diferença está no quanto o fluxo é programado e no esforço que cada agente recebe. Quanto mais o comportamento é definido em código, menor a chance de uma execução sem fim.

O que fazer enquanto a implementação amadurece

A recomendação prática é simples: não use o Ultra enquanto ele estiver apresentado como nível de raciocínio. Mantenha os padrões e acompanhe as mudanças, porque as equipes por trás dessas ferramentas costumam responder rápido a feedback. Em poucas horas, parte das reclamações descritas no vídeo já havia sido endereçada.

Se você precisa de trabalho paralelo com controle, prefira fluxos programáticos, nos quais fases e schemas definem quando o processo termina. Se precisa apenas de respostas mais profundas, um nível alto de esforço resolve sem multiplicar subagentes.

Vale ainda separar expectativa de capacidade. Os modelos novos não são ineficientes por natureza; o que destrói limites é uma configuração que multiplica contexto e raciocínio máximo em cada subagente.

Perguntas frequentes sobre o Ultra do GPT

• Ultra do GPT é um nível de raciocínio? Não. Ele é um skill que altera o system prompt para induzir o modelo a disparar mais subagentes, todos em raciocínio máximo. O seletor o apresenta ao lado de low, medium, high, extra high e max, o que gera a confusão.

• Por que uma execução pode consumir o limite de cinco horas tão rápido? Porque o agente raiz e todos os subagentes rodam em raciocínio máximo, e cada subagente carrega contexto próprio. No relato analisado, o limite foi atingido em cerca de 20 minutos em modo rápido.

• O que muda no Claude Code com o Ultra Code? Ele também é um skill, mas aponta para extra high em vez de max. O trabalho paralelo é organizado por workflows, com fases, schemas e prompts definidos em código.

• O que são workflows nesse contexto? São arquivos JavaScript que definem fases, cada uma com schema de saída e prompt próprio. Eles permitem decidir em código qual fase roda depois, com base no resultado anterior.

• Qual a diferença entre V1 e V2 de subagentes no Codex? A V1 é a implementação concluída e padrão, com subagentes que executam tarefas e devolvem resultado. A V2 adiciona troca de mensagens, nomes por caminho e aninhamento, mas ainda é um trabalho em andamento.

• Por que a V2 compartilha o histórico todo com os subagentes? O compartilhamento padrão amplia o contexto de cada subagente e encarece a execução. É possível ajustar para nenhum histórico ou para um número limitado de turnos.

• Existe limite de profundidade de aninhamento no Ultra? Não há limite de profundidade, apenas um teto de execuções simultâneas, quatro por padrão. Isso torna possível uma cadeia longa de subagentes disparando outros subagentes.

• Quem começou essa abordagem de esconder o skill como nível de esforço? Segundo a análise, a Anthropic começou esse padrão com o Ultra Code, e a OpenAI copiou a interface, mas não a implementação baseada em workflows.

• O que fazer para não perder a cota semanal? Não use o Ultra enquanto ele estiver no seletor de esforço. Prefira fluxos com fases definidas e evite níveis máximos de raciocínio em todos os subagentes.

• A implementação atual tende a melhorar? O histórico recente mostra ajustes rápidos após feedback, como esconder o Ultra do seletor no aplicativo e alterar o roteamento de modelos. Vale acompanhar as notas de versão antes de mudar seu fluxo.

Onde aprender a montar fluxos com subagentes

Entender a diferença entre esforço e skill é o primeiro passo para controlar custo e qualidade em agentes de código. Quem quer ir além encontra material em português no Crazystack Typescript, comunidade voltada a desenvolvimento com TypeScript, e no conteúdo do canal Gustavo Dev Doido. Para quem prefere formação estruturada, o Bootcamp do Dev Doido cobre esse tipo de decisão de arquitetura.

A parte prática importa mais do que a teoria: montar um workflow simples, com duas ou três fases, já mostra como o encerramento do fluxo muda o consumo. A partir daí, dá para ajustar quantos subagentes cada fase dispara e qual esforço cada um recebe.

Transforme vídeos técnicos em artigos com o Skala Blog

Explicações como a diferença entre esforço e skill quase sempre nascem em vídeo, onde é fácil demonstrar o seletor, o comando de esforço e o gasto de tokens em tempo real. O problema é que esse conhecimento fica preso na gravação e some do alcance de quem pesquisa no texto.

Se você tem aulas, entrevistas ou análises técnicas gravadas, o Skala Blog transforma o vídeo em artigo: você cola a URL, o conteúdo é transcrito e vira um texto estruturado para publicar. Para quem acumulou horas de gravação, é uma forma de reaproveitar o que já foi explicado e alcançar quem procura respostas escritas.

Source video