Pareto 26.9 vs. Prévia do Pareto 26.10 da Unbiased: O Pin Estável e a Prévia

A linha Pareto da Unbiased agora oferece dois lançamentos chamáveis com duas respostas diferentes para a mesma pergunta, e a partir desta semana você precisa escolher um deles de propósito. Pareto 26.9 é o lançamento para o qual o alias padrão do fornecedor resolve: 262.144 tokens de contexto, US$ 2,50 por milhão de tokens de entrada, sem data de expiração associada. Pareto 26.10 Preview é a build opt-in: quatro vezes o contexto, cerca de um terço do preço de entrada, quatro pontuações de benchmark que o próprio fornecedor chama de preliminares, e uma data de expiração gravada em seu registro de catálogo. Ambos estão ativos. Ambos recebem texto e imagens e retornam texto. Nenhum é uma variante do outro que você possa alternar com uma flag no momento da requisição.

O que mudou não é nenhum dos modelos. É que a versão estável finalmente tem seu próprio endereço. Em 13 de outubro de 2026, o catálogo roteado que lista esta família passou a incluir unbiased/pareto-26.9 como uma entrada chamável separadamente, ao lado de uma entrada de alias que sempre redireciona para a versão atual. Antes disso, a única maneira de alcançar o modelo estável com certeza era pedir Pareto e aceitar o que quer que o alias entregasse. Agora as duas versões ficam na mesma lista com seus próprios preços, seus próprios limites e seus próprios metadados de expiração — e escolher entre elas é uma decisão que você toma, em vez de uma que é tomada por você.

Os dois lançamentos, dimensão por dimensão

Todas as diferenças publicadas entre eles cabem nestas sete linhas. À esquerda está o Pareto 26.9; à direita está o Pareto 26.10 Preview.

• Janela de contexto — 262.144 tokens vs 1.048.576 tokens. Quatro vezes o espaço, sem uma faixa menor oferecida em nenhum dos dois. • Saída máxima — 131.072 tokens vs 131.072 tokens. A janela de entrada maior não garantiu uma resposta maior. • Preço de entrada — $2,50 por milhão de tokens vs $0,80. A pré-visualização fica em cerca de 32% da tarifa estável. • Preço de saída — $7,50 por milhão de tokens vs $3,20. Cerca de 43% dela. • Entrada em cache — $0,25 por milhão de tokens vs $0,03. A pré-visualização é aproximadamente um oitavo, que é a linha que mais altera a fatura de um agente de longa duração. • Tabela de benchmarks publicada — uma pontuação, numa fatia parcial de tarefas, vs quatro pontuações que o fornecedor classifica como preliminares. • Termos de estabilidade — sem expiração no registro, e o fornecedor chama a isto a versão padrão vs uma pré-visualização opcional cujo registro de catálogo tem uma data de expiração de 15 de outubro de 2026.

Duas dessas linhas fazem a maior parte do trabalho. A taxa de entrada em cache é a que decide se uma longa trajetória agêntica é viável em qualquer uma das duas versões, e o campo de expiração é o que decide se a prévia é algo sobre o qual você pode construir.

Por que os números de versão não estão alinhados

Os números são rótulos de mês, não uma sequência a partir da qual você deve raciocinar. O próprio model card da Unbiased data o Pareto 26.9 como uma execução de 20 de setembro de 2026 e descreve o 26.10 Preview como o lançamento de 1º de outubro que veio depois. O catálogo que lista o 26.9 mostra que ele entra em seu registro em 13 de outubro — três semanas depois da data de lançamento que o fornecedor imprime. E o post de lançamento do fornecedor para o preview diz que a versão anterior "26.9" vinha rodando por duas semanas em gateways de terceiros sob um nome temporário antes de ser nomeada.

Reunindo essas três afirmações, a lição prática é que um número de versão aqui indica de qual mês veio uma build, e nada sobre se a build ainda é atual, ainda tem suporte ou ainda é a que está por trás do alias. Também significa que a data que você vê em uma página de catálogo é uma data de listagem, não uma data de lançamento. Interpretá-la como a segunda é o erro mais comum cometido em relação a esta família, e agora ele é cometido nas duas direções: 26.9 parece três semanas mais recente do que é, e a prévia parece cinco semanas mais antiga.

O que a prévia oferece, e o que a ficha de benchmark realmente diz

O argumento a favor da prévia é aritmético. Quatro vezes o contexto por um terço do preço de entrada, com uma taxa de leitura de cache baixa o suficiente para que uma trajetória longa custe uma fração do que custaria no 26.9. Unbiased também afirma menor latência na prévia, com o maior ganho em execuções agênticas longas — uma alegação sem nenhuma medição publicada que a respalde, nem do fornecedor nem de qualquer outra pessoa.

O argumento contra recorrer a ele por reflexo é mais sutil e está no único lugar onde os dois lançamentos podem ser comparados. No DeepSWE v1.1, o benchmark de codificação agêntica em que ambos os lançamentos aparecem, o model card do fornecedor mostra Pareto 26.9 com 70,0% a US$ 0,29 por tarefa e Pareto 26.10 Preview com 69,9% a US$ 0,24 por tarefa. O lançamento mais novo e mais barato pontua marginalmente mais baixo no único benchmark em que ambos têm um número, e vence no custo por tarefa em cerca de 17%. Isso não é um escândalo e não é um erro de arredondamento a ser desconsiderado — é exatamente o que um sistema combinado mais barato deveria parecer, e vale a pena saber antes de assumir que a preview é uma atualização estritamente superior.

