Card de título frente a frente com um selo “CARA A CARA”, a chamada “DOIS LANÇAMENTOS, UMA LINHA DE PRODUTO”, o título “Pareto 26.10 vs 26.9”, o subtítulo “Um número os separa, e não é uma pontuação.”, chips com os textos “Ambos executados pelo fornecedor”, “Ambos com pesos fechados” e “Um único provedor de serving”, e três cards com os textos “Contexto: 1.048.576 vs 262.144 tokens”, “DeepSWE v1.1: 69,9% vs 70,0%” e “Preço: US$ 0,80 de entrada / US$ 3,20 de saída em ambos”.
Guides & Insights

Pareto 26.10 vs Pareto 26.9: Um número separa estas duas versões

Autor

Rowan Sterling

Data de publicação

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

Comparando Pareto 26.10 com Pareto 26.9 é, em grande parte, um estudo sobre coisas que não mudaram. Mesmo fornecedor, mesma arquitetura composta, mesmo limite máximo de resposta de 131,072 tokens, mesmos cinco parâmetros declarados, mesmas tarifas publicadas na própria página de preços do fornecedor e — no único benchmark que ambas as versões compartilham — uma diferença de um décimo de ponto a favor do modelo mais antigo. Nos aspectos em que as pessoas costumam comparar modelos, estes dois são o mesmo produto vestindo números de versão diferentes. Em um aspecto, não são, e é esse aspecto que decide quais cargas de trabalho podem usar qualquer um dos dois: a janela de contexto, em que 26.9 oferece 262,144 tokens e 26.10 oferece 1,048,576. As falhas de IA e os incidentes com agentes documentados por trás de lançamentos como este estão reunidos em the OrcaRouter AI Incident Archive onde cada entrada traz suas próprias fontes, severidade, grau de confiança e indicador de contestação.

Ambas estão no ar. A versão pareto-26.10 é a que se tornou o padrão por trás do alias pareto em 15 de outubro de 2026, quando a Unbiased transferiu para ela sua versão de disponibilidade geral; a pareto-26.9 é a versão de setembro que o fornecedor diz que “permanece disponível” para quem quiser ficar. É essa a decisão inteira diante de quem liga hoje, e o restante desta página é o detalhe por trás dela.

Os fatos circunstantes

Ambos os modelos estão documentados como aceitando entrada de texto e imagem e retornando texto, e nenhum deles publica um identificador no Hugging Face — os pesos são fechados em ambos os lados desta comparação, portanto não há nada para baixar e hospedar por conta própria. Nenhum dos dois tem um benchmark independente. Ambos são servidos por um único provedor, a própria Unbiased, o que significa que não há um segundo host para o qual alternar em caso de falha dentro da própria stack do fornecedor para nenhum dos lançamentos. A comparação abaixo, portanto, é entre duas configurações de uma única linha de produto de um único fornecedor, e não entre dois ecossistemas.

O contexto é o argumento inteiro.

Um aumento de contexto de 4× parece uma linha de ficha técnica até você relacioná-lo com o que as pessoas realmente fazem com modelos de contexto longo.

Com 262.144 tokens, uma sessão de agente em repositório completo, uma transcrição longa de suporte ou uma thread de pesquisa de várias horas é um problema de chunking. Você recupera, resume, mantém uma janela deslizante e aceita que o modelo vê uma reconstrução da tarefa, e não a tarefa. Com 1.048.576 tokens, essas cargas de trabalho cabem — nem sempre com conforto e não de forma barata, a US$ 0,80 por milhão de tokens de entrada sem acerto de cache, mas cabem. A diferença prática entre as duas versões é se o seu pipeline precisa de uma camada de recuperação entre os seus dados e o modelo.

Essa é uma decisão de engenharia de verdade, e também é a única nesta página com uma resposta defensável. Todo o resto é próximo o bastante para que a escolha deva se basear em algo que não seja a qualidade.

Lado a lado, dimensão por dimensão

• String do modelo — pareto-26.10 (padrão por trás do pareto desde 2026-10-15) vs. pareto-26.9 (mantido, não padrão).

• Janela de contexto — 1.048.576 tokens vs 262.144 tokens.

• Resposta máxima — 131.072 tokens em ambos. Inalterado entre versões.

• Modalidades — texto + imagem na entrada, texto na saída, em ambos.

• Parâmetros declarados — max_tokens, temperature, top_p, tools, tool_choice na 26.10; o mesmo conjunto, além de response_format, na 26.9.

• Chamada de ferramentas — tool_choice restrito a auto no 26.10; o modelo decide se deve chamar, você não pode forçá-lo.

• Pesos — fechados em ambos; nenhum identificador do Hugging Face em nenhum dos registros.

• Prestadores de serviços — um, o fornecedor, em ambos.

• Preço publicado — US$ 0,80 de entrada / US$ 0,03 em cache / US$ 3,20 de saída por milhão em ambos, conforme a página de preços atual do fornecedor.

DeepSWE v1.1 — 69,9% a US$ 0,24 por tarefa em 26.10 vs 70,0% a US$ 0,29 por tarefa em 26.9, ambos realizados pelo fornecedor.

Duas dessas linhas merecem um parágrafo próprio, porque são justamente as que costumam ser mal interpretadas.

A two-column comparison scoreboard titled “Pareto 26.10 vs Pareto 26.9 — the scoreboard”. The left column, Pareto 26.10, lists context 1,048,576 tokens, max response 131,072 tokens, price per million $0.80 / $3.20, DeepSWE v1.1 69.9% at $0.24 per task, response_format not declared, and default behind pareto: yes, since Oct 15. The right column, Pareto 26.9, lists context 262,144 tokens, max response 131,072 tokens, price per million $0.80 / $3.20, DeepSWE v1.1 70.0% at $0.29 per task, response_format declared, and default behind pareto: no, retained. A footer reads “Vendor-reported figures; the 26.9 DeepSWE run used a 30-task slice. No independent benchmark for either release.”

A diferença de saída estruturada que ninguém anuncia

As listas de parâmetros não são idênticas. O registro de catálogo do 26.9 declara response_format entre seus parâmetros suportados; o registro do 26.10 não. A superfície declarada do 26.10 é max_tokens, temperature, top_p, tools e tool_choice, ponto final.

Leia isso com atenção, em vez de como uma manchete: a ausência de um parâmetro em uma lista declarada não é prova de que o endpoint o rejeite, e a própria documentação da API do fornecedor não enumera nenhuma das duas listas. Mas, se seu pipeline depende de saída em modo JSON ou restrita por schema, e você está migrando de 26.9 para 26.10 presumindo que a versão mais nova é um superconjunto estrito, essa suposição não é sustentada por nada publicado. Teste com seu próprio tráfego antes de migrar, ou planeje validar a saída no lado do cliente. É uma coisa pequena que vira um incidente numa terça-feira.

Duas tabelas de tarifas em vigor discordam sobre quanto custa 26.9

Esta é a parte mais confusa da comparação e a que tem maior probabilidade de afetar uma decisão real.

A Unbiased publica uma única tabela de preços — US$ 0,80 de entrada, US$ 0,03 de entrada em cache, US$ 3,20 de saída — e não a versiona por lançamento. Lido ao pé da letra, isso significa que 26.10 e 26.9 custam o mesmo por token hoje, o que torna a migração gratuita e o aumento de contexto a única variável. Enquanto isso, o próprio registro técnico de listagem do modelo ainda traz os números de setembro para o 26.9: US$ 2,50 de entrada, US$ 0,25 em cache, US$ 7,50 de saída. Ambas as fontes estavam no ar quando isto foi escrito. Nenhuma delas tem data, e o fornecedor não publicou nenhuma entrada de changelog explicando a mudança, então não há nenhuma linha citável de "neste dia o preço caiu" em lugar algum do registro.

A orientação prática é prosaica. Considere o cartão inferior, porque duas das três interfaces que você consegue consultar o publicam e uma delas é a página sobre a qual o cliente é cobrado — depois, confira novamente antes de definir um número no orçamento. Se você estiver fixando qualquer uma das versões para atribuição de custos, saiba que um mês misto que abranja a transição de 15 de outubro não será decomposto de forma limpa a posteriori, porque as versões tinham preços diferentes em momentos diferentes e o fornecedor não data suas mudanças.

Uma pontuação, um décimo de ponto e nada a concluir.

O único benchmark em comum entre ambas as versões é o DeepSWE v1.1, e os números do próprio fornecedor colocam a 26.9 em 70,0% e a 26.10 em 69,9%. Ambos os valores foram obtidos pelo fornecedor, sendo o mais antigo em um recorte de 30 tarefas, e não no conjunto completo de avaliação, e toda a comparação é descrita pela Unbiased como não validada de forma independente.

A leitura honesta é que esta medição não distingue as versões. Um décimo de ponto num recorte parcial de tarefas está dentro do ruído de uma única execução, e tratá-lo como um ranking em qualquer direção — "26.10 regrediu" ou "26.10 é melhor porque é mais barato por tarefa" — é ler folhas de chá. Os números de custo por tarefa divergem mais (US$ 0,24 contra US$ 0,29), e mesmo esses vêm de execuções em meses diferentes num modelo combinado cuja composição subjacente o fornecedor não divulga.

O que a planilha de fato lhe diz é onde não olhar. Se você está escolhendo entre esses dois com base em qualidade, está escolhendo com base em um número que não consegue sustentar a escolha. As evidências que os separam são arquiteturais — a janela de contexto e a superfície de parâmetros — e ambas são verificáveis de um modo que as pontuações não são.

A vendor model card for Pareto 26.10 from Unbiased's own site, showing a paired bar chart of the DeepSWE v1.1 score and cost per task for Pareto 26.10 against the earlier release: 69.9% at $0.24 per task versus 70.0% at $0.29 per task, with the note “Preliminary comparison.” beneath the chart.

Qual chamar, por carga de trabalho

• Codificação agêntica sobre um repositório completo — 26.10. A janela de 1M é a diferença entre enviar o repositório e enviar um resumo dele.

• Análise de documentos longos ou transcrições longas — 26.10, pelo mesmo motivo, e fique de olho na conta de entrada: 1M de tokens sem acerto de cache custa US$ 0,80 por solicitação apenas de entrada.

• Pipelines de saída em modo JSON ou restritos por esquema — 26.9 até você mesmo testar o comportamento da 26.10, porque a lista de parâmetros declarada da 26.9 inclui response_format e a da 26.10 não.

• Uma carga de trabalho já em produção e que cabe dentro de 262K — 26.9. Não há evidências publicadas de que migrar melhore o resultado, e fixar é a decisão mais econômica.

• Qualquer coisa em que você queira o padrão atual do fornecedor sem manter uma versão fixada — 26.10, via o alias pareto simples, com o entendimento de que o alias segue o calendário do fornecedor em vez do seu.

Para equipes que operam os dois lados de um ciclo de build e verificação, o padrão útil é fixar o 26.10 para a passagem de contexto longo e manter o 26.9 disponível como braço de comparação — que é exatamente para isso que serve uma camada de roteamento. O OrcaRouter não oferece nenhum modelo Unbiased, então ambas as strings são chamadas pela API do próprio fornecedor; o que oferecemos é uma chave e uma integração para os modelos que você compararia o 26.10 com, então avaliar a troca não significa assinar um segundo contrato. O OrcaRouter repassa o preço de tabela do fornecedor diretamente, com 0% de markup, o que é uma afirmação sobre os modelos que servimos, não sobre este.

The OrcaRouter models catalogue page in English, with the search field and model list visible, showing the breadth of the routed catalogue, none of which includes an Unbiased model.

A migração que ninguém agendou

O motivo de esta comparação ser prática e não acadêmica é que a mudança já aconteceu com pessoas que não a solicitaram. Em 15 de outubro, o alias pareto passou da versão de setembro para a 26.10. Qualquer pessoa que chamasse a string pura recebeu uma janela de contexto quadruplicada e uma superfície de parâmetros diferente sem alteração no código — e, como a documentação do fornecedor observa que identificadores de modelo desconhecidos não são rejeitados, um pin com erro de digitação ainda é servido e cobrado como Pareto em vez de falhar de forma explícita.

Se você estava na string de preview, esse caminho está fechado: a Unbiased disse aos usuários de preview para migrar para pareto ou pareto-26.10. Se você estava no pareto e presumiu estabilidade, essa suposição agora está visível nos seus próprios logs, tenha ela causado um problema ou não.

De qualquer forma, a correção é a mesma e leva uma linha: nomeie a versão que você testou. Uma string qualificada por versão é o que torna um modelo de custo subtraível e uma regressão atribuível, e é o único mecanismo que este fornecedor oferece para qualquer um dos dois.

O que ainda não está verificado

Nenhum dos dois lançamentos tem um benchmark independente. O Artificial Analysis não mantém uma página para nenhum dos dois, e nenhum avaliador publicou uma reexecução do harness do fornecedor. Cada número nesta comparação — as quatro pontuações, os números de custo por tarefa, as janelas de contexto — é ou publicado pelo fornecedor ou lido do registro técnico de listagem do modelo, e as pontuações especificamente carregam os próprios rótulos do fornecedor de “preliminar” e “não validado de forma independente”.

Isso não é motivo para evitar nenhum dos dois modelos. É motivo para decidir sobre as coisas que são verificáveis: se sua carga de trabalho se encaixa em 262K, se seu pipeline precisa de response_format e se você quer estar no alias ou em um pin. Essas três perguntas têm resposta. Qual modelo é melhor não tem, e nenhuma quantidade de leitura da ficha publicada vai produzir uma.