Um cartão de notícias gerado com o título «Uma história de cliente, dois modelos, zero números», com três selos que dizem «GPT-6.1 Sol: percurso de produção», «GPT-6 Astra: stand de demonstração» e «Números publicados na história: nenhum», e o logótipo da OrcaRouter no canto inferior direito.
Guides & Insights

A história do GPT-6.1 Sol da DevRev é, na verdade, uma história sobre onde o GPT-6 Astra não está

Autor

Alistair Wren

Data de publicação

Modelos mais recentes · 20Ver todos os modelos →
Benchmarks: Artificial Analysis · atualizado diariamente
Voltar para todas as publicações

A OpenAI publicou esta semana um relato de cliente intitulado "DevRev entrega autoatendimento autônomo com GPT-6.1 Sol", e a frase mais informativa dele não é sobre o GPT-6.1 Sol de modo algum. É aquela em que se diz que os engenheiros de vendas da DevRev usam GPT-6 Astra para criar demonstrações para estandes de conferências. O diretor de tecnologia da DevRev, Ahmed Bashir, descreve uma empresa que dividiu seu portfólio de modelos em dois: o modelo intermediário sustenta a via de suporte em produção, e o modelo de fronteira sustenta aquilo que um potencial cliente examina por noventa segundos. Essa é uma evidência mais útil do que qualquer benchmark no texto, porque é uma decisão de implantação tomada por alguém que tem uma conta a pagar.

O momento importa. O GPT-6.1 Sol foi lançado em 29 de setembro de 2026 no DevDay, uma semana depois do GPT-6 Sol, a US$ 2,00 por milhão de tokens de entrada e US$ 10,00 por milhão de tokens de saída. O próprio texto da DevRev sobre a parceria com a OpenAI traz um carimbo de atualização de 2 de novembro de 2026, e o relato de cliente é a primeira vez que um serviço em produção identificado colocou o modelo de faixa intermediária, em vez do principal, no caminho voltado ao cliente. Não é um lançamento. É a primeira referência de trabalho.

O que a DevRev realmente executa

A DevRev cria dois produtos sobre o mesmo substrato. O Computer é o colega de equipe de IA que responde e age em dados de negócios; o Operator é o agente que executa uma ação aprovada ou encaminha uma solicitação para a pessoa certa. Ambos precisam das mesmas três coisas antes que um modelo seja autorizado a se aproximar de um cliente: contexto da empresa, permissões que correspondam à função de uma pessoa e ações que possam ser desfeitas. O modelo fornece raciocínio, planejamento e seleção de ferramentas. A estrutura de execução da DevRev fornece o restante, e o Agent Studio é onde um cliente descreve em conversa como uma ferramenta deve se comportar e, em seguida, fixa as partes que não devem variar com regras fixas.

Duas propriedades na história valem mais do que os elogios. As ações são reversíveis. As respostas citam as suas fontes. Esses são os dois modos de falha que impedem as empresas de permitir que um agente encerre um chamado, e a DevRev está a afirmar que ambos são comportamento do produto, e não do modelo. Se estiver a avaliar qualquer agente de autoatendimento, estas são as perguntas a fazer, e nenhum ranking responde a elas.

O número que será associado a esta história é de julho, e não se trata de Sol.

Pesquise por cobertura da DevRev e da OpenAI e você encontrará um par impressionante de números: 48% mais preciso e 4,4 vezes menos tokens por resposta correta. Eles são reais, estão publicados e não têm nada a ver com o GPT-6.1 Sol.

Esses números vêm de um comunicado de 9 de julho de 2026 que anunciava o Enterprise-Bench, um benchmark aberto de agentes empresariais que a DevRev criou com o Laude Institute e publicou no harness Harbor. Nessa comparação, o Computer da DevRev obteve 94,3% contra 63,6% no conjunto de dados XL, e usou aproximadamente 5.598 tokens por resposta correta contra 24.461. A comparação foi explicitamente harness contra harness, com ambos os sistemas executando o mesmo modelo subjacente. A DevRev atribuiu a diferença à sua arquitetura de recuperação e memória compartilhada, e não ao modelo por trás. Também foi comparado com o Claude Code, e não com qualquer coisa que a OpenAI tenha lançado em setembro.