Duas ressalvas cabem nessa comparação, e o fornecedor publica ambas. O número 26,9 vem de uma fatia de 30 tarefas, não do conjunto completo DeepSWE v1.1, portanto não é a mesma medição da prévia. E todos os números aqui são executados pelo fornecedor: as quatro pontuações da prévia — 92,4% no GPQA-Diamond, 49,9% no Humanity's Last Exam somente texto, 69,9% no DeepSWE v1.1, 50,8% no Terminal-Bench 4.0 — carregam o rótulo do próprio fornecedor de "preliminar, pode mudar antes da publicação final", e o cartão do modelo afirma que denominadores e metodologia de custo ainda "requerem confirmação". Ninguém fora da Unbiased publicou uma pontuação para qualquer um dos lançamentos. Trate a planilha inteira como um motivo para testar, não como um motivo para trocar.

A expiração é a parte em torno da qual é preciso planejar.

O registro da preview traz uma data de expiração de 15 de outubro de 2026 — um dia depois de isto ser escrito. O que acontece nessa data não está documentado em lugar nenhum que conseguimos encontrar: nem no changelog, nem no cartão do modelo, nem na página de preços. Nada no material do fornecedor diz que a preview deixa de ser servida, e o post de lançamento diz, em essência, o oposto de um encerramento — que "o preço não vai subir, e o slug da preview não vai quebrar debaixo de você", e que na graduação o 26.10 se torna o padrão para assinantes enquanto as cotas semanais dobram, de 25M para 50M tokens no plano Personal de $10 e de 300M para 600M no nível de $100.

Então, a leitura honesta não é "a versão prévia morre amanhã". É que a versão prévia é regida por termos que mudam, e que uma build com um campo de expiração em seu registro não é a versão a ser fixada para um sistema que você não quer revisitar. É esse o argumento inteiro a favor do 26.9 como padrão: ele melhora mais devagar e custa três vezes mais na entrada, mas é o que o fornecedor chama de versão, e não de experimento, e seu registro não tem relógio algum.

Mantendo ambos sem reescrever a integração

O motivo de isto ser uma decisão de roteamento, e não de modelagem, é que ambas as versões aceitam o mesmo formato de solicitação. A mesma família de endpoints, os mesmos parâmetros, a mesma superfície de entrada de texto e imagem/saída de texto — a única coisa que difere é a string que você coloca no campo do modelo. Isso torna a superfície de migração minúscula e a disciplina de fixação de versão o problema inteiro: exatamente um valor, em exatamente um lugar, determina qual de dois sistemas com preços muito diferentes responde a você.

É para isso que o DSL de roteamento no OrcaRouter foi criado. Você compõe uma chamada a partir de pernas nomeadas e mantém a string do modelo como um valor de configuração em vez de uma constante enterrada no código da aplicação, de modo que passar de uma prévia para um pin estável é uma edição na rota em vez de um deploy. O mesmo vale para a cadeia de failover: uma prévia que muda, expira ou começa a retornar erros torna-se um evento de fallback em vez de um incidente. Não distribuímos nenhuma das versões do Unbiased — esta é uma família servida pelo fornecedor com um único provedor, o próprio fornecedor — então a maneira de chamá-la é a própria API do Unbiased, e se o seu objetivo é comparar as duas versões com a sua própria carga de trabalho, ambas estão acessíveis lá hoje.

Qual deles fixar

Se você está colocando em produção algo que precisa responder no mês que vem sem que ninguém mexa nele, fixe o Pareto 26.9. Ele custa três vezes mais por token de entrada e oferece um quarto do contexto e, em troca, é a versão para a qual o alias do fornecedor aponta, não tem campo de expiração, e seu único benchmark publicado — uma pontuação de fatia parcial — por acaso é a maior das duas. Essa é a resposta chata, e é a certa para um caminho de produção.

Se você está avaliando, ou se sua carga de trabalho tem contexto longo e é sensível a custos o suficiente para que um terço do preço de entrada mude o que é viável, execute o Pareto 26.10 Preview de forma deliberada e com um fallback por trás. Uma taxa de entrada em cache de US$ 0,03 por milhão contra US$ 0,25 é a diferença entre um loop de agente que você pode custear o dia todo e um que você precisa racionar, e a janela de 1.048.576 tokens é a única das duas que comporta um repositório grande ou um conjunto extenso de documentos em uma única requisição. Aproveite o preço, aproveite a janela e mantenha a data de expiração em um evento de calendário, em vez de nas suas suposições.

O que mudaria esta recomendação é restrito e verificável: um anúncio de que a prévia foi promovida e o alias mudou, um benchmark independente para qualquer uma das versões, ou a prévia continuar disponível depois de 15 de outubro com as mesmas tarifas. Qualquer um desses fatores transforma uma escolha de duas vias em uma escolha de via única. Até que um deles se concretize, as duas versões desta família são produtos genuinamente diferentes, com perfis de risco genuinamente diferentes, e a única coisa que você controla é qual string suas requisições carregam.

Uma versão que pode mudar debaixo de você no meio da semana é o caso para o qual o failover automático foi criado: failover automático — uma prévia que expira ou começa a apresentar erros torna-se um evento de fallback em vez de um incidente.