Drex Max volta os olhos para o Modelo de Decisão — e precifica cada clique em US$ 0,06

Um agente de uso de computador não é realmente uma única decisão. Reservar um voo envolve trinta delas: qual campo clicar, qual resultado abrir, se o widget de calendário terminou de renderizar, se a tarifa que ele está vendo é a que ele quer. Cada uma dessas é uma ida e volta de captura de tela e, se o modelo do outro lado for um modelo de chat de fronteira, cada uma custa segundos e uma fatura de modelo de fronteira. Drex Max, que a Nace.AI lançou em disponibilidade geral em 19 de outubro de 2026, é uma tentativa de reduzir essa aritmética. É um modelo de decisão em vez de um modelo de chat — você entrega a ele uma tela e um conjunto de opções tipadas, e uma única passagem direta retorna uma probabilidade para cada opção. A Nace o lista a US$ 0,06 por milhão de tokens de entrada, latência mediana de 183 ms e nenhuma cobrança de saída, porque ele não escreve nada. As falhas de IA documentadas e os incidentes com agentes por trás de lançamentos como este estão reunidos no OrcaRouter AI Incident Archive, onde cada entrada traz suas próprias fontes, gravidade, grau de confiança e indicador de disputa.

A comparação que Nace coloca ao lado disso é TypeSafe J​ev 1.14, o modelo de decisão que definiu o formato das solicitações da categoria, e os modelos de fronteira de propósito geral que os agentes usam hoje. Na própria tabela publicada por Nace, isso equivale a US$ 10,17 por mil decisões para o Claude Opus 5.5 e cerca de 3,5 segundos por decisão, contra US$ 0,06 e 174 ms para o Drex Max nas mesmas 243 perguntas com captura de tela. Números de fornecedor, executados internamente, sem auditoria por ninguém fora da Nace — mas a ordem de grandeza é o que importa, e é por isso que este lançamento importa mais do que sua linha no benchmark.

O que realmente foi lançado

Drex Max é o primeiro modelo da linha Drex com um codificador de visão. Drex 2.0 e Drex 1.5 tinham entrada de texto e saída de probabilidade; Max lê capturas de tela, gravações de tela, documentos digitalizados, gráficos, fotos e quadros de vídeo, e responde aos mesmos três tipos de pergunta que seus antecessores.

• ID do modelo — drex-max, fixado. Sem pesos abertos; hospedado pela própria API da Nace, sem checkpoint para download.

• Formato da entrada — uma state string mais um objeto questions, e um array de images com até 8 imagens por requisição. O endpoint é POST /v1/systemone, o mesmo caminho que o J​ev usa.

• Tipos de pergunta — escolha (opções nomeadas, retorna uma probabilidade por opção), noul (uma pergunta sim/não, retorna P(true)), pontuação (níveis ordenados, retorna um nível esperado e uma distribuição). Várias perguntas sobre um mesmo estado compartilham uma única passagem.

• Contexto — 131.072 tokens por pergunta, incluindo tokens de imagem, conforme o guia da API. O post de lançamento diz separadamente "janela de contexto de 262K tokens". Esses dois números não concordam, e é a primeira coisa a resolver antes de dimensionar um buffer de captura de tela.

• Preço — $0.06 por milhão de tokens de entrada; a saída não é cobrada. A Nace cita o mesmo valor como $0.06 por mil decisões, o que implica aproximadamente mil tokens por chamada.

• Predecessores — Drex 2.0 (35B no total, cerca de 3B ativos, construído sobre o Qwen3.6-35B-A3B, pesos abertos) a $0,06 por mil decisões, e o Drex 1.5 (9B, somente texto) a $0,04.

• Implantação — gerida nas GPUs da Nace, dedicada, dentro de uma conta AWS ou Azure do cliente, ou em ambiente air-gapped, tudo com o mesmo contrato de requisição. A ausência de pesos significa que não há auto-hospedagem, mas não significa que seja apenas SaaS.

Não há nada de exótico na interface. Isso é intencional: a Nace criou o Drex Max para ser compatível no nível de protocolo com o SDK J​ev da TypeSafe, de modo que @typesafe-ai/sdk continue funcionando com uma URL base, chave e modelo padrão alterados. A compatibilidade não é uma cortesia com um rival. É assim que se experimenta um novo participante — a migração mais barata é aquela que é um valor de configuração.