O caso de cliente da OpenAI menciona o Enterprise-Bench, e Bashir diz que o GPT-6.1 Sol tem bom desempenho nele. Essa é uma afirmação qualitativa. Não há pontuação, nem recorte do conjunto de dados, nem comparação. Qualquer pessoa que tente encaixar os números de julho no relato de novembro está medindo outra coisa, em outro modelo, em outro trimestre. A leitura honesta é mais restrita e ainda assim interessante: a DevRev tem um benchmark criado exatamente para essa decisão e optou por não publicar nele uma linha do Sol.

O que a história não diz

Não há taxa de resolução, nem volume de tickets, nem percentil de latência, nem contagem de tokens e nem preço no post da OpenAI. Para uma história de cliente sobre autoatendimento autônomo, isso é o placar inteiro faltando.

A figura publicada mais próxima é a prova de conceito do BILL da DevRev, em que a BILL relatou uma taxa de resolução por IA de 70% em consultas reais de clientes usando sua própria avaliação. Os materiais da DevRev também citam uma redução de 77% em tokens e uma queda de cerca de nove minutos para cerca de 1,5 minuto em perguntas de várias etapas, medidas em relação à sua própria abordagem anterior. Esses números foram relatados pelo fornecedor e não foram reproduzidos, e nenhum deles está vinculado à geração de modelo atualmente em produção. Trate-os como o formato da alegação, não como o seu tamanho.

A generated scoreboard titled 'DevRev: what is measured, and what is claimed', with a July column showing 94.3% versus 63.6% accuracy and 5,598 versus 24,461 tokens per answer measured on the Opus 4.8 family, a November column showing no published accuracy, token or resolution figures alongside $2.00/$10.00 for GPT-6.1 Sol and $10.00/$50.00 for GPT-6 Astra, and a takeaway line noting that the July figures measure a harness against a harness.

A restrição do próprio Bashir é a que devemos manter: "Essas coisas precisam conseguir rodar e se concluir em segundos, não em minutos." Uma interação de suporte que leva vinte minutos de raciocínio não é autoatendimento, seja qual for a pontuação que obtenha. Essa frase explica a escolha do modelo melhor do que qualquer tabela de benchmark.

A aritmética que uma central de suporte pode conferir

Considere um ticket rotineiro: 20.000 tokens de entrada de contexto recuperado, 2.000 tokens de saída, incluindo raciocínio. No preço de tabela do GPT-6.1 Sol, isso é US$ 0,04 de entrada e US$ 0,02 de saída, ou cerca de seis centavos. A mesma solicitação no GPT-6 Astra, a US$ 10,00 de entrada e US$ 50,00 de saída, é US$ 0,20 mais US$ 0,10, ou cerca de trinta centavos. Mesma tarefa, cinco vezes a conta.

Seis centavos são um piso, não uma previsão. Tokens de raciocínio são cobrados como saída, novas tentativas são cobradas duas vezes, e qualquer loop de ferramentas multiplica ambos. Mas a proporção é o que importa, e ela resiste a todas as três ressalvas. Os próprios números de custo reportados pelo fornecedor da OpenAI apontam na mesma direção: no Terminal-Bench Science 0.1, a OpenAI colocou o GPT-6.1 Sol a US$ 5,47 por tarefa, contra US$ 23,80 do GPT-6 Astra e US$ 23,21 do Claude Opus 5.5, com o Sol marcando 57,02% no esforço máximo, contra 68,1% do Astra. Você está comprando onze pontos de capacidade por quatro vezes o dinheiro, e, em uma fila de suporte, o décimo primeiro ponto geralmente é uma paráfrase melhor, não um ticket resolvido.

É esse o cálculo em que o modelo de precificação do OrcaRouter se baseia: o preço de tabela do provedor é repassado sem mark-up, então uma tarifa como $2.00 e $10.00 é o valor que você paga, e uma mudança de preço do fornecedor entra em vigor no mesmo dia, e não na próxima renovação de contrato. Ambos os modelos ficam atrás de uma única chave, o que significa que a divisão que a DevRev fez em sua arquitetura — modelo barato no caminho de volume, modelo caro onde a resposta é o produto — é uma decisão de roteamento, e não uma segunda compra. Para as etapas em que uma chamada de ferramenta errada sai cara, o failover para um modelo mais forte por solicitação é a diferença entre uma tarde ruim e uma semana ruim.

