Como executar agentes GPT-6.1 Sol no Sharkly

A OpenAI lançou o GPT-6.1 Sol no DevDay em 29 de setembro pelo mesmo preço de tabela do GPT-6 Sol: US$ 2 por milhão de tokens de entrada e US$ 10 por milhão de saída, com a entrada em cache reduzida pela metade para US$ 0,10. O detalhe mais relevante para equipes que operam múltiplos agentes Codex é mais discreto. A tela inicial na documentação da CLI do Codex agora exibe gpt-6.1-sol medium. Em qualquer Computer que não fixe uma versão de modelo, seus Agents mudarão de modelo sempre que alguém atualizar o Codex nessa máquina — e não quando a equipe decidir que deveriam.

O Sharkly não exibirá essa alteração. O Agent segue o modelo padrão do Runtime e não mostra o nome do modelo; portanto, a partir desta semana, dois Agents com instruções idênticas podem rodar modelos diferentes em dois Computers, enquanto suas Tasks continuam com a mesma aparência no painel. Saber qual agente está em qual modelo e de onde veio cada resultado passa a ser uma questão respondida de memória. Este guia aborda apenas o que mudou desde o nosso guia do GPT-6 Sol: de onde vem o novo padrão, quando fixá-lo, as duas configurações que mudaram de lugar e como uma Crew deve rotear o trabalho agora que a categoria intermediária está mais próxima do topo.

TL;DR

O GPT-6.1 Sol chega ao Sharkly por meio do Codex Runtime em um Computer, e nada no Sharkly muda quando isso acontece. Verifique qual build do Codex cada Computer está executando e se o seu ~/.codex/config.toml fixa um modelo. Computers sem modelo fixado seguem o padrão da CLI, que a documentação agora indica como gpt-6.1-sol com esforço medium. Computers configurados a partir do nosso guia anterior permanecem no gpt-6-sol até que alguém edite uma linha. Substitua qualquer esforço none por low, espere que o preço reduzido pela metade do cache apareça em Computers com chave de API (e não em logins vinculados a planos) e trate a tabela de roteamento abaixo como uma regra a ser testada em suas próprias Tasks, não como um veredito definitivo.

O que mudou no Codex Runtime

A documentação de Agents explica por que este artigo é sobre Computers e não sobre Agents: “O Agent segue o modelo padrão do Runtime. Ele não garante nem exibe o nome de um modelo específico. Altere os modelos na configuração de ferramentas do Runtime ou do Computer, não no Agent.” O upgrade é um evento de Runtime. Eis a diferença perceptível para uma Crew:

A CLI atualizada do Codex também adicionou suporte a voz, visualização /agents, edição de prompts, retomada de sessões e worktrees em todos os planos. Vale a pena utilizá-los sempre que você operar o Codex manualmente pelo terminal. No entanto, quando o trabalho passa a ser da equipe, a Task se torna o registro compartilhado. No modo Temporary, o Sharkly fornece a cada Task seu próprio diretório e, em trabalhos com repositórios, pode preparar uma nova worktree, retornando o status da execução, logs, dúvidas e resultados para a Task, onde a próxima pessoa poderá encontrá-los.

Fixar o modelo ou deixar cada Computer seguir o padrão

Comece fazendo um inventário, pois a resposta pode variar para cada Computer. O comando sharkly computer list exibe os Computers registrados na sua organização, e sharkly computer show <computer-id> retorna um Computer específico com seus respectivos Runtimes. No próprio Computer, iniciar o codex exibe a versão do build e o modelo. O changelog do Codex indica que a versão 0.159.1 (29 de setembro) tornou o GPT-6.1 Sol o padrão, e a sessão de exemplo na documentação exibe model: gpt-6.1-sol medium.

Fique atento a dois pontos. Primeiro, qual binário está em execução. No macOS, um Computer sem o Codex independente instalado pode registrar como seu Runtime a CLI do Codex inclusa no aplicativo para desktop do ChatGPT; no entanto, a documentação do Sharkly recomenda usar uma versão do Codex instalada por você e configurada no PATH. Segundo, qual camada de configuração define o modelo. O guia de configuração básica do Codex define padrões pessoais em ~/.codex/config.toml, permite que um repositório os sobrescreva com seu próprio .codex/config.toml (carregado apenas para projetos confiáveis) e dá precedência aos parâmetros -m ou --model da linha de comando sobre ambos.

Um critério simples de decisão: deixe o Computer seguir o padrão quando ele for utilizado por apenas uma pessoa, executar poucas Tasks por semana e ela preferir acompanhar o modelo recomendado pela OpenAI em vez de gerenciar linhas de configuração. Fixe o modelo quando várias pessoas atribuírem trabalho a Agents nesse Computer, quando uma Crew abranger mais de um Computer ou no meio de uma Sprint — momento em que uma alteração silenciosa pode fazer com que o resultado de terça-feira e o de quinta-feira pareçam equivalentes na Task quando, na verdade, não foram gerados pelo mesmo modelo.

Para fixá-lo, edite a configuração do usuário no Computer que executa o Codex Runtime:

# ~/.codex/config.toml
model = "gpt-6.1-sol"
model_reasoning_effort = "medium"

Ambas as chaves aparecem na documentação de configuração do Codex com estes valores. Se você seguiu nosso guia do GPT-6 Sol, esse arquivo já contém model = "gpt-6-sol", e esse Computer não mudará de modelo após atualizações. Altere a linha apenas quando estiver pronto, não antes.

Atualize o Codex usando o instalador indicado na documentação para instalação e atualização, ou peça ao Sharkly para solicitar a atualização da CLI em um Runtime específico:

curl -fsSL https://chatgpt.com/codex/install.sh | sh
# or, from anywhere with the Sharkly CLI:
sharkly computer update <computer-id> <runtime-id>

Em seguida, execute a nova varredura ou o teste de conexão nos detalhes do Computer e confirme se o Codex Runtime aparece como Available. Por fim, registre o modelo fixado na descrição do Agent. Quem estiver revisando um diff não deveria precisar abrir um terminal em algum Computer para descobrir qual modelo escreveu o código.

As duas configurações que mudaram: esforço e cache

A opção none foi descontinuada. O GPT-6.1 Sol aceita low, medium, high, xhigh e max, mas não aceita none nem minimal. Um Computer cuja configuração solicita none — uma escolha natural para fluxos rápidos no GPT-6 Sol — precisará mudar para low antes da migração, e os resultados merecem uma segunda análise, pois low ainda realiza raciocínio. Se uma execução falhar com a configuração antiga, o log de execução manterá o título e a resposta original do serviço do modelo; além disso, a orientação de solução de problemas do Sharkly para opções não suportadas é verificar as opções do modelo e da requisição em vez de tentar novamente às cegas.

O cache é a grande vantagem silenciosa. A OpenAI precificou a entrada em cache em US$ 0,10 por milhão, “95% mais barato que o preço padrão de entrada e 50% mais barato que o preço de entrada em cache do GPT-6 Sol”. É nos Agents de longa execução que isso se torna evidente. Uma execução que opera em um repositório por uma hora reenvia repetidamente grande parte do mesmo contexto, e membros da Crew que partem da mesma estrutura de repositório, regras e comandos de teste reutilizam o mesmo prefixo durante todo o dia.

Três ressalvas importantes para manter as expectativas alinhadas: a economia por token só se aplica a Computers nos quais o Codex fatura contra uma chave de API; um Computer autenticado com um plano do ChatGPT consome o limite de uso do plano — tema abordado no artigo complementar sobre como executar o GPT-6.1 Sol sem chave de API. O preço de tabela não mudou, logo o trabalho sem cache continua custando o mesmo que na semana passada. Além disso, contextos longos têm uma sobretaxa: a OpenAI precifica qualquer prompt acima de 272 mil tokens de entrada com o dobro das tarifas de entrada e de cache, além de 1,5x na saída para toda a requisição; portanto, um Agent que carrega um contexto enorme a cada iteração deve receber um prefixo menor e estável antes de receber um orçamento maior.

Roteando a Crew: Astra, 6.1 Sol, Luna ou um Runtime Claude

A aposta da OpenAI no 6.1 Sol é entregar resultados próximos ao Astra por uma fração do custo, e todos os dados apresentados vêm das próprias avaliações da OpenAI. No DeepSWE v1.1, a OpenAI afirma que o 6.1 Sol empata com o Astra por cerca de um quinto do custo e supera a melhor pontuação do GPT-6 Sol por 6,4 pontos com menor esforço de raciocínio. No OSWorld 2.0, um benchmark de uso de computador, ele fica a 2,1 pontos do Astra no esforço max por cerca de um sétimo do custo por tarefa. A OpenAI também deixa clara a sua limitação: o Astra ainda mantém a pontuação mais alta no Terminal-Bench Science, com 68,1%, e a OpenAI recomenda usar o Astra para as tarefas científicas mais complexas.

O guia de seleção de modelos da OpenAI organiza a família da mesma forma: Astra para problemas ambíguos, 6.1 Sol para trabalhos complexos onde tempo e custo importam, e Luna para triagem e tarefas de escopo delimitado, tratando essa recomendação como um ponto de partida. Como o modelo é definido na configuração do Runtime, uma regra de roteamento no Sharkly é, na prática, uma regra sobre Computers: um Agent vinculado a um Computer cujo Codex tem o Astra como padrão executará o Astra. Uma regra inicial para testar:

A última linha reflete neutralidade de fornecedores na prática, não uma alegação de benchmark. O Claude Sonnet 5.5 foi lançado um dia antes do 6.1 Sol pelos mesmos valores de US$ 2 e US$ 10, e a publicação da OpenAI compara o 6.1 Sol com o Opus 5.5 e o Fable 5.1, nunca com o Sonnet 5.5. Nenhum fornecedor publicou esse confronto direto; logo, a única comparação válida é aquela executada em suas próprias Tasks. Os argumentos completos para a adoção de uma regra formal com fluxo manual de escalonamento estão no artigo sobre roteamento de modelos para Crews.

Nada disso altera o destino final do fluxo. Um caminho mais acessível para resultados próximos ao nível do Astra se traduz em mais execuções concluídas por dia — e cada uma delas ainda termina em uma pessoa revisando o diff. Agents pesquisam, executam, testam e reportam. Pessoas definem a direção, concedem permissões e aprovam o resultado. O trabalho essencial desta semana é garantir que o painel consiga responder qual Computer executou qual modelo, o que foi concluído, o que falhou por configurações desatualizadas de esforço de raciocínio e o que está aguardando revisão. Se você ainda alterna entre múltiplos terminais do Codex manualmente, o guia sobre como gerenciar múltiplos agentes Codex apresenta primeiro a versão manual desse processo.

Você pode estruturar isso manualmente com worktrees ou usar o Sharkly para gerenciar o fluxo de trabalho.