A parte que é genuinamente diferente: uma distribuição em vez de uma frase

Um modelo de chat responde a uma pergunta sobre uso de computador escrevendo até chegar a uma resposta. "Olhando a página, os resultados da busca parecem ter carregado, então a próxima ação deve ser clicar no segundo resultado" — e então seu harness analisa essa frase, ou um blob JSON, e torce para que o modelo não tenha escolhido uma opção que você nunca ofereceu. O custo desse design é pago duas vezes: uma em tokens de saída, e outra no parser que você precisa manter porque o modelo pode alucinar um botão que não está na tela.

O Drex Max não consegue fazer isso. Ele retorna uma probabilidade sobre as opções fornecidas e nada mais. Se você oferecer cinco candidatos clicáveis, receberá cinco números que somam um. Essa é uma capacidade mais restrita e um ajuste muito melhor para um loop, por três motivos que importam mais em produção do que em uma demonstração.

O primeiro é a definição de limiares. Uma distribuição de probabilidade permite escrever a regra que você realmente quer: aja quando a opção principal superar 0,9; encaminhe para um modelo mais lento ou para um humano quando não superar. Um modelo generativo fornece uma frase e um campo de confiança que significa algo completamente diferente — normalmente o quão concentrada era a distribuição de tokens, não a probabilidade de a resposta estar correta.

O segundo é o comportamento em caso de falha. Um agente que só consegue responder com opções declaradas não pode inventar um sexto botão. Ele pode estar errado e pode estar mal calibrado, mas não pode produzir uma ação que sua estrutura de execução não saiba executar.

O terceiro é a economia. Como não há tokens de saída, o custo de pontuar dez opções é o mesmo de pontuar duas. A formulação de Nace é que isso o torna barato o suficiente para chamar a cada passo, e a US$ 0,06 por mil chamadas a aritmética se sustenta: mesmo uma tarefa desleixada de trinta passos custa menos de dois décimos de centavo em decisões. A mesma tarefa com o Opus 5.5, segundo o valor por decisão de Nace, custaria cerca de trinta centavos — não é fatal, mas é trinta vezes o preço daquilo que está fazendo.

A tabela de benchmark, e de quem são esses números

Cada número abaixo vem do post de lançamento da Nace. O Decision Index 0.3.2 é um ranking público de benchmarks no estilo de tomada de decisão, mas a execução do Drex Max nele é da própria Nace, usando o kit oficial, e ninguém fora da Nace a reproduziu. A pontuação "Full" do ranking também mistura testes privados que não fazem parte desta execução. Trate a forma dos resultados como informativa e as casas decimais como marketing.

A manchete é um Decision Index público de 67,6, contra 61,3 do Drex 2.0, 58,1 do Drex 1.5, 60,7 do J​ev 1.14 e 47,8 do GPT-6 Luna Decisions. No Vision Index complementar — o número que importa para um modelo cujo principal atrativo é enxergar —, o Drex Max marca 74,5 contra 63,9 do Luna.

• Mind2Web — 88,6 vs 81,2 para o GPT-6 Luna Decisions, a linha mais diretamente relevante para agentes de navegador.

• OSWorld-Verified — 0,780 vs 0,756 para GPT-6 Sol e 0,790 para Claude Opus 5.5. O Drex Max supera o primeiro e perde por pouco para o segundo.

• OSWorld-V2 — 0,737 vs 0,744 para Sol e 0,761 para Opus 5.5. Mesma história, diferença ligeiramente maior.

• Chamada de ferramentas BFCL — 98,2, à frente do J​ev 1.14 com 96,4 e do Claude Opus 5.5 com 97,3, atrás apenas do GPT-6 Sol.

• DecideBench — 98,5 em itens e 97,0 em pares, ambos à frente do J​ev 1.14.

• Decisões de negócios vs J​ev 1.14 — FinEntity 92,3 vs 81,9, BANKING77 90,0 vs 79,7, ContractNLI 75,9 vs 57,7.

