Preços do OpenRouter explicados: custos, taxas de recarga e BYOK

Para planejar um orçamento preciso no OpenRouter, é necessário separar o custo das requisições processadas do valor antecipado que você adiciona ao saldo da sua conta. Além disso, você precisa avaliar de forma independente as regras de BYOK (Bring Your Own Key) caso conecte suas próprias credenciais de API de um provedor. Uma única tarifa publicada “por milhão de tokens” não cobre todos esses componentes financeiros.

Preço do modelo e recarga de créditos são itens separados

De acordo com a FAQ oficial, o valor das requisições é debitado do seu saldo de créditos pré-pagos, com tarifas determinadas pelo modelo e provedor subjacentes. O OpenRouter declara repassar os preços dos provedores sem margem adicional sobre a inferência; a comissão da plataforma incide na compra de créditos. Na página de preços em 14 de setembro de 2026, a taxa indicada para o Pay-as-you-go é de 5.5%.

Antes de concluir qualquer pagamento, compare três valores distintos: a quantidade de créditos que você receberá, a taxa exibida e o valor final cobrado no seu método de pagamento. Verifique o cálculo em tempo real no checkout para conferir eventuais taxas mínimas por transação, impostos aplicáveis ou sobretaxas da forma de pagamento. Uma porcentagem descrita na tabela de preços não substitui o total final do checkout.

Considere um exemplo hipotético: se a compra de $100 em créditos tiver o acréscimo de uma taxa da plataforma de 5.5%, o pagamento total será de $105.50. Trata-se de uma ilustração aritmética sem impostos, conversão de moeda e encargos de processamento — não de uma captura exata de checkout. Após consumir $20 em créditos, o saldo restante será de $80; você não pode atribuir todo o pagamento inicial como o custo dessas primeiras requisições.

Como estimar sua carga de trabalho real

Para um cenário padrão de geração de texto sem prompt caching ou recursos faturáveis adicionais:

request_cost = input_tokens / 1000000 * input_price
             + output_tokens / 1000000 * output_price

Tomemos uma tarifa real do BetterToken para glm-5.3 no grupo GLM, verificada em 14 de setembro de 2026 no catálogo de preços atual. Em dólares americanos por milhão de tokens, a entrada custa $1.232 e a saída custa $3.872. Para 8.000 tokens de entrada não armazenados em cache e 2.000 tokens de saída, o cálculo é:

input_cost = 8000 / 1000000 * 1.232 = $0.009856
output_cost = 2000 / 1000000 * 3.872 = $0.007744
total_cost = $0.0176
1000_requests = $17.60

O BetterToken não adiciona taxa de transação extra a esse total: para esse volume, o custo permanece em $0.0176 por requisição ou $17.60 para mil requisições idênticas. Não é necessário multiplicar esse montante por 1.055 — as taxas de recarga do OpenRouter não se aplicam ao BetterToken. As quantidades de tokens neste cenário são ilustrativas; o preço foi extraído diretamente do catálogo ativo, e não de um modelo hipotético. Tokens em cache e chamadas de ferramentas adicionais não estão incluídos nesse valor. Este cálculo serve como exemplo para o BetterToken, não como comparação direta com o preço do GLM-5.3 no OpenRouter.

Para transformar esse cálculo em um orçamento operacional prático, meça o tamanho real das requisições, incluindo o histórico completo de conversas e as instruções de sistema. Acompanhe separadamente consultas curtas e processamentos de contexto longo. No caso de agentes autônomos, some todas as chamadas intermediárias necessárias antes da aceitação do resultado final, em vez de orçar apenas a resposta conclusiva. Qualquer repetição causada por uma resposta insatisfatória também precisa constar nos seus registros de despesas caso tenha gerado uma chamada de API faturável.

Prompt caching, entradas de imagens, tokens de reasoning e cobranças adicionais por requisição podem alterar os cálculos de custo: confira as unidades de cobrança específicas no cartão do modelo. O consumo é auditado pelos logs de Activity. Para comparar com o BetterToken, consulte a respectiva página de preços e seus próprios registros no Workspace, onde o modelo, as quantidades de tokens e as despesas ficam visíveis. Compare sempre a mesma carga de trabalho e as mesmas unidades de cobrança; a simples observação de duas tabelas de tarifas distintas não prova qual caminho é mais econômico.

Acesso ao nível gratuito não significa taxa de transferência ilimitada

A página de preços indica um limite de 50 requisições por dia para o plano gratuito. Essa cota não é uma garantia ampla de serviço para qualquer tipo de conta ou rota paga de fallback. A documentação de limites diferencia limites de gastos de limites de frequência de requisições: o erro HTTP 402 exige a checagem do saldo da conta e do limite da chave de API, enquanto o código de status HTTP 429 pode se originar tanto da plataforma OpenRouter quanto do provedor upstream.

Ao se deparar com um HTTP 429, examine o corpo da resposta e o cabeçalho Retry-After, se estiver disponível, e adote intervalos de espera (backoff) entre as tentativas. Não crie loops de repetição ilimitados. Se as suas regras de roteamento fizerem fallback para um modelo pago, inclua os custos desse modelo no orçamento antes da ativação. Embora a rota gratuita seja útil para testar a compatibilidade, fluxos em produção exigem uma estratégia operacional clara para o esgotamento de limites ou falhas de serviço.

BYOK: confira ambas as faturas

O BYOK (Bring Your Own Key) permite rotear requisições pelo OpenRouter usando sua própria chave de API do provedor upstream. De acordo com a página de preços em 14 de setembro de 2026, o Pay-as-you-go inclui até $25.000 mensais em inferência a preço de tabela sem taxa de BYOK, aplicando-se 5% após esse teto. Esse montante representa um limite monetário para isenção de taxas — não é uma cota de requisições gratuitas nem uma promessa de que o OpenRouter pagará a fatura do seu provedor upstream.

A gestão de chaves é realizada na interface de BYOK do workspace. Conforme a documentação de BYOK, o envio de requisições segue uma ordem rígida: o tráfego prioriza as chaves prioritárias configuradas (Prioritized keys), migra para os endpoints compartilhados do OpenRouter (shared OpenRouter endpoints) se necessário e, por fim, encaminha para chaves de reserva (Fallback keys), respeitando filtros de modelos e regras de roteamento. O fallback para a capacidade compartilhada consome créditos do OpenRouter. Além disso, os orçamentos do workspace e os limites de proteção (guardrail budgets) excluem os gastos com BYOK por padrão; se desejado, eles podem ser ativados por meio da opção “Include BYOK spend”.

Para configurar e validar seu fluxo de BYOK, siga esta sequência:

1. Verifique permissões e filtros: confirme se a chave de API do provedor possui as permissões de modelo necessárias e defina os filtros de modelo correspondentes no OpenRouter.
2. Defina as políticas de prioridade de chaves: estabeleça a ordem de uso das chaves e se as requisições têm permissão para transbordar para endpoints compartilhados do OpenRouter ou Fallback keys.
3. Separe as alocações de orçamento: planeje os limites de forma independente — um diretamente no provedor upstream e outro no seu saldo do OpenRouter para cobrir a capacidade de fallback ou as taxas de BYOK após ultrapassar o teto de isenção.
4. Execute uma única requisição de teste: envie uma chamada limitada, abra o log de Activity para acessar View Raw Metadata, verifique o bloco provider_responses e cruze os dados com as faturas reais do seu provedor. Nunca suponha que o rastreamento automatizado de custos corresponda com perfeição às faturas upstream sem uma conferência direta.

Se uma única API direta atende às suas necessidades operacionais, compare a fatura mensal com o custo de rotear o mesmo volume de trabalho pelo OpenRouter. Se você precisa de redundância multimodelo ou roteamento dinâmico, considere a conveniência arquitetural do faturamento unificado e dos endpoints padronizados. Para uma avaliação inicial, um lote de testes pequeno e limitado é suficiente: o custo total por resultado aproveitado oferece muito mais clareza do que avaliar tarifas básicas de tokens isoladamente.