gpt-6-astra no Codex CLI: guia completo de configuração e reasoning effort

Q: O gpt-6-astra funciona com o Codex CLI 0.151.0?

Sim, desde que a integração use a Responses API ( wire_api = "responses" ). O Codex CLI opera sobre essa rota por padrão.

Q: Qual o valor correto para reasoning effort no Codex CLI?

low , medium , high , xhigh ou max . O modelo rejeita none e minimal com HTTP 400. O mais comum para trabalho de engenharia é xhigh .

Q: Por que meu reasoning_tokens vem 0 mesmo com xhigh configurado?

Na grande maioria dos casos, porque max_output_tokens está muito baixo — esse limite inclui os tokens de raciocínio na Responses API. A segunda causa mais comum é testar com perguntas triviais, que não disparam raciocínio.

Q: O codex exec fica travado em "Reading additional input from stdin"

Redirecione a entrada padrão: codex exec ... < /dev/null . Sem esse redirecionamento, o processo fica esperando entrada indefinidamente.

Q: Onde fica o config.toml do Codex CLI?

Em ~/.codex/config.toml — no Windows, %USERPROFILE%\.codex\config.toml .

Você configurou o gpt-6-astra no Codex CLI, escolheu reasoning_effort = "xhigh" e ainda ficou com uma dúvida: o modelo está mesmo usando esse nível de raciocínio? Este guia responde à pergunta com configuração e resultados de testes.

Executamos os testes na nossa própria infraestrutura e mostramos os números retornados pela API. Assim, você pode comparar o que está configurado no cliente com o que chega à resposta.

Fluxo visual do Codex CLI para a Responses API e o raciocínio do gpt-6-astra

Testes da MandAPI realizados em 7 de novembro de 2026. Resultados podem variar conforme o provedor, o cliente e a configuração.

O que é o gpt-6-astra

O gpt-6-astra (alias atual gpt-6-astra-2026-09-03) é o modelo topo de linha da OpenAI, lançado em setembro de 2026. Estas são as especificações relevantes para a configuração:

Especificação	Valor
Janela de contexto	1.050.000 tokens
Saída máxima	128.000 tokens
Knowledge cutoff	30/04/2026
Endpoints	`v1/responses`, `v1/chat/completions`, `v1/batch`, `v1/realtime`, `v1/assistants`
Function calling	Suportado
Streaming / Structured Outputs	Suportados

Para usar o Codex CLI, o ponto central é o suporte à Responses API (v1/responses), rota da qual o cliente depende.

gpt-6-astra é compatível com Codex CLI 0.151.0?

Sim, desde que a integração use a Responses API. No config.toml, isso significa wire_api = "responses".

O Codex CLI usa a Responses API por padrão. A configuração funciona quando o provedor encaminha essa rota corretamente.

É aqui que surgem os problemas: muitos gateways implementam apenas /v1/chat/completions. Se o provedor converter /v1/responses para essa rota sem avisar, o Codex CLI pode falhar ou apresentar comportamento inesperado, sem uma mensagem de erro clara.

Como configurar o gpt-6-astra no Codex CLI

Passo 1: variável de ambiente com a chave

export MANDAPI_API_KEY="sk-sua-chave-aqui"

Passo 2: editar `~/.codex/config.toml`

model = "gpt-6-astra"
model_provider = "mandapi"
model_reasoning_effort = "xhigh"
approval_policy = "never"

[model_providers.mandapi]
name = "MandAPI"
base_url = "https://api.mandapi.com/v1"
env_key = "MANDAPI_API_KEY"
wire_api = "responses"

Passo 3: verificar se carregou

codex exec --skip-git-repo-check -C . "responda apenas OK" < /dev/null

Neste teste não interativo, mantenha < /dev/null. Sem o redirecionamento, o Codex pode ficar em Reading additional input from stdin..., aguardando entrada. Esse sintoma já foi confundido com indisponibilidade da API.

O cabeçalho da saída mostra o modelo e a política de aprovação carregados. Confira esses campos para saber se o config.toml foi aplicado.

Os 3 erros de configuração mais comuns

Erro 1: `model_reasoning_effort` dentro do bloco do provider

# INCORRETO — o Codex ignora silenciosamente
[model_providers.mandapi]
model_reasoning_effort = "xhigh"

# CORRETO — no nível raiz do arquivo
model_reasoning_effort = "xhigh"

[model_providers.mandapi]
name = "MandAPI"

Coloque essa chave no nível raiz. Dentro de [model_providers.*], ela é descartada sem aviso; você pode acreditar que selecionou xhigh enquanto o modelo usa o valor padrão.

Erro 2: `wire_api` diferente de `responses`

reasoning_effort só tem efeito sobre a Responses API. Se wire_api = "chat", o parâmetro não chega ao modelo.

Erro 3: não reiniciar o Codex

O Codex carrega o config.toml na inicialização do processo. Alterou o arquivo, reinicie a aplicação — senão a mudança simplesmente não existe.

`reasoning_effort = "xhigh"` funciona de verdade?

