Selected model is at capacity: soluções no Codex e limites de uso

“Selected model is at capacity” é um erro que o Codex classifica como sobrecarga do servidor. Verificamos a correspondência da mensagem com o código público da OpenAI e encontramos a mesma mensagem completa com serverOverloaded no histórico de execução deste computador. Trate esse erro separadamente do esgotamento da franquia de uso ou de uma falha no PC. Porém, nem as informações públicas nem os registros do computador permitiram determinar o que causou a sobrecarga.

Selected model is at capacity. Please try a different model.

O que está acontecendo? O que mostram os registros oficiais

A mensagem informa que o modelo selecionado atingiu sua capacidade e pede que você tente outro modelo. Não há fundamento para interpretar “capacity” como a memória ou o espaço em disco do seu PC. A página oficial de status da OpenAI registra incidentes do serviço que exibiram essa mensagem.

Esses dois registros demonstram que a mesma mensagem pode aparecer durante incidentes do serviço e que trocar de modelo nem sempre ajuda. A quantidade de incidentes publicada não permite determinar a frequência do erro nem demonstra que o seu erro teve a mesma causa de um incidente anterior. As datas seguem as páginas oficiais; não convertemos seus horários para o horário padrão do Japão.

Nenhum dos registros publica uma causa raiz, como uma escassez específica de hardware ou um problema na troca de contas. Afirmações como “faltam GPUs” ou “a autenticação do Pro está com defeito” vão além das informações verificadas. Consultamos as fontes oficiais originais em 1º de outubro de 2026 e distinguimos os fatos estabelecidos das nossas recomendações.

Diferenças em relação a limites de uso, 401 e thread not found

Todos esses problemas podem parecer uma interrupção do trabalho, mas exigem verificações diferentes. Para um erro de capacidade, comece verificando tanto a mensagem completa na tela quanto seu status de uso. Vários tipos de problema podem ocorrer na mesma conta.

Consulte a franquia restante na tela específica de uso

O guia de preços e uso da OpenAI orienta os usuários a consultar o painel de uso para verificar os limites atuais. Durante uma sessão do Codex CLI, você também pode usar /status. Consultar logo após o erro facilita compará-lo com a franquia disponível naquele momento.

O guia oficial também explica que trabalhos já em andamento podem continuar sob restrições de uso justo mesmo que um limite seja atingido durante o processamento. Portanto, um erro seguido de um relatório de conclusão não permite, por si só, determinar se um limite foi atingido. Por outro lado, um incidente do serviço pode ocorrer mesmo com bastante franquia restante. Veja nossa comparação dos planos ChatGPT Pro para conhecer as franquias incluídas e os créditos adicionais.

Para um erro 401, primeiro verifique como você fez login

O guia de autenticação do Codex distingue o login com ChatGPT do login com uma chave de API. No aplicativo para desktop, o menu do perfil mostra a conta ativa ou o status da chave de API. Na CLI, use codex login status.

Mesmo que “Incorrect API key” apareça enquanto você está conectado com ChatGPT, a tela sozinha não demonstra que você configurou uma chave incorreta. Identificar quais credenciais foram rejeitadas exige investigação adicional. Um erro de capacidade não é motivo para sair imediatamente da conta ou apagar arquivos de autenticação. Usar uma chave de API gera cobranças normais de API, separadas da assinatura do ChatGPT.

Se a mensagem for thread not found, consulte nossa investigação e guia de solução do erro “thread not found” do Codex. Erros anteriores de autenticação ou de chat no mesmo PC não estabelecem uma relação causal com o erro de capacidade atual.

Diferencie erros HTTP 503 da API da mensagem do aplicativo

O guia de códigos de erro da API da OpenAI explica HTTP 503, service_unavailable_error e server_is_overloaded como indicadores de sobrecarga temporária do modelo. HTTP 429 inclui erros de frequência de solicitações ou limites de uso, enquanto HTTP 401 se refere à autenticação.

Passos para retomar o trabalho

As recomendações a seguir se baseiam em registros oficiais de incidentes, guias de uso e documentação geral de solução de problemas. Elas não foram publicadas como uma solução garantida especificamente para este erro.

1. Salve sua solicitação e o último trabalho concluído

Se o texto da solicitação não enviada continuar visível, copie-o e preserve o último relatório de conclusão ou o estado dos arquivos modificados. Antes de fechar ou substituir o chat, registre o que você pediu e quanto foi concluído. Isso facilita a retomada.

A mensagem de erro sozinha não prova que nenhum arquivo foi editado ou comando executado. Em desenvolvimento com Git, examine as diferenças ou execute git status antes de pedir a mesma alteração novamente. Para trabalhos que envolvam publicação, envio de mensagens ou compras, não repita a instrução sem verificar primeiro o resultado.

2. Aguarde um pouco e consulte a página oficial de status