As linhas do OSWorld merecem uma ressalva que a tabela de Nace não explicita. Essas pontuações descrevem uma pilha completa de automação, e não está documentado quanto do ciclo em torno do Drex Max também era o próprio harness do Nace. Um modelo de decisão que escolhe bem a próxima ação ainda depende daquilo que tira a captura de tela, espera pelas renderizações e decide quando a tarefa está concluída. Leia 0,780 como evidência de que as decisões não são o gargalo, e não como uma promessa sobre o seu agente.

Onde ele perde, que é a metade mais útil da tabela

As perdas não estão escondidas, mas são fáceis de passar despercebidas ao passar os olhos, e duas delas descrevem limites reais, e não ruído de arredondamento.

Em conhecimento geral e raciocínio difícil, os modelos de decisão simplesmente não são competitivos com os modelos de chat de ponta, e o Drex Max não muda isso. O MMLU-Pro é 72,5, atrás do 82,1 do J​ev 1.14, do 93,0 do Sol e do 94,0 do Opus 5.5. O HLE é 19,0 contra 19,4 do J​ev — um empate na parte inferior da faixa de qualquer forma. Isso é esperado para um modelo cujo trabalho é escolher de uma lista curta com base em uma triagem, e é a razão pela qual um modelo de decisão é um componente de um agente, não um substituto do modelo que planeja.

Mais interessante é a regressão em relação ao seu próprio antecessor. No When2Call, que pergunta se uma chamada de ferramenta é justificada, Drex Max obtém 85,2, enquanto Drex 2.0 alcança 86,5 e o mais antigo e barato Drex 1.5 marca 89,7. O modelo Drex mais novo e mais caro é o pior dos três em saber quando não agir. Se seu fluxo de trabalho depende de contenção — um agente de suporte que deve permanecer em silêncio em vez de chamar uma ferramenta de reembolso —, a capacidade de visão não lhe garante isso, e um modelo de texto mais barato ainda pode ser a escolha certa.

O mesmo padrão aparece em duas linhas de visão que seguem na direção oposta. KIE, extração de informações-chave em formulários digitalizados, é 95,5 contra 97,5 do Luna. A moderação do Hateful Memes é 70,6 contra 71,2. Nenhuma das diferenças é grande, e ambas estão em domínios nos quais a vantagem do Drex Max em outros pontos chega a trinta pontos, o que sugere que o codificador de visão é treinado para layouts de tela e gráficos, e não para formulários impressos ou memes.

A latência também piorou. A mediana de 183 ms do Drex Max é 32 ms mais lenta que a do Drex 2.0 e 38 ms mais lenta que a do Drex 1.5. Em um loop que roda trinta vezes por tarefa, isso adiciona cerca de um segundo por tarefa, contra vários segundos economizados por etapa em comparação com um modelo de fronteira. Ainda é a troca certa, mas vale saber que o codificador de visão não vem de graça.

Um número precisa ser separado antes de ser citado para você. Os 174 ms no parágrafo de abertura são a medição apenas por captura de tela da Nace — 243 perguntas de imagem, uma requisição por vez, contra 253 ms do J​ev 1.14 no mesmo conjunto. Os 183 ms são a mediana em toda a suíte de benchmarks na tabela de lançamento. Ambos são da Nace; são medições diferentes, e a mais favorável é a mais estreita.

Duas armadilhas na API antes de você integrar qualquer coisa

A documentação contém um detalhe que custará uma tarde a alguém se passar os olhos por ele. drex-latest não aponta para o Drex Max. É um checkpoint fixado, e o alias resolve para outra coisa. Qualquer pessoa que siga o guia de início rápido, troque pela própria chave e defina TYPESAFE_DEFAULT_MODEL=drex-latest — que é exatamente o que as instruções de compatibilidade com o J​ev mandam fazer — estará chamando um modelo somente de texto e se perguntando por que suas capturas de tela são ignoradas.

A segunda armadilha é o tamanho. O guia da API limita as solicitações a oito imagens e 131.072 tokens por pergunta, incluindo tokens de imagem; o post de lançamento anuncia 262K. Até que a Nace concilie os dois, dimensione com base no número menor. Não há um custo publicado de tokens por imagem, o que torna difícil raciocinar sobre o limite com antecedência: uma captura de tela em resolução total não tem um número fixo de tokens, e a documentação não diz como as imagens são redimensionadas ou divididas em blocos.