Essa é uma das perguntas que mais recebemos. A resposta curta: funciona quando o provedor encaminha o parâmetro ao modelo.

Dois cenários podem parecer iguais no painel:

O gateway aceita o campo e mostra xhigh no painel de logs
O gateway repassa o campo ao modelo e o modelo realmente pensa mais

Um gateway pode registrar xhigh na interface sem encaminhá-lo ao upstream. Por isso, o log sozinho não basta para avaliar o comportamento do modelo.

O teste que executamos

Enviamos ao gpt-6-astra um problema que exige raciocínio de múltiplas etapas (identificar 1 moeda falsa entre 12, usando uma balança apenas 3 vezes, e ainda determinar se ela é mais pesada ou mais leve), com reasoning.effort = "xhigh" e max_output_tokens = 2000.

Resultado:

reasoning_tokens  = 1.034
output_tokens     = 1.958
itens retornados  = reasoning, reasoning, message
eco do parâmetro  = {"effort":"xhigh","mode":"standard"}
tempo de resposta = 53 s

Como ler esse resultado:

reasoning_tokens = 1.034 — a cadeia de raciocínio realmente foi executada. O modelo gastou mais de mil tokens pensando antes de responder.
output contém dois itens type=reasoning — não é apenas um contador; os blocos de raciocínio voltam na resposta.
O eco do parâmetro retorna effort: xhigh — o valor chegou íntegro na camada que executa o modelo.

Neste teste, o contador de raciocínio, os itens retornados e o eco do parâmetro formam evidências complementares de que xhigh foi aplicado.

Valores aceitos

low | medium | high | xhigh | max

O modelo não aceita none (retorna HTTP 400). minimal também é rejeitado. Se você precisa de qualidade máxima, use max — mais lento e mais caro que xhigh.

Por que `reasoning_tokens` volta 0 (e como corrigir)

Se o provedor encaminha o parâmetro, mas reasoning_tokens ainda volta 0, examine primeiro duas causas comuns do lado do cliente.

Causa 1: `max_output_tokens` muito baixo

Este erro é comum e fácil de passar despercebido.

Na Responses API, max_output_tokens inclui os tokens de raciocínio. Ou seja: se você define max_output_tokens = 32 ou 128, o modelo não tem espaço para pensar. Ele é obrigado a responder de imediato, e reasoning_tokens virá 0 — mesmo com effort = "xhigh".

Regra prática: reserve espaço para o raciocínio. Para testar xhigh, use pelo menos 2000 tokens de saída; tarefas complexas podem exigir um limite maior.

Causa 2: a pergunta não exige raciocínio

Perguntas triviais não disparam cadeia de raciocínio. Isso é comportamento esperado do modelo, não falha do serviço.

Um teste como "responda apenas OK" serve para conferir a conexão, mas não para avaliar o uso de reasoning_effort = "xhigh".

Como confirmar que o raciocínio está ativo

Adicione ao config.toml:

model_reasoning_summary = "detailed"

Envie então uma pergunta que exija múltiplas etapas. Se aparecer um bloco de reasoning summary na resposta, o raciocínio está habilitado e funcionando.

Custo: reasoning tokens são cobrados como saída

Esse detalhe afeta diretamente o custo de cada chamada.

Na Responses API, os reasoning_tokens entram na conta de tokens de saída. No teste que fizemos, a resposta final tinha cerca de 2.500 caracteres de texto, mas o output_tokens marcou 1.958 — porque 1.034 desses tokens foram raciocínio interno, não texto entregue.

Na prática, isso significa que subir de medium para xhigh aumenta o custo por requisição, mesmo que o tamanho da resposta final seja idêntico.

Três consequências práticas:

xhigh não é gratuito. Se você está rodando um agente que dispara centenas de chamadas por dia, a diferença aparece na fatura.
Não existe "reasoning de graça" em gateway nenhum. Se um provedor cobra os tokens de raciocínio como entrada, ou não os cobra de jeito nenhum, vale perguntar como isso se sustenta.
Cache ajuda, e muito. Um agente como o Codex CLI reenvia o mesmo prompt de sistema a cada turno. No nosso teste, 3.844 tokens vieram de cache — o que reduz bastante o custo efetivo de entrada em sessões longas.

Como ponto de partida, reserve xhigh para arquitetura, refatorações complexas e depuração difícil. Para tarefas mecânicas, como renomear variáveis ou gerar código repetitivo, teste medium ou low e compare qualidade e custo.

Como testar sem escrever código (só com curl)

Se você quer validar o provedor antes de configurar o Codex, você pode executar os três testes abaixo com curl.

Teste 1 — a rota /v1/responses existe?

curl -s https://api.mandapi.com/v1/responses \
  -H "Authorization: Bearer $SUA_CHAVE" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-6-astra","input":"oi","max_output_tokens":16}' \
  -o resposta.json -w "%{http_code}\n"

200 significa que a rota existe e responde. 404 significa que o provedor só tem /chat/completions — o Codex CLI não vai funcionar.

Teste 2 — o reasoning realmente chega ao modelo?