Abra o OpenAI Status e verifique incidentes que afetem o Codex ou a seleção de modelos. Compare o horário do erro com o período do incidente, em vez de olhar apenas seu status atual. Um incidente passado com o mesmo nome não significa que ele continue ocorrendo.

Para sobrecarga da API, a orientação oficial é aguardar pelo menos o tempo especificado por Retry-After, quando presente, ou aumentar o intervalo entre tentativas quando ausente. Não pudemos verificar um número fixo de segundos que os usuários do aplicativo precisam esperar quando nenhum prazo é exibido. Recomendamos aguardar um pouco antes de tentar novamente, em vez de enviar solicitações repetidamente em rápida sucessão. Durante um incidente listado, consulte as atualizações oficiais de recuperação.

A página de status apresenta informações agregadas. Ela pode não refletir totalmente a situação de uma conta ou modelo específico. A ausência de um incidente listado não demonstra que seu PC esteja com defeito.

3. Verifique o uso e considere outro modelo se o trabalho for urgente

Confira sua franquia restante e o horário de renovação. Se um limite de uso for informado explicitamente, siga esse aviso ao decidir o que fazer. Não trate a compra de créditos adicionais ou uma renovação paga da franquia como forma de recuperação quando a única mensagem for um erro de capacidade. Restaurar sua própria franquia e o modelo poder aceitar solicitações são questões distintas.

O guia oficial de seleção de modelos explica que os controles de modelo e esforço de raciocínio do aplicativo para desktop ficam abaixo do campo de entrada. Na CLI interativa, use /model. Os modelos disponíveis variam conforme a conta, o cliente e outros fatores; não presuma que um modelo ausente da sua interface esteja disponível.

Trocar de modelo pode alterar o tipo de resposta e o consumo da franquia. Não há fundamento para sempre escolher o modelo de nível mais alto para evitar erros de capacidade. Ao transferir trabalhos complexos de implementação ou projeto, revise a nova saída por meio de diferenças e testes. Nossa comparação entre gerações do GPT Sol e guia de seleção também oferece contexto.

4. Investigue a resposta do aplicativo separadamente se ele estiver travado

Diferencie um erro de capacidade de um campo de entrada, terminal ou interface que não responde. Para chats aparentemente travados, a orientação oficial de solução de problemas recomenda verificar aprovações pendentes, testar o terminal com um comando básico e tentar uma solicitação pequena em um novo chat.

Se o terminal continuar travado, a orientação é aguardar os chats ativos terminarem antes de reiniciar o aplicativo. Isso trata de um estado geral de falta de resposta; não afirma que reiniciar resolva a falta de capacidade do servidor. Primeiro verifique o estado dos outros chats que ainda estejam em execução.

Se retomar em um novo chat, informe brevemente o objetivo, a pasta de trabalho, as alterações concluídas e as tarefas pendentes. Não envie apenas “continue” presumindo que toda a conversa anterior esteja disponível. Um novo chat usa o mesmo serviço e, portanto, não garante evitar o erro de capacidade.

O que registrar se acontecer novamente

Se o erro se repetir, preserve evidências que apoiem uma investigação futura. Registrá-las antes de alterar repetidamente as configurações esclarece as condições da falha.

Dependendo dos registros disponíveis, talvez não seja possível confirmar que o modelo selecionado nas configurações foi realmente usado na solicitação que falhou. Se você registrou apenas a seleção visível, descreva somente essa evidência. Da mesma forma, a recuperação imediatamente após trocar de modelo não prova que a troca resolveu o problema: o serviço pode ter se recuperado ao mesmo tempo.

O guia oficial explica como enviar feedback digitando / no campo de mensagens. Ao enviar de um chat existente, você pode escolher se deseja compartilhar a conversa. Remova chaves de API, endereços de e-mail, conversas privadas e informações internas da empresa dos logs ou capturas enviados. Não é necessário publicar os valores das chaves nem os próprios arquivos de autenticação.

Um relatório com data, modelo, mensagem exata e franquia restante exibida é mais útil do que apenas dizer “vive falhando”. Um código HTTP ou ID de solicitação, se obtido, pode ajudar o suporte a investigar, mas não preencha lacunas com suposições.

O que encontramos neste computador e o que continua desconhecido

Após um usuário relatar ocorrências repetidas com capturas de tela, a AI Arte pediu que o Codex neste computador realizasse uma investigação somente de leitura do uso e dos logs locais em 1º de outubro de 2026. A versão do pacote do aplicativo para Windows era 26.928.3736.0. Não verificamos se a mesma versão estava instalada quando os erros ocorreram.

A busca inicial não encontrou o erro em 32.737 registros do banco de dados comum de logs, 15 arquivos de logs do desktop ou 143 arquivos atualizados de registros de sessão. Depois que um leitor questionou os resultados, verificamos outros locais de armazenamento e encontramos registros de falha em um banco de dados separado de histórico de execução. O escopo da busca inicial foi insuficiente.

Na investigação posterior, 35 dos 6.781 turnos do histórico de execução eram falhas. Em todo o período registrado, 13 continham a mesma mensagem completa e codexErrorInfo: serverOverloaded. Desses, 12 ocorreram em cinco chats entre 30 de setembro de 2026, às 22:10:01, e 1º de outubro, às 00:24:55 (JST). O chat em que o usuário anexou as capturas do erro também continha quatro falhas em 30 de setembro, às 22:15:06, 22:57:58, 23:12:31 e 23:24:38, com mensagens e classificações correspondentes. Esses horários são os registros de conclusão dos turnos que falharam, não os horários das capturas. Eles descrevem os registros deste computador, não uma taxa de erros para todos os usuários.

A Codex CLI incluída no aplicativo era a versão 0.159.2. Nas definições de erros da tag pública correspondente, a mensagem completa corresponde a ServerOverloaded, classificado separadamente do esgotamento da franquia de uso. O código de processamento do fluxo converte server_is_overloaded em um erro de sobrecarga, e o código de conversão para exibição o conecta à mensagem completa no início deste artigo. Há também um caminho que converte respostas HTTP 503 com o mesmo código de erro, mas erros também podem chegar dentro de um fluxo. Assim, a mensagem exibida não demonstra que a resposta foi HTTP 503.

O que estabelecemos é que as falhas foram classificadas e armazenadas como sobrecarga do servidor. Os registros não mostram se houve uma escassez real de GPUs, problemas de roteamento de solicitações ou de controle de capacidade. Os detalhes adicionais das quatro falhas estavam vazios, e nenhum código HTTP foi registrado. Na investigação inicial, restavam 31% da franquia semanal e o uso normal era permitido. Essa não era a franquia no momento dos erros, e o modelo realmente usado pelas solicitações que falharam também não foi estabelecido.

Quanto aos erros de autenticação, o relatório oficial de causa raiz de outro incidente ocorrido em 25 de setembro explica que a detecção equivocada e a invalidação de credenciais internas do serviço causaram erros 401 e 502 no Codex conectado via ChatGPT. Isso não estabelece a causa dos erros de sobrecarga examinados aqui. Não confunda um incidente interno de autenticação explicado oficialmente com os atuais erros de sobrecarga.

Esta investigação não alterou modelos ou assinaturas, não usou renovações pagas da franquia nem apagou credenciais. Também não enviamos deliberadamente solicitações rápidas e repetidas para reproduzir o problema, portanto não temos uma comparação experimental de quais ações restauram o serviço. Distinguimos exemplos de incidentes verificados oficialmente das observações neste único computador.

Resumo: identifique o erro antes de agir

Se aparecer “Selected model is at capacity”, salve sua solicitação, aguarde um pouco e verifique incidentes e consumo. Para trabalho urgente, você pode considerar outro modelo disponível, mas alguns incidentes afetam vários modelos. O erro de capacidade sozinho não justifica gastar mais, comprar uma renovação paga da franquia ou apagar credenciais.

Verifique a autenticação para um 401, o estado do chat para thread not found e o status de uso para um aviso de limite. Registrar horário, mensagem completa, modelo e franquia restante quando o erro se repetir ajuda mais a próxima investigação do que alterar configurações sem conhecer a causa.

Perguntas frequentes

Isso pode acontecer com uma assinatura Pro?

O usuário deste artigo relatou a mesma mensagem com uma assinatura Pro. Porém, um relato não permite estabelecer taxas de incidentes por plano. Os registros oficiais não afirmam que o Pro esteja isento. Verifique a franquia restante da assinatura separadamente da possibilidade de o modelo aceitar trabalho naquele momento.

Créditos adicionais ou uma renovação paga da franquia resolvem?

Não encontramos evidências oficiais de que essas ações resolvam este erro de capacidade. Créditos adicionais e mecanismos semelhantes se referem à sua própria franquia. Primeiro verifique se realmente atingiu um limite e não confunda a restauração da franquia com a recuperação de um erro de capacidade.

Por que continua acontecendo após trocar de modelo?

Os registros oficiais descrevem a mesma mensagem afetando vários modelos. Ela aparecer em outro modelo não prova, por si só, uma falha no PC ou na conta. Consulte os incidentes e a franquia restante e registre os resultados das tentativas. A documentação pública não estabelece um modelo que garanta evitar o erro.

Devo reiniciar o aplicativo ou abrir um novo chat?

Não pudemos estabelecer que nenhuma das duas ações seja necessária. Elas podem ajudar a investigar um aplicativo ou terminal sem resposta, mas não garantem resolver um problema de capacidade do serviço. Verifique os outros trabalhos em andamento e preserve sua solicitação, alterações e tarefas pendentes antes de decidir.