Uma coisa que é mais fácil do que na solução atual: o Drex Max aceita capturas de tela de qualquer dimensão. A API do J​ev 1.14 rejeita imagens com um lado inferior a 280 px ou superior a 1.568 px, que é o tipo de restrição que se manifesta como uma falha silenciosa num ciclo de retentativas às 2 da manhã.

O que isto faz a uma decisão de roteamento

A questão prática não é se o Drex Max é melhor que um modelo de fronteira. Não é, e não tenta ser. A questão é quais das trinta decisões em uma tarefa merecem um modelo de fronteira e quais merecem uma distribuição de probabilidade de 174 ms, e isso é um problema de roteamento antes de ser um problema de modelo.

O Drex Max não está na nossa lista de rotas. O catálogo do OrcaRouter não o inclui, e nada aqui deve ser interpretado como uma alegação de disponibilidade da nossa parte — a Nace o vende por meio da própria API e do próprio console. O que nós oferecemos é o incumbente contra o qual ele é medido. TypeSafe Jev 1.13 é uma rota listada a US$ 0,042 por milhão de tokens de entrada em um contexto de 65.536 tokens, servido pelo mesmo POST /v1/systemone corpo, então um A/B entre um modelo de decisão e seu loop atual de screenshot até o frontier é uma string de modelo em vez de uma reescrita. A maneira barata de resolver isso é manter suas chamadas de decisão somente texto onde estão, adicionar uma etapa de leitura de tela ao lado delas para as tarefas que precisam de olhos, e avaliar ambos com base nos seus próprios logs em vez das 140.178 solicitações pontuadas da Nace.

Esse tipo de divisão só funciona se as peças puderem ser acessadas de um único lugar. Uma única chave para mais de 200 modelos, preço de tabela do provedor repassado sem markup por token, e failover automático entre provedores é o que impede o experimento de se degenerar em um ramo obsoleto quando a pessoa que o configurou muda de equipe. Isso também importa aqui por um motivo específico: o Drex Max é novo, não auditado e somente via API, e a forma segura de adotar um componente não comprovado é colocá-lo por trás de algo que possa recorrer a um modelo conhecido quando sua confiança cair ou o endpoint se comportar mal. Encaminhe as decisões com alta confiança para o modelo barato e deixe o failover cuidar do resto.

O que mudaria essa leitura?

Uma execução independente do Decision Index é a primeira coisa a fazer. A suíte é pública, Nace diz que as avaliações são reprodutíveis e, até alguém de fora da empresa rodar o Drex Max nela, o 67,6 é um número de fornecedor. As células a observar quando isso acontecer são as que apontam em direções opostas: uma vantagem de 30 pontos no Mind2Web ao lado de uma regressão no When2Call não é uma curva de capacidade suave, descreve um modelo treinado intensamente em "qual destes é o próximo clique" e menos intensamente em "devo clicar em alguma coisa". Se isso se confirmar, é o fato operacionalmente mais importante sobre o Drex Max e não está nos destaques.

A latência de produção sob concorrência é o segundo ponto. O próprio valor de throughput da Nace — cerca de 25 solicitações por segundo em uma réplica H100, sem erros até 64 em voo — é para o Drex em geral, não especificamente para o Max. A proposta central do design é que ele fica em um hot path em cada etapa, o que torna o p95 sob carga muito mais relevante do que uma mediana de 183 ms, e nada publicado aborda isso.

Terceiro, a precificação precisa de um exemplo prático com imagens. US$ 0,06 por milhão de tokens de entrada só é útil se você souber quanto custa em tokens uma captura de tela, e nenhum número publicado faz isso. Uma equipe que está orçando um loop de 30 etapas com uma tela 1440p por etapa está chutando até que a Nace publique a contabilização de imagens ou alguém meça isso.

Nada disso torna o lançamento menos interessante. Um modelo de decisão que enxerga é um componente genuinamente diferente de um modelo de chat ao qual se pede para olhar uma captura de tela, e a diferença de preço é grande o suficiente para mudar o que um agente pode se dar ao luxo de fazer a cada passo. Só que ainda não é um número que alguém fora da Nace tenha verificado — e a parte da tabela que sobreviver ao contato com uma implantação real provavelmente será a parte que ninguém está citando.