Pareto 26.10 Preview vs Pareto: Mesma String de Modelo, Dois Modelos Diferentes

Unbiased lançou Pareto 26.10 Preview em 1º de outubro de 2026 e deixou a versão anterior, Pareto, listada ao lado. Os dois não são variantes de uma família entre as quais se escolhe com uma flag. São dois lançamentos por trás de uma única marca, e a própria string de modelo do fornecedor — pareto — agora resolve para a mais nova, explicitamente instável. Então, a pergunta da comparação não é realmente “qual é melhor”. É: qual delas a sua requisição realmente alcança, e o que acontece com a resposta quando isso muda debaixo de você?

O único lugar onde os dois são descritos juntos é a listagem técnica pública do modelo. A ficha do modelo, a página de preços e o FAQ da própria Unbiased descrevem um único produto empilhado e nunca mencionam a divisão. Essa assimetria — um diff público detalhado de um lado, silêncio do outro — é o ponto de partida honesto para uma comparação direta, porque mostra de onde veio cada número abaixo.

Seis dimensões, ambos os lados

Tudo o que separa as versões está nestas seis linhas. O lado esquerdo é o Pareto 26.10 Preview; o direito é a versão Pareto de 17 de setembro, aquela que o texto do catálogo da prévia chama de escolha estável.

• Janela de contexto — 1.048.576 tokens vs 262.144 tokens. Quatro vezes mais espaço, no papel, sem nenhum nível menor oferecido em nenhum dos dois.
• Saída máxima — 131.072 tokens vs 131.072 tokens. Inalterado. A janela maior não trouxe uma resposta maior.
• Preço de entrada, conforme roteado — $0,80 por milhão vs $2,50 por milhão. É aproximadamente um terço do preço nessa listagem.
• Preço de saída, conforme roteado — $3,20 por milhão vs $7,50 por milhão. Menos da metade.
• Entrada em cache, conforme roteado — $0,03 por milhão vs $0,25 por milhão. As trajetórias de agente mais longas ganham mais aqui.
• Planilha de benchmark publicada — quatro pontuações, explicitamente "preliminares" e "podem mudar antes da publicação final" vs nenhuma tabela de benchmark publicada.

Duas dessas linhas são as que decidem o trabalho real. A janela de contexto é a manchete que o fornecedor não vai declarar em seu próprio site — ela fica na listagem, não na ficha do modelo —, e o preço de entrada em cache é o que muda a conta de um agente, e não seu teto. Todo o resto é ou um delta de marketing ou, no caso da pontuação de saída, uma admissão: publicar os números de uma prévia com o rótulo "preliminar" é mais honesto do que a alternativa, e também é um aviso.

O preço que você vê depende de onde você olha

Coloque as duas tabelas de tarifas lado a lado e elas não se conciliam, o que é a parte desta comparação que ninguém explicou.

A própria plataforma da Unbiased, no dia em que o 26.10 Preview se tornou a versão atual, ainda lista US$ 2,50 por milhão de entrada, US$ 0,25 em cache e US$ 7,50 de saída. Esses são os números de setembro, inalterados, tanto na página de preços quanto no cartão do modelo. O conjunto mais baixo — US$ 0,80, US$ 0,03, US$ 3,20 — aparece na listagem do catálogo roteado para o mesmo preview. Portanto, um cliente que chama pareto diretamente pela API do fornecedor paga os preços do cartão antigo pelo novo modelo, enquanto a listagem roteada anuncia cerca de um terço disso. Ambos estão no ar. O fornecedor não publicou nenhuma data de término promocional nem nenhuma declaração que os concilie.

Isso é uma questão de canal e, numa versão de pré-visualização, é também uma questão de timing: seja qual for o número em que basear os seus custos, o outro está a uma nota de lançamento de distância de se tornar o correto. Um router que repassa o preço de tabela de um fornecedor com 0% de margem elimina exatamente esta fricção — uma alteração de preço do fornecedor entra em vigor no próprio dia, em vez de na próxima revisão de contrato — e é essa a única coisa estrutural que vale a pena ir buscar à OrcaRouter aqui. Não temos hoje nenhum dos lançamentos da Unbiased, por isso a resposta direta a "onde é que eu chamo isto" é a própria API da Unbiased, seja qual for dos dois conjuntos de preços que a listagem através da qual compra tiver. A razão para o dizer em voz alta é que a diferença é de um fator de três, e uma pré-visualização não é o sítio para descobrir que escolheu o preço errado.

O que a pré-visualização te traz, e o que ela te custa

A própria descrição do catálogo do preview estabelece os termos: ele "pode mudar sem aviso", e quem precisa de comportamento previsível é remetido de volta à versão de setembro. Isso não é texto padrão — é a definição do produto. Compare isso com o formato prático de uma longa sessão de agente e o trade-off se torna concreto.

Um agente que mantém uma conversa a decorrer acumula contexto, e é nas conversas longas que o cache de prompts compensa. Um modelo alterado por trás de um endpoint inalterado é a forma clássica de o perder: a cache tem como chave o modelo que produziu os tokens, pelo que uma troca silenciosa de versão a meio de uma trajetória pode invalidar o que tinha em cache e voltar a cobrar por trabalho que pensava já estar pago. A própria documentação da Unbiased defende este ponto no sentido oposto — posiciona a sua combinação como estável em cache, ao passo que um router que alterna não o é —, pelo que este é um risco que o fornecedor compreende bem e está simplesmente a aceitar em troca de lançar uma preview. Vale a pena assinalá-lo porque a falha é invisível num painel: os tokens continuam a ser cobrados, as respostas continuam a chegar, e o número é apenas maior do que na semana passada.

O lado positivo do preview é real e espelha o negativo. Quatro vezes o contexto, entrada em cache a um oitavo da tarifa da versão estável na listagem roteada, e uma folha de benchmark, ainda por cima — a versão de setembro nunca teve pontuações publicadas. Se sua carga de trabalho é de contexto longo e sensível a custo, o preview é o que você quer, e a forma de adotá-lo sem apostar toda a stack é fixá-lo deliberadamente: um endpoint nomeado para o preview, um endpoint nomeado para a versão estável, e um fallback entre eles configurado uma vez. A DSL de roteamento existe exatamente para esse tipo de problema — componha os dois como pernas separadas, envie uma fatia do tráfego real por cada uma, e deixe o log de requisições dizer quanto cada uma realmente custou. Um preview deve ser uma decisão que você pode reverter com uma linha de configuração, não uma propriedade do seu endpoint que você descobre pela fatura.

Um panorama de desempenho que não é estável o suficiente para ser confiável

Todos os números acima vêm da listagem pública, e o próprio painel de desempenho da listagem mudou entre leituras no dia do lançamento. Uma leitura da página do 26.10 Preview reportou uma latência mediana de 5,28 segundos e 35 tokens por segundo; uma visualização lado a lado publicada no mesmo dia reportou 3,54 segundos e 21 tokens por segundo para o preview e 1,05 segundo e 45 tokens por segundo para a versão de setembro. Essas não são discrepâncias pequenas. Um modelo totalmente novo servido por um único provedor tem uma base de medição pequena, e uma janela deslizante ao longo de horas vai variar.

A posição honesta é que nenhum dos lançamentos tem um número de throughput ou latência estável o suficiente para se planejar com base nele e, no caso do preview, isso é intrínseco ao produto, e não um problema de snapshot. O lançamento de setembro pelo menos já teve semanas de tráfego — sua listagem mostra disponibilidade de vários dias na casa dos noventa e poucos por cento, com um histórico completo de provedor por trás. O preview tem horas. Se o seu motivo para escolher entre eles é velocidade, e não preço ou contexto, as evidências para escolher ainda não existem, e a atitude responsável é medir com seus próprios prompts em vez de ler um número em qualquer uma das páginas.

Qual deles ligar, e como parar de se importar

Use a prévia se o seu trabalho envolve contextos longos, é sensível a custos e pode ser avaliado — sessões de agentes, processamento em lote, qualquer coisa em que quatro vezes a janela e um terço do preço de entrada compensem o risco de uma mudança no meio da semana. Trate-a como um teste com uma linha de configuração por baixo, e guarde os seus próprios números, porque os do fornecedor vão mudar.

Chame o Pareto estável se sua carga de trabalho for de produção, sensível à latência ou coberta por uma revisão de conformidade que não quer um modelo descrito como possivelmente sujeito a mudanças sem aviso prévio. Você abre mão da janela de 1M, do cache mais barato e das pontuações publicadas; você mantém um endpoint com histórico comprovado e um nome que significa a mesma coisa na próxima semana. Para muitas equipes, isso é o requisito inteiro.

O erro é tratar isso como um fork permanente. A Unbiased criou a divisão para ser temporária — a prévia existe para ser avaliada e depois absorvida — e a decisão que importa não é qual das duas você escolhe, mas se alternar entre elas é uma mudança de cinco minutos ou um projeto trimestral. Em um único endpoint com uma única string de modelo, atualmente não é nem uma coisa nem outra: é um anúncio que você precisa acompanhar. Em vez disso, configure a escolha como uma decisão de roteamento, e a versão que você chama se torna um botão, que é a única postura que uma versão de prévia realmente já recompensou.