Use uma pergunta que exija raciocínio e dê orçamento de saída:

curl -s https://api.mandapi.com/v1/responses \
  -H "Authorization: Bearer $SUA_CHAVE" \
  -H "Content-Type: application/json" \
  -d '{
    "model":"gpt-6-astra",
    "input":"Explique passo a passo como determinar qual de 12 moedas é falsa usando uma balança apenas 3 vezes, sem saber se ela é mais pesada ou mais leve.",
    "max_output_tokens":2000,
    "reasoning":{"effort":"xhigh"}
  }' -o resposta.json

Abra o resposta.json e procure usage.output_tokens_details.reasoning_tokens.

reasoning_tokens > 0 → o parâmetro foi repassado
reasoning_tokens = 0 com uma pergunta dessas → investigue o limite de saída, a pergunta e o repasse do parâmetro

E confira também o campo reasoning no nível raiz da resposta. Um provedor que repassa corretamente devolve algo como {"effort":"xhigh","mode":"standard"}, confirmando que o valor chegou na camada que executa o modelo.

Teste 3 — tools é repassado?

curl -s https://api.mandapi.com/v1/responses \
  -H "Authorization: Bearer $SUA_CHAVE" \
  -H "Content-Type: application/json" \
  -d '{
    "model":"gpt-6-astra",
    "input":"Qual o clima em São Paulo? Use a ferramenta.",
    "max_output_tokens":200,
    "tools":[{"type":"function","name":"get_weather",
              "description":"Retorna o clima de uma cidade",
              "parameters":{"type":"object",
                            "properties":{"city":{"type":"string"}},
                            "required":["city"]}}]
  }' -o resposta.json

Procure por um item com "type": "function_call" no array output. Se em vez disso vier só texto, o campo tools foi descartado — e o Codex CLI vai conseguir conversar, mas não vai conseguir editar arquivo nenhum.

Tool calling e function calling

O gpt-6-astra suporta function calling nativo, e as ferramentas da Responses API estão disponíveis:

apply_patch · hosted shell · MCP · web search · file search · code interpreter · computer use

No nosso teste, a chamada retornou corretamente uma function_call estruturada, com nome da função e argumentos em JSON — sem degradar para resposta em texto puro.

Isso importa porque o Codex CLI depende de apply_patch e exec_command para trabalhar. Se o provedor engolir o campo tools, o agente vira um chat comum: ele conversa bem, mas não edita nenhum arquivo.

Checklist antes de contratar qualquer provedor

Se você está avaliando usar gpt-6-astra com Codex CLI através de um gateway ou provedor de API, verifique estes três pontos — nesta ordem:

[ ] A rota é /v1/responses nativa? Peça a evidência. Se o provedor só souber responder sobre /v1/chat/completions, o Codex CLI não vai funcionar direito.
[ ] reasoning.effort chega ao modelo? A prova é reasoning_tokens > 0 em uma tarefa que exija raciocínio. Log mostrando "xhigh" não é prova.
[ ] tools é repassado? Teste enviando uma definição de ferramenta simples e verifique se volta um function_call.

Peça respostas acompanhadas dos dados retornados pela API; uma declaração genérica de compatibilidade não substitui esses testes.

Perguntas frequentes

O gpt-6-astra funciona com o Codex CLI 0.151.0?

Sim, desde que a integração use a Responses API (wire_api = "responses"). O Codex CLI opera sobre essa rota por padrão.

Qual o valor correto para reasoning effort no Codex CLI?

low, medium, high, xhigh ou max. O modelo rejeita none e minimal com HTTP 400. O mais comum para trabalho de engenharia é xhigh.

Por que meu reasoning_tokens vem 0 mesmo com xhigh configurado?

Na grande maioria dos casos, porque max_output_tokens está muito baixo — esse limite inclui os tokens de raciocínio na Responses API. A segunda causa mais comum é testar com perguntas triviais, que não disparam raciocínio.

Preciso reiniciar o Codex depois de mudar o config.toml?

Sim. A configuração é carregada na inicialização do processo.

O `codex exec` fica travado em "Reading additional input from stdin"

Redirecione a entrada padrão: codex exec ... < /dev/null. Sem esse redirecionamento, o processo fica esperando entrada indefinidamente.

Onde fica o config.toml do Codex CLI?

Em ~/.codex/config.toml — no Windows, %USERPROFILE%\.codex\config.toml.

Conclusão

O gpt-6-astra pode ser usado no Codex CLI: suporta a Responses API, aceita os cinco níveis de reasoning_effort listados acima, faz function calling nativo e tem contexto de mais de um milhão de tokens.

O ponto decisivo é o caminho entre o cliente e o modelo. Um gateway pode aceitar parâmetros sem encaminhá-los. Confira os campos da resposta, além do log, para entender o que aconteceu em cada chamada.

Para conferir sua configuração, crie uma conta gratuita e execute os três testes acima com a sua chave. Se encontrar um resultado inesperado, abra um chamado para analisarmos a chamada com você.

Veja também: modelos disponíveis, preços atuais e guia de API compatível.