Tirei uma trava da minha IA e a resposta caiu de 5,5 s para 3,7 s.

Uma opção de retenção zero prendia toda a IA de um produto a um provedor que respondeu 1,8 s mais devagar que o melhor no meu teste. A configuração parecia pequena. O efeito aparecia em toda chamada.

Todos os meus produtos chamam modelos de IA pelo OpenRouter, que manda cada chamada para um dos provedores que servem aquele modelo. Isso me dá uma escolha a mais para investigar quando a resposta demora: olhar também para o caminho percorrido pela chamada.

A retenção zero fechou a escolha de provedor

Num produto que ainda não apresentei aqui, toda chamada enviava provider.zdr: true. Para o modelo da OpenAI que ele usa, só o Azure tinha endpoint com retenção zero, então todo o tráfego ficava preso no Azure, e a IA ficou lenta.

A lentidão parecia vir do modelo, mas a causa estava na restrição enviada na chamada. O nome do modelo permanecia igual em cada requisição, mas a exigência sobre o provedor reduzia as opções disponíveis ao roteador. Uma escolha feita na configuração passou a determinar o caminho de todas as respostas.

Esse detalhe importa quando se usa um roteador de modelos. Ter vários provedores disponíveis para um modelo não significa que todos estejam disponíveis para a configuração enviada. Cada restrição precisa ser considerada junto da chamada que a contém.

A comparação também precisava respeitar as mesmas condições para isolar o impacto da rota. O teste precisa manter o mesmo pedido, o mesmo modelo e o mesmo nível de raciocínio em cada tentativa. Mantive esses elementos iguais para comparar os tempos entre endpoints.

O mesmo pedido mostrou tempos diferentes

Em 6 de novembro, medi a mesma chamada com o GPT-6 Luna e raciocínio medium. O Amazon Bedrock respondeu em 3,7 s, o Azure em 5,5 s e a OpenAI direta em 7,0 s. O intervalo entre o Bedrock e o Azure foi de 1,8 s.

Ao enviar provider.sort: "throughput", o OpenRouter escolheu o Bedrock sozinho. A escolha acompanhou o objetivo da configuração: ordenar os provedores pela velocidade de processamento. No pedido medido, o caminho escolhido também foi o que teve o menor tempo entre os comparados.

O resultado mede aquela chamada específica, sem garantir que o mesmo provedor vença sempre. A utilidade do teste está em manter pedido, modelo e raciocínio iguais e observar o que muda ao trocar o provedor. Assim a comparação responde a uma pergunta direta sobre tempo de resposta.

Para repetir a medição em outro produto, comece pela chamada que parece lenta e confira quais restrições ela envia. Depois, compare os provedores disponíveis com a mesma entrada e a mesma configuração de modelo. Por último, teste o roteamento configurado para observar qual caminho o OpenRouter escolhe.

A configuração passou a priorizar velocidade

A decisão de 6 de novembro passou a valer para todos os meus produtos: nenhuma configuração que possa deixar a IA mais lenta. A regra fixa é não pedir retenção zero, não fechar a lista de provedores com provider.only e não ligar guardrail que restrinja provedor.

Toda chamada de texto envia provider.sort: "throughput". O esforço de raciocínio padrão é medium. A chamada prioriza a velocidade de processamento sem impor barreiras desnecessárias ao roteador.

Há uma exceção na configuração que pode permanecer: require_parameters: true. Ela retira endpoints que não aceitam a saída estruturada solicitada. Esses endpoints dariam erro, então mantê-los na seleção não resolveria o pedido.

As políticas de privacidade de cada produto passaram a citar o OpenRouter sem prometer retenção zero. O texto precisa acompanhar a configuração adotada. Uma promessa escrita para uma configuração anterior não deve continuar como descrição do comportamento atual.

A exceção fica no produto que precisar dela

A base de onde nascem os produtos novos já segue essa regra desde 7 de novembro, num registro de decisão chamado “OpenRouter: speed first”. Cada projeto que nasce dessa base já começa com a regra escrita.

Se um produto um dia precisar de retenção zero, a decisão será daquele produto. O código pede a condição em cada chamada, e as chaves dele recebem um guardrail com o nome do produto como segunda trava. A regra geral de velocidade permanece protegida no restante da operação.

O ganho desta investigação foi descobrir qual configuração estava fechando as opções antes de mudar o modelo. O roteador só pode escolher entre os caminhos que a chamada permite. Para entender como organizo as contas que sustentam essa operação, contei o padrão no post sobre Sentry, PostHog e OpenRouter.