Quando o modelo diz não

Esta semana nosso relatório de erros sinalizou uma classe de recusas que não tínhamos previsto: em tópicos histórica ou politicamente sensíveis, a API do provedor do modelo responde com uma rejeição de política de conteúdo em vez de uma completion — mesmo quando a solicitação é claramente legítima. A recusa vem da camada do próprio provedor, não da nossa, e o usuário vê um corpo de erro bruto num idioma que quase certamente não lê.

Dois filtros, não um

Todo prompt no OnePress passa primeiro pela nossa própria triagem de entrada — uma exigência contratual do nosso processador de pagamentos, e uma exigência razoável. Essas solicitações passam por ela, corretamente: trabalho claramente legítimo é exatamente o tipo de tráfego que deveria passar direto.

A recusa vem de um segundo filtro que nem nós nem o usuário controlamos: a triagem de conteúdo em nível de plataforma do próprio provedor do modelo, que inspeciona o tráfego acima do modelo em si. Solicitações que tocam em assuntos politicamente sensíveis caem num território que a camada de conformidade de uma jurisdição trata como inseguro. A mesma solicitação é trabalho completamente comum em qualquer outro lugar.

A descoberta útil: o filtro não está no modelo

Esta é a parte que mudou nossa arquitetura. Enviamos uma solicitação similar nossa — a mesma classe de conteúdo — para os exatos mesmos pesos do modelo, mas servidos por um host diferente: OpenRouter, roteado para provedores de inferência nos EUA. Mesmos pesos, mesma classe de prompt. Geração completa, sem recusa.

Então a recusa nunca esteve no modelo. Ela vive na camada de serviço — o invólucro de conformidade que um provedor coloca em volta da sua API. O que significa que dá para rotear ao redor dela, de forma limpa e aberta, sem tocar no modelo.

O que mudamos

• Cada modelo agora existe duas vezes no seletor. O conjunto padrão roteia via OpenRouter para provedores de inferência fora da China continental; os mesmos quatro modelos continuam disponíveis nas suas APIs de origem, rotulados (CN), para quem preferir.
• As solicitações do OpenRouter carregam uma lista de permissões upstream. Fixamos as solicitações em provedores nomeados e desativamos o fallback — se a lista fixada não puder atender, a chamada falha ruidosamente em vez de cair silenciosamente num caminho filtrado.
• As recusas do provedor agora produzem uma mensagem legível. Uma recusa de política de conteúdo se explica em linguagem clara e aponta para o seletor de modelos — chega de blocos de erro brutos num idioma que o usuário não lê. Quadros de erro embutidos no meio do stream, que antes eram engolidos e pareciam uma resposta vazia, também passam a aparecer corretamente.
• As tarefas em segundo plano também migraram. A geração de títulos e resumos lê o mesmo conteúdo da conversa, então usa o mesmo endpoint do OpenRouter.

Os limites honestos

Dois compromissos que vale nomear. Primeiro, nem todo modelo tem um caminho sem filtro: o tier flash hospedado do Qwen só existe atrás do upstream da própria Alibaba, então o slot do Qwen no OpenRouter roda a variante de pesos abertos de 27B — um modelo diferente, e rotulamos isso honestamente. Segundo, fixar significa que uma lista de permissões totalmente indisponível devolve um erro em vez de degradar para um caminho filtrado. É uma escolha deliberada: uma falha visível vence uma mudança invisível de lugar.

O maior é filosófico. Para um produto internacional, o caminho padrão provavelmente não deveria herdar a linha editorial de nenhuma jurisdição específica — não porque o filtro seja malicioso, mas porque a definição de «sensível» foi escrita para outro público. Os padrões agora assumem o contexto do usuário, não o do provedor.