O modelo que não escreve também lê pouco
Em 12 de outubro de 2026, a Subquadratic lançou o SubQ Snap, um modelo de decisão que aceita até 384 mil tokens de texto e imagem em uma chamada (Subquadratic, Introducing SubQ Snap). No mesmo anúncio, a empresa afirma que os modelos de decisão de hoje param em 32 mil tokens.
Para a Subquadratic, quem para em 32 mil decide sem a maior parte do que precisaria ver. A promessa do Snap é ler de uma vez um repositório de código ou um contrato com os anexos.
Fiquei animado com o anúncio, e o motivo passa longe do placar. Os números deste texto sobre o Snap e o Jev vêm todos da Subquadratic, e eu leio cada um como alegação de quem vende.
O que me animou foi o problema que o lançamento expõe. Um modelo que não escreve ainda precisa ler.
O analfabeto resolveu metade da conta
Escrevi sobre o Jev, da TypeSafe, em Jev, o modelo analfabeto. Um modelo de decisão recebe um contexto, uma pergunta e uma lista fechada de respostas. Em vez de escrever um texto, devolve uma probabilidade para cada resposta.
O apelido vinha daí: o Jev não escreve. Fechei aquele texto perguntando por que estamos pedindo texto a um modelo quando o sistema só precisa de uma decisão.
A pergunta continua boa. Ela só olha para um lado da chamada.
Toda chamada a um modelo tem dois custos. O de ler é processar a entrada inteira antes de qualquer resposta. O de responder é produzir a saída, que num LLM comum é texto gerado token a token.
O modelo de decisão praticamente zera o segundo, porque não gera texto. O primeiro fica onde estava. O anúncio do Snap diz isso sem rodeio: tirar a geração remove o custo da saída e mantém o de ler a entrada (Subquadratic).
A tabela de preços conta a mesma história. O Snap cobra US$ 0,05 por milhão de tokens de entrada e nada pela saída.
Sobrou a leitura.
Escolher pode exigir ler o repositório
Resposta curta não garante contexto curto. A escolha entre três ferramentas pode depender de evidência espalhada por um repositório inteiro ou por um histórico longo de interações. O anúncio lista outros casos: a restrição que o usuário deu 40 turnos atrás, a função definida em outro módulo e a cláusula que está em outro documento (Subquadratic).
É aí que a conta aperta.
No contexto longo, a leitura corrói a economia que o modelo de decisão fez ao não escrever. A Subquadratic diz que é por isso que os modelos de decisão ficaram nos 32 mil tokens.
Quem precisava decidir sobre um repositório ou um contrato inteiro tinha duas saídas:
- Ler tudo: mandar o material inteiro em uma chamada e pagar a conta maior, em tempo e em dinheiro;
- Reduzir a entrada: truncar, resumir, recuperar só os trechos que parecem relevantes ou fatiar o texto em pedaços, o chunking.
A segunda saída esconde uma decisão. Truncar, resumir, recuperar e fatiar escolhem, antes do modelo, o que ele vai ver e o que não vai (Subquadratic). E cada corte perde de um jeito. O truncamento pode levar embora a restrição dita 40 turnos atrás. A recuperação pode deixar de fora a evidência relevante. O resumo pode apagar o detalhe que só depois se mostra importante.
O modelo de decisão decide sobre o que sobrou. A primeira decisão do fluxo já foi tomada, e quem tomou foi o corte.
O Snap é a aposta numa terceira saída: ler tudo sem pagar a conta maior. E o que sustenta a aposta se chama Subquadratic Sparse Attention (SSA). A empresa afirma que, com ela, o custo da atenção cresce de forma linear com o contexto, e explica a ideia em How SSA Makes Long Context Practical.
O Jev fez a prova com o livro rasgado
O teste que mais me interessou no anúncio se chama Decision LCR. A Subquadratic adaptou um benchmark de contexto longo da Artificial Analysis: 100 perguntas escritas por pessoas sobre conjuntos de documentos reais, cada conjunto com 72 mil a 115 mil tokens. As perguntas viraram decisões de múltipla escolha (Subquadratic).
Nenhum conjunto cabe em 32 mil tokens. O Snap leu cada um inteiro, em uma chamada, e o Jev leu em chunks. O resultado: o Snap marcou 74,0 lendo os documentos inteiros, e o Jev, 48,0 lendo em pedaços.
São 26 pontos. Para ter a escala: sem documento nenhum, os modelos marcam entre 24 e 25 nesse teste, e o chute puro dá 19,2.
Só que esse número mede duas coisas de uma vez. Uma é a diferença entre os dois modelos. A outra é a diferença entre ler tudo e ler fatiado. O teste não separa uma da outra.
O anúncio também não descreve como os documentos foram fatiados para o Jev, nem como as respostas dos pedaços viraram uma decisão só. Outro fatiamento poderia dar outro placar.
Por isso não leio os 26 pontos como prova de que o Snap raciocina melhor. Leio como um indício do que se perde quando alguém corta o texto antes de o modelo decidir. E quem escolheu a tesoura foi a concorrente do Jev.
No contexto curto, a distância é bem menor, ali o Snap marca 61,7 e o Jev, 57,9.
As duas réguas são diferentes, e não dá para subtrair uma da outra. Ainda assim, a vantagem grande aparece justamente onde um dos dois precisou cortar a entrada.
O placar também tem derrota. Em 16 testes do Decision Index que a empresa associa a fluxos corporativos, o Snap lidera em 13. Dos três que perde, dois são por menos de 2 pontos. O terceiro é o When2Call: 67,0 contra 74,6 do Jev.
Esse teste mede uma decisão: chamar a ferramenta, perguntar, responder ou recusar. O anúncio desenha quatro papéis para o Snap dentro de um agente. O primeiro é o de roteador, que decide entre chamar uma ferramenta, perguntar ao usuário ou responder direto.
Antes de levar esse placar para uma decisão de arquitetura, eu anotaria quatro ressalvas:
- Quem mediu: todos os números vêm do anúncio da Subquadratic, e o teste de contexto longo foi adaptado por ela;
- Custo linear: é a alegação da empresa para o SSA;
- Acesso: o Snap está em prévia pública, com capacidade limitada, e a empresa avisa que pode abrir lista de espera;
- Calibração: no post do Jev, cobrei que a confiança do modelo fosse testada nos dados de quem adota, isso não muda aqui.
Nenhuma dessas ressalvas derruba a ideia. Elas mudam o que eu faria com ela.
Antes de escolher o modelo, conte o que ele precisa ler
Ao desenhar uma etapa de decisão, eu começaria por duas contas: onde está a evidência e quanto dela chega ao modelo.
Se a evidência cabe na janela do modelo de decisão que você já usa, o que escrevi no post do Jev continua valendo. Classifique antes de gastar e confira a calibração nos seus dados.
Quando ela não cabe, existe um corte antes do modelo, e esse corte já é uma decisão. Trocar de modelo é agora mais uma opção.