A screenshot of the OrcaRouter model page for openai/gpt-6.1-sol, dated 2026-09-29, showing a 1M-token context window, 128K maximum output, $2.00 input and $10.00 output per million tokens, a 937 ms median time to first token, an 8.99 s p95, and 382.0M tokens of seven-day traffic.

Por que o modelo de nível intermediário fica com o caminho de produção

O instinto é ler isto como uma questão de custo. É em parte uma questão de latência. O GPT-6.1 Sol funciona com raciocínio sempre ativado em cinco níveis de esforço, de low a max, com medium como padrão, e não aceita temperature nem top_p de forma alguma. Isso remove o botão de ajuste ao qual a maioria das equipes recorre quando um agente parece lento e deixa o nível de esforço como o acelerador. Entre low e max, a diferença no tempo até o primeiro token de resposta é medida em minutos, não em milissegundos.

Os números independentes situam-se onde seria de esperar para um modelo nesta posição. No Artificial Analysis Intelligence Index v5.0.1, o GPT-6.1 Sol obtém 55 em esforço máximo, a 56 tokens por segundo, $1.27 por tarefa de índice concluída e 63,7 milhões de tokens de saída ao longo da execução. Na nossa própria telemetria de sete dias, apresenta um tempo mediano até ao primeiro token de 937 ms, uma taxa de erro de 5,7% e 39,5 tokens por segundo de saída, que é o tipo de perfil sobre o qual se pode construir um fluxo de suporte: não é o modelo mais rápido disponível, mas é suficientemente previsível para que se possa dimensionar uma fila com base nele.

A screenshot of the Artificial Analysis page for GPT-6.1 Sol at max effort, showing an Intelligence Index of 55, an output speed of 56 tokens per second, 20.3 minutes per index task, $1.27 cost per index task, 63.7M output tokens, and list pricing of $2.00 input and $10.00 output per million tokens.

A janela de contexto é a outra metade da escolha. Com 1.050.000 tokens e um teto de saída de 128.000 tokens, um processo, seu histórico e o conhecimento recuperado cabem todos em uma única requisição. É isso que torna possível um agente que raciocina "sobre dados em tempo real" sem uma camada elaborada de chunking — e é dessa parte da ficha técnica que uma taxa de resolução de 70% realmente depende.

O que transformaria isto num estudo de caso?

Três coisas fariam isto passar de um logotipo numa página para evidências com as quais é possível planejar. Uma taxa de resolução publicada para o Operator, num conjunto de dados nomeado, com a taxa de escalonamento humano ao lado. Uma distribuição de latência em vez de uma média, porque o p95 é onde o autoatendimento falha. E uma ablação Sol versus Astra no Enterprise-Bench, já que a DevRev já tem o harness e já demonstrou que publicará resultados quando eles favorecerem sua arquitetura.

Bashir aponta para duas coisas que quer a seguir: a Decisions API, para as pequenas decisões de julgamento que são caras de codificar como regras, mas não exigem raciocínio profundo, e a Ultrafast, o nível de velocidade 6× da OpenAI a US$ 12,00 de entrada e US$ 60,00 de saída por milhão de tokens, disponível para compra desde 8 de outubro. Ambas são tentativas de comprar latência sem comprar inteligência, o que é o instinto correto para uma fila de suporte e o oposto do que a maioria dos roteiros de agentes busca.

O padrão a observar não é especificamente a DevRev. É que a primeira implantação de produção nomeada do GPT-6.1 Sol colocou o modelo barato onde estão os clientes e o modelo caro onde estão os potenciais clientes. Se isso se tornar o formato normal de uma stack de agentes empresariais — um cavalo de batalha na via de alto volume, um carro-chefe para a demonstração —, então a pergunta interessante para todo fornecedor deixa de ser qual modelo é o mais inteligente e passa a ser com que limpeza você consegue mover uma requisição entre eles.

Comparados neste artigo2

Detectado a partir deste artigo · Benchmarks: Artificial Analysis · atualizado diariamente