OpenRouter

OpenRouter para quem conecta cartão: conta invadida

Minha conta no OpenRouter foi invadida e o invasor criou uma chave de API nova, sem minha autorização. O padrão de uso era completamente atípico, e ainda assim as cobranças no cartão seguiram normalmente. Em cerca de trinta minutos foram dez lançamentos no meu cartão de crédito, sem bloqueio, sem confirmação extra e sem nenhum alerta de segurança que impedisse o abuso. Considero o OpenRouter, por isso, uma plataforma insegura para quem mantém um meio de pagamento conectado à conta. Chave de API criada por invasor sem nenhuma confirmação O ponto que mais me incomoda não é apenas o acesso indevido, é a facilidade com que a chave de API foi criada. Quem entrou na minha conta emitiu uma credencial nova e passou a usar os modelos como se fosse o dono dela. Não houve confirmação por e-mail, não houve verificação adicional, não houve nenhum passo que atrasasse o ataque o suficiente para eu perceber o que estava acontecendo. Uma chave de API é o que libera o consumo faturável dentro da plataforma. Quando alguém consegue criá-la a partir de uma sessão já aberta, todo o resto do controle de segurança perde o sentido, porque o dano deixa de depender de descobrir uma senha e passa a depender só de gerar a credencial e começar a consumir. Foi exatamente o que ocorreu comigo, sem nenhum atrito. O que eu esperava de uma plataforma que guarda um meio de pagamento conectado era justamente o contrário: trava na criação de chaves novas a partir de um dispositivo ou de um local incomum, e um aviso claro para o dono da conta. Não recebi nada disso. A criação passou direto, o consumo passou direto e eu só fui entender depois. Dez cobranças no cartão em cerca de trinta minutos O consumo foi rápido e repetido. Em cerca de trinta minutos, dez cobranças separadas foram lançadas no meu cartão de crédito. Um padrão desse tipo, várias cobranças em sequência numa conta que nunca teve esse comportamento, deveria ser o exemplo clássico de anomalia que qualquer camada de antifraude identifica antes de continuar liberando transações. Nada foi bloqueado. Nenhuma das cobranças pediu confirmação, nenhuma etapa exigiu validação adicional e eu não recebi um alerta de segurança útil enquanto o gasto acontecia. Descobri o problema pelo extrato do cartão, não por um aviso da plataforma. Também não existiu limite temporário nem trava automática no momento em que o padrão ficou estranho. Como o cartão está conectado à conta, o prejuízo não fica restrito ao saldo de créditos, ele vai direto para o meio de pagamento. Para mim essa é a combinação mais perigosa que existe nesse tipo de serviço: credencial criada sem barreira de um lado e cobrança recorrente sem freio do outro. A atividade era completamente fora do meu perfil e mesmo assim seguiu até o fim. Cinco contatos com o suporte e nenhuma resposta Depois do estrago, tentei resolver pelo caminho normal. Entrei em contato com o atendimento cinco vezes e não recebi resposta em nenhuma delas. Não houve retorno útil, não houve prazo informado, não houve ninguém do outro lado explicando o que seria feito com as cobranças ou com a chave criada pelo invasor. Para uma plataforma que lida com dinheiro e com credenciais de acesso, o silêncio do suporte é o agravante que fecha a experiência. De que serve ter canal de atendimento se, no momento em que o problema é grave, ninguém responde? O prejuízo continua correndo e a sensação é de estar totalmente sozinho, sem conseguir nem contestar o que aconteceu. Minha conclusão prática é que o OpenRouter não é seguro para uso com forma de pagamento conectada. As travas de segurança não seguraram o abuso e o suporte não apareceu quando eu mais precisei. Se você usa a plataforma no dia a dia e mantém cartão cadastrado, esse risco precisa entrar na conta antes de continuar recarregando saldo. Depois de passar por uma invasão de conta, ver dez cobranças em cerca de trinta minutos e não ter retorno em cinco contatos com o atendimento, não consigo recomendar o OpenRouter para ninguém que mantenha um cartão vinculado. A plataforma pode até entregar acesso aos modelos, mas o que ficou para mim foi a ausência de controle quando o uso fugiu completamente do normal e a falta total de suporte no momento crítico.

Como o OpenRouter ignorou meu reembolso de créditos

Pedi o reembolso de 25 dólares em créditos no OpenRouter com menos de uma hora de uso e, mais de dez dias depois, continuo sem o dinheiro de volta e sem qualquer resposta do suporte. Os créditos estavam intactos, sem nenhuma chamada feita, e mesmo assim só recebi uma fatura genérica do Stripe dizendo que o reembolso havia sido processado. Não foi. Se você pensa em comprar créditos, pense dez vezes antes. O pedido de reembolso feito dentro de uma hora que não saiu do lugar Não usei praticamente nada da plataforma. Fiz a compra, vi que os créditos ficaram parados no saldo e, dentro de uma hora, já tinha aberto o pedido de reembolso pelos 25 dólares que havia colocado na conta. Os créditos estavam completamente intactos, sem nenhum consumo, o que deveria tornar o processo simples: bastava estornar no mesmo meio de pagamento. Não foi o que aconteceu. O pedido foi feito em 13 de julho de 2026 e, mais de dez dias depois, nada de estorno, nada de dinheiro de volta na conta. Para mim, o problema não é só o valor em si, é a quebra de confiança. Quem compra créditos no OpenRouter espera que uma solicitação feita imediatamente, com saldo não utilizado, seja resolvida sem discussão. Aqui aconteceu o contrário: a solicitação entrou, o saldo continuou sem uso e o reembolso simplesmente não apareceu. Contato com o suporte no mesmo dia e silêncio na resposta Contatei o suporte no mesmo dia em que pedi o reembolso, justamente para não deixar margem a dúvida sobre a data e sobre o fato de os créditos estarem sem uso. Não recebi resposta. Nem um retorno dizendo o que faltava para o estorno sair, nem um prazo, nem uma pessoa assumindo o caso. Passaram-se mais de dez dias e o silêncio continuou igual. Enquanto isso, a única coisa que chegou foi uma fatura genérica do Stripe indicando que o reembolso havia sido processado, o que não corresponde a nada do que vi do meu lado: o saldo não voltou, o valor não apareceu e ninguém explicou a diferença entre o que o documento diz e o que o extrato mostra. Um suporte que não responde transforma um pedido simples em um problema sem saída, e foi exatamente aí que percebi que não teria com quem resolver o caso pela via do diálogo. A fatura genérica do Stripe como única resposta ao pedido de estorno A fatura genérica do Stripe é, talvez, a parte mais frustrante de toda a história. Ela afirma que o reembolso foi processado, mas o dinheiro não chegou. Quando o único comprovante enviado contradiz o resultado real, o usuário fica sem ter a quem recorrer: não há retorno do suporte, não há prazo e não há estorno na conta. Pedi o reembolso de créditos que nunca foram usados, dentro de uma hora após a compra, e mesmo assim precisei ficar escrevendo para tentar recuperar o que é meu. Se você está pensando em colocar créditos no OpenRouter, pense dez vezes antes de comprar. A recomendação que dou é simples: não arrisque dinheiro em uma plataforma que não devolve saldo não utilizado e que não responde quando é chamada. Resumindo o que vivi: pedido de reembolso em 13 de julho de 2026, créditos intactos, contato com o suporte no mesmo dia e mais de dez dias de espera sem resposta e sem estorno. A fatura do Stripe diz que o reembolso saiu; o meu saldo diz o contrário. Para quem está avaliando comprar créditos no OpenRouter, fica o alerta, porque o risco de perder o valor sem uso é real e o caminho de volta é longo.

Recarga de saldo com OpenRouter: cobrança debitada sem crédito

Paguei US$ 55 em recargas no OpenRouter e não recebi nenhum crédito no saldo. Foram três pagamentos de US$ 15 e um de US$ 10 debitados com sucesso da minha conta, enquanto a própria plataforma seguia recusando a conclusão da recarga. Abri ticket de suporte duas vezes, recebi uma única resposta dizendo que estavam verificando e depois mais de um mês de silêncio absoluto. Essa é a minha experiência com cobrança debitada sem crédito. Cobrança debitada sem crédito: como a recarga de saldo falhou O processo deveria ser simples: eu adiciono saldo, a plataforma confirma o pagamento e o valor vira crédito disponível para uso. Na prática, cada tentativa de recarga terminava em rejeição de pagamento na tela do OpenRouter, mas o dinheiro saía da minha conta do mesmo jeito. Foram três pagamentos de US$ 15 e um de US$ 10, todos debitados com sucesso do meu lado, e nenhum deles apareceu como crédito no meu saldo. A plataforma falhava na etapa de confirmação, mas o débito acontecia no mundo real, na minha conta bancária. O que mais me incomoda é a assimetria. Se o pagamento não passa, o esperado é que nada seja cobrado, ou que a cobrança seja estornada automaticamente em seguida. Aqui aconteceu o contrário: a recusa aparecia para mim, o crédito nunca era lançado e o valor ficava com eles. Somando as quatro tentativas, são US$ 55 que saíram do meu bolso e não viraram saldo em lugar nenhum. Não estou falando de um bug cosmético de interface, estou falando de dinheiro debitado de uma conta real sem a contrapartida de crédito na plataforma. Como usuário há um bom tempo, eu já conhecia o produto e gostava dele. Justamente por isso a falha de cobrança não foi o que me afastou, e sim o que veio depois dela. Mais de um mês de silêncio no ticket sobre os US$ 55 Abri um ticket de suporte assim que percebi que o saldo não tinha sido creditado. Não obtive resolução e abri uma segunda vez, detalhando os valores e as tentativas. Recebi exatamente uma resposta, curta, dizendo que estavam verificando o caso. Depois disso, nada. Nenhum retorno, nenhum pedido de informação adicional, nenhuma confirmação de reembolso, nenhuma explicação técnica sobre por que o pagamento era recusado na plataforma e aprovado no meu cartão. Já se passou mais de um mês desde esse primeiro contato. Para uma plataforma que processa pagamentos de API e que portanto lida com o dinheiro das pessoas, esse tempo de silêncio não é aceitável. Uma falha de cobrança é compreensível, sistemas quebram. O que não se sustenta é ficar um mês sem responder sobre uma diferença de US$ 55 que está registrada do meu lado, com comprovante de débito, e simplesmente não ter retorno. O silêncio é pior do que o erro, porque ele tira qualquer previsibilidade. Eu não sei se o caso está na fila, se foi esquecido ou se ninguém está olhando. Um ticket que não anda transforma um problema de cobrança em um problema de confiança, e foi exatamente isso que aconteceu comigo. O risco de uma disputa de cobrança em aberto para quem depende da plataforma Uso o OpenRouter há um tempo e, no geral, gostava do produto. Essa experiência, porém, abalou seriamente minha confiança no suporte e na confiabilidade da cobrança. O motivo é simples: o tipo de problema que eu tive não é raro em termos de categoria, é uma recusa de pagamento. O que o torna grave é a combinação de débito efetivado, crédito ausente e ausência total de resposta por mais de um mês. Se você depende do OpenRouter para algo crítico para o negócio, vale levar isso em conta. Um problema de pagamento pode ficar parado por tempo indefinido, e enquanto ele está parado o seu saldo não existe, mesmo com o dinheiro já tendo saído da sua conta. Não existe prazo, não existe previsão e não existe um caminho claro de resolução além de abrir ticket e esperar. Não estou dizendo que o produto é ruim no uso diário, porque a minha experiência anterior era positiva. Estou dizendo que o momento em que eu precisei de suporte financeiro foi o momento em que a plataforma simplesmente não respondeu, e isso muda a forma como eu avalio o risco de continuar usando. No fim, o que eu queria era muito pouco: ou os US$ 55 virarem crédito, ou os US$ 55 voltarem para a minha conta, com uma explicação sobre o que deu errado na recarga. Não tive nem uma coisa nem outra. Por isso, não recomendo o OpenRouter enquanto o suporte não corrigir a responsividade em problemas de cobrança. A falha em si eu teria relevado; o mês inteiro de silêncio sobre o meu dinheiro, não.

OpenRouter: acesso a modelos open weight e pagamentos

O OpenRouter cumpre bem o papel de democratizar o acesso a modelos open weight, porque reúne muitas variantes de pagamento e de acesso em um só lugar. No meu uso, essa flexibilidade fez diferença para testar e trabalhar com modelos abertos sem depender de uma única forma de entrada. Quando surgiram alguns imprevistos, contei com o suporte de Chris Hughes, que entrou rápido, foi muito responsivo e ajudou a organizar as coisas. Acesso a modelos open weight com variantes de pagamento O ponto que mais me chamou atenção no OpenRouter é a possibilidade de reunir muitas variantes de pagamento e de acesso a modelos open weight. Na prática, isso significa que a entrada em modelos abertos não fica presa a um formato único de pagamento, e a variedade ajuda quem quer experimentar diferentes modelos sem refazer toda a configuração a cada tentativa. Para o meu uso, a flexibilidade é o centro da experiência, porque acesso e pagamento caminham juntos. Também vejo valor na maneira como o OpenRouter organiza essa democratização. O acesso a modelos open weight deixa de parecer um recurso distante e passa a fazer parte de uma rotina mais simples, com alternativas de pagamento disponíveis. Não estou falando de um recurso isolado, mas de uma proposta que junta acesso e pagamento no mesmo ambiente. Foi isso que sustentou minha avaliação positiva e que faz o OpenRouter continuar sendo uma escolha associada a abertura e praticidade. Suporte rápido quando aparecem imprevistos Em determinado momento, apareceram alguns imprevistos no uso. O que mudou o tom da experiência foi a reação do suporte. Chris Hughes assumiu a conversa, entrou rápido e foi muito responsivo. Em vez de deixar o problema se arrastar, ele ajudou a resolver e a colocar as coisas nos trilhos. Esse tipo de atendimento faz diferença quando o acesso a modelos open weight e as variantes de pagamento precisam continuar funcionando. A resposta rápida também aumentou minha confiança no OpenRouter. Como eu já valorizava a flexibilidade de acesso e pagamento, ver alguém do suporte agir com agilidade fechou o ciclo da experiência. O contato foi direto, responsivo e útil, exatamente como eu esperava de uma plataforma que se propõe a democratizar o acesso à IA. Por isso, o suporte teve peso na nota que dou ao OpenRouter, e a experiência geral continuou positiva. No fim, minha experiência com o OpenRouter é positiva porque a plataforma entrega o que considero essencial: muitas variantes de pagamento, acesso a modelos open weight e um suporte que responde rápido quando algo sai do previsto. A combinação entre flexibilidade e atendimento responsivo faz o OpenRouter se destacar no meu uso. Continuo associando a plataforma à ideia de democratização do acesso à IA, agora com a confiança de que imprevistos podem ser tratados com agilidade.

Por que OpenRouter falha com erros de timeout na API

Depois de usar o OpenRouter em tarefas que exigiam continuidade, minha conclusão é direta: a API não sustenta trabalho sério. Eu vi a API parar de responder de forma aleatória e retornar erros como Upstream idle timeout exceeded, sem um padrão que me permitisse contornar o problema. Para mim, OpenRouter virou sinônimo de instabilidade com erros de timeout, e essa experiência me levou a evitar a ferramenta em qualquer fluxo que não possa falhar. O que acontece quando a API do OpenRouter para de responder Na prática, o problema não é uma falha isolada que eu consiga prever. A API simplesmente para de responder no meio de uma tarefa, e eu só percebo quando o fluxo já travou. Como isso acontece de forma aleatória, não tenho um sinal claro para saber se devo esperar, tentar de novo ou abandonar o trabalho. O relato é de problemas constantes, e essa sensação de interrupção sem aviso é o que mais pesa. Para quem depende de continuidade, cada parada obriga a parar o que estava fazendo e lidar com a incerteza. Não é o tipo de comportamento que eu aceito em uma ferramenta que deveria apenas responder às chamadas. A API do OpenRouter, nesse ponto, não me passa segurança. Quando a resposta não vem, o prejuízo é imediato: o trabalho fica pela metade e a confiança cai. Erros de timeout deixam qualquer fluxo vulnerável O erro Upstream idle timeout exceeded é o exemplo mais concreto do que eu enfrentei. Ele aparece no meio da operação sem uma explicação que me ajude a agir, e a impressão é de que a falha escolhe o momento. Para trabalho sério, isso é grave porque eu não consigo tratar o timeout como um evento raro e controlado. A mensagem não resolve o problema; ela apenas confirma que a API parou de responder e que o fluxo precisa ser interrompido. Quando o erro se repete, a reação natural é desconfiar de cada chamada e criar verificações extras, o que tira a simplicidade da ferramenta. O OpenRouter não me dá a previsibilidade necessária para seguir em frente. Eu preciso de uma API que responda de forma consistente, e os erros de timeout mostram que essa consistência não existe no meu uso. Por que não confio o OpenRouter a tarefas críticas A questão central não é ter recursos ou uma interface bonita, é saber se a API vai responder quando eu preciso. No meu caso, a resposta é não. O OpenRouter apresentou problemas constantes e paradas aleatórias, e isso basta para eu não colocá-lo em um fluxo que não pode falhar. Tarefas críticas exigem continuidade, e a ferramenta não entrega essa continuidade no meu uso. Cada timeout ou interrupção me obriga a repensar o desenho do trabalho e a criar uma alternativa manual, o que não deveria ser necessário em uma API. Por isso, a recomendação é evitar o OpenRouter em qualquer operação séria. Não se trata de uma escolha de preferência, mas de confiança: se o serviço falha sem padrão, eu não posso contar com ele. Para mim, a ferramenta ficou marcada pela instabilidade, e não pelo que poderia entregar. No fim, minha avaliação do OpenRouter é negativa porque a API não me passou confiança. Eu vi problemas constantes, paradas aleatórias e erros de timeout que atrapalham qualquer trabalho que precise de continuidade. Não recomendo a ferramenta para tarefas sérias. Se o serviço falha sem um padrão claro, eu prefiro não usar. Essa é a minha experiência real com o OpenRouter, e ela não me deixa com vontade de tentar de novo.

OpenRouter: camada grátis confiável só até o reembolso

Paguei para ver a camada grátis do OpenRouter crescer e me dei mal. Com o plano gratuito de 50 requisições por dia tudo funcionava bem, então coloquei US$ 10 na conta para liberar as 1.000 requisições gratuitas por dia anunciadas. Enquanto o prazo de reembolso de 24 horas esteve aberto, o serviço foi impecável, sem um tropeço. Passado esse prazo, os modelos gratuitos ficaram instáveis, com erros e limite de taxa constantes. Não recomendo. O contraste entre antes e depois do prazo de reembolso Meu histórico com o OpenRouter começou bem. A camada gratuita, limitada a 50 requisições por dia, funcionou de um jeito que me surpreendeu pela consistência, e foi justamente essa boa impressão que me levou a colocar US$ 10 na conta para desbloquear as 1.000 requisições gratuitas por dia anunciadas. Enquanto o prazo de reembolso de 24 horas estava aberto, tudo continuou funcionando sem tropeço: as respostas chegavam, os modelos respondiam e nada indicava problema. Foi então que o cenário virou. Assim que o período de reembolso passou, a experiência mudou de forma drástica. Os modelos gratuitos ficaram instáveis, as requisições começaram a ser limitadas por taxa e uma parte simplesmente falhava. O contraste entre o comportamento de antes e o de depois foi grande demais para eu ignorar. Não tenho como afirmar se isso é intencional ou apenas coincidência, e deixo isso claro, mas como cliente saí com a sensação de ter sido induzido a erro. Anunciar uma cota generosa e entregar outra coisa depois que o dinheiro não pode mais ser recuperado muda a relação de confiança. Erros 429 e 400 nos modelos gratuitos depois da recarga Depois do prazo, o que apareceu com mais frequência foram erros 429 Too Many Requests e 400 Bad Request, além de outras falhas que eu nem conseguia classificar direito. Muitas requisições eram limitadas por taxa e outras simplesmente não retornavam nada útil. Na prática, a cota diária de requisições gratuitas deixou de ser utilizável: de que adianta ter direito a um volume grande de chamadas se elas travam no meio do caminho? O ponto que mais me incomoda é a repetição. Não estou falando de uma instabilidade ocasional, daquelas que qualquer serviço enfrenta em um pico de uso. O padrão voltou várias vezes e sempre nos mesmos modelos, justamente os gratuitos, que eram a razão pela qual eu tinha recarregado. Não tenho dados para apontar a causa, e talvez seja apenas sobrecarga de infraestrutura. O que ficou registrado para mim foi o resultado: os modelos que eu tinha acabado de pagar para acessar com mais folga passaram a ser um conjunto de erros com número na frente. Para quem usa o serviço em uma rotina de testes, isso quebra o fluxo inteiro e obriga a repetir chamadas que deveriam ser automáticas. Recarregar apenas pela cota gratuita exige cautela O conselho que eu daria a quem está de olho nessa recarga é simples: cautela. Se a única razão para depositar dinheiro é ampliar a cota de requisições gratuitas, vale acompanhar se o serviço continua confiável depois que o prazo de reembolso fecha, porque é exatamente aí que a minha experiência mudou. O argumento de marketing de 1.000 requisições gratuitas por dia não significa muita coisa se os modelos estão consistentemente indisponíveis ou limitados por taxa a ponto de não servirem para nada. Também acho importante registrar que o valor em si não é o problema. O que pesa é a assimetria: durante a janela em que eu poderia pedir o dinheiro de volta, tudo funcionou; depois dela, o acesso degradou. Para quem está avaliando, o caminho é testar bastante dentro desse período de 24 horas e desconfiar de cota anunciada que não se sustenta no uso contínuo, principalmente quando o volume diário é o principal argumento da oferta. Eu não recomendo o OpenRouter com base no que vivi, e a minha sugestão é comparar o comportamento real antes e depois da recarga antes de deixar qualquer saldo parado na conta. No fim das contas, minha avaliação do OpenRouter é negativa. A camada gratuita funcionou bem o suficiente para me convencer a pagar, e bastou o prazo de reembolso passar para os modelos gratuitos virarem uma sequência de erros e limites de taxa. Publicidade de cota diária generosa não compensa quando o acesso real não acompanha. Para mim, ficou a lição de tratar recarga feita só pela cota gratuita como aposta, não como investimento.

OpenRouter: suporte que resolve na rotina técnica

OpenRouter entrega resultado em suporte e estabilidade? Na minha avaliação, sim, e por um motivo bem concreto: eu troco entre modelos de linguagem diferentes sem reescrever a integração do meu produto, usando uma única chave de API. E quando algo saiu do previsto no meio do caminho, o suporte apareceu rápido, o que pesou bastante na nota final. Uso a plataforma no dia a dia de desenvolvimento e a experiência tem sido consistente desde o início. Por que o OpenRouter virou minha camada padrão de acesso a modelos O que me fez adotar o OpenRouter como padrão foi a possibilidade de testar modelos diferentes sem montar uma integração nova para cada um. Antes eu mantinha chaves separadas, formatos de requisição distintos e um pequeno inferno de variáveis de ambiente para cada provedor. Com a plataforma, virou um endpoint só e um identificador de modelo que eu troco conforme o teste que quero rodar. Isso mudou a forma como comparo qualidade e custo. Consigo rodar o mesmo prompt em modelos diferentes, olhar o consumo de tokens no painel e decidir com base em dado, não em impressão. Para quem desenvolve produto com IA, esse tipo de comparação lado a lado economiza dias de trabalho e evita decisão no achismo. A camada de créditos também ajuda a controlar gasto sem precisar abrir conta em cada fornecedor. Outro ponto prático é a flexibilidade de fallback. Se um modelo fica indisponível ou devolve erro, dá para direcionar a chamada para outro sem refazer a lógica inteira. No meu caso, isso reduziu bastante o tempo de resposta a incidente, porque eu já tenho um caminho alternativo configurado antes de o problema acontecer. É o tipo de recurso que só parece importante depois que você precisa dele com o cliente esperando. Quando tive problemas e como o suporte do Chris Hughes resolveu Tivemos alguns percalços no meio do caminho, e é aqui que quero dar o crédito devido ao Chris Hughes. Ele entrou na conversa rápido, entendeu o cenário sem precisar de dez mensagens de contexto e foi direto ao ponto para ajudar a organizar a situação. Em ferramenta de infraestrutura, velocidade de primeira resposta vale ouro, porque cada hora parada impacta usuário final. O que me agradou não foi só a rapidez, mas o acompanhamento. Ele não mandou uma resposta genérica de central de ajuda e sumiu. Acompanhou até a confirmação de que estava tudo certo do nosso lado, o que mostra que existe responsabilidade sobre o problema, e não apenas triagem de ticket. Já passei por fornecedores em que o suporte fecha o chamado antes de a solução ser validada, e essa diferença aparece na rotina. Vale registrar que o produto em si já é bom, então o suporte acabou sendo o fator que separou uma avaliação positiva comum de uma avaliação cinco estrelas. Errar é normal em qualquer plataforma que lida com múltiplos provedores e picos de uso. A questão é como a empresa reage, e nesse episódio específico a reação foi exemplar. Por isso faço questão de citar o nome dele aqui. O que o OpenRouter entrega bem e onde ainda exige paciência Do lado positivo, a documentação cobre o essencial e a integração inicial é rápida para quem já mexeu com API de chat completions. O painel de uso mostra consumo por modelo, o que ajuda a montar orçamento e a perceber qual chamada está pesando mais na fatura. Para equipe pequena, esse controle de gasto em um lugar só resolve uma dor que normalmente exige planilha paralela. Do lado que exige paciência, nem todo modelo tem o mesmo comportamento de limites e latência, e isso varia com o provedor por trás. Em horário de pico, percebi diferença de tempo de resposta entre modelos que, no papel, pareciam equivalentes. Também é bom lembrar que a plataforma é uma camada de acesso, então algumas particularidades de fornecedor específico continuam existindo e precisam ser testadas na prática antes de ir para produção. Minha recomendação é simples: teste seus prompts principais em pelo menos dois modelos antes de fechar a escolha, monitore custo nas primeiras semanas e configure fallback desde o começo. Com esse cuidado, a experiência tende a ser tranquila. Para mim, o saldo é claramente positivo e a plataforma já está incorporada no fluxo de desenvolvimento da equipe, sem plano de sair. Depois de todo esse período de uso, o que fica é a sensação de ter escolhido uma base sólida em vez de mais uma camada de complexidade. A combinação de variedade de modelos, controle de custo no painel e um suporte que responde de verdade resolve as três dores que mais me travavam antes. Se você está avaliando se OpenRouter entrega resultado em suporte e estabilidade para o seu contexto, minha resposta segue sendo sim, com a ressalva de testar limites e latência com antecedência para não ter surpresa em produção.

OpenRouter: política de créditos e cobrança

OpenRouter entrega resultado em custo e retorno? Pela experiência que tive, não. A conta foi financiada, os créditos expiraram e recebi apenas um aviso com um mês de antecedência, sem qualquer opção de reembolso do saldo que sobrou. Empresas sérias devolvem o saldo não utilizado independentemente de quando o depósito foi feito, e a OpenRouter simplesmente não faz isso. É por isso que classifico o serviço com 1 de 5 e escrevo este alerta para quem está prestes a colocar dinheiro na plataforma. O aviso de um mês antes dos créditos expirarem A expiração dos créditos chegou como uma surpresa completa. Eu tinha saldo parado na conta e, de repente, recebi um único e-mail avisando que o prazo terminaria em trinta dias. Não houve segunda notificação, não houve contato de alguém do suporte explicando o que aconteceria com o valor restante. A mensagem era clara: usar ou perder. A impressão que ficou é que o relógio trabalha a favor deles, nunca do cliente. Para quem trata créditos de API como orçamento de projeto, um aviso de um mês é curto demais. Pior que o prazo foi o tom: o comunicado não abria espaço para negociação, apenas para consumo. Acabei queimando tokens em testes que não precisava fazer só para não ver o saldo virar zero. Isso não é gestão de cliente, é pressão para gastar. Nenhum outro gateway de modelos com que trabalhei me tratou dessa forma. Por que a OpenRouter não devolve saldo não utilizado Esse é o ponto que mais pesou na avaliação. O saldo não foi consumido, simplesmente expirou, e a resposta foi a mesma de sempre: não há reembolso, independentemente de quanto tempo atrás a conta foi financiada. Empresas boas devolvem o valor restante, mesmo que o depósito tenha sido feito meses antes. A OpenRouter escolheu o caminho oposto, e isso muda a natureza da relação, porque eu deixo de ser cliente e passo a ser alguém que pré-pagou por um serviço com prazo escondido. O argumento de que o crédito tem validade não se sustenta quando não existe aviso razoável nem caminho de devolução. O que existe é uma estrutura em que o saldo não usado alimenta o ecossistema deles, com uma legião de modelos que eu preciso manter girando para não perder o que já paguei. Chame isso de cabal, chame de política interna, o efeito é o mesmo: o dinheiro fica com eles e o risco fica comigo. Total desvantagem para quem deposita. O que eu faria diferente antes de depositar na OpenRouter Se eu pudesse voltar atrás, teria começado com o menor depósito possível e recarregado apenas conforme a demanda real, sem nunca deixar saldo parado na conta. Também teria lido a política de expiração com atenção antes de qualquer aporte, porque ela existe, mas fica longe de onde o usuário costuma olhar. O detalhe é que nem esse cuidado resolve o problema de fundo: em algum momento vai sobrar saldo, e a resposta continuará sendo a mesma. Para quem depende de vários modelos em produção, a recomendação é testar alternativas que permitam recarga granular e devolução de saldo, ou usar provedores diretos quando o volume justifica. No meu caso, a lição foi clara: nunca mais trato crédito de gateway como reserva de longo prazo. Fundir a conta só sob demanda, em valores pequenos, é a única forma de reduzir o prejuízo com esse tipo de regra. Resumo da experiência: depois de perder saldo sem qualquer reembolso e com um único aviso de um mês, não recomendo depositar valores altos na OpenRouter. O serviço funciona para testar modelos, mas a política de créditos é hostil com quem paga. Antes de financiar a conta, leia os termos com lupa e assuma que o saldo pode simplesmente desaparecer do seu lado.

Como o OpenRouter deixou clientes sem API após pagar

Paguei US$ 10,80 em créditos no OpenRouter e o saldo voltou a zero poucos minutos depois, sem eu ter consumido nenhum modelo pago. Desde então a API só devolve erro de fundos insuficientes e meus clientes seguem parados esperando o serviço. Este é o meu relato sobre como a plataforma trata um problema de sincronização de banco de dados e por que o suporte sem resposta humana me custou dinheiro e reputação. Créditos pagos que somem do saldo sem nenhum consumo de modelos O pagamento foi feito em 5 de junho de 2026, no valor de US$ 10,80, com recibo #1505-6204 processado via Stripe. Os créditos apareceram no painel por alguns instantes e em seguida desapareceram por completo, deixando o saldo em US$ 0,00. Não usei nem consumi nenhum modelo pago de API nessa janela curta, então não existe cobrança legítima por trás do zero no dashboard. Isso não é um bug visual nem cosmético. Toda vez que tento conectar na API, recebo um erro duro informando fundos insuficientes, o que torna a plataforma inutilizável na prática. O sistema simplesmente não reconhece o pagamento que ele mesmo processou. Se fosse apenas a tela do painel mostrando um número errado, eu seguiria trabalhando normalmente, mas a chamada falha antes de qualquer requisição sair do meu lado. Para quem depende de modelos por API em produção, esse tipo de falha de sincronização entre cobrança e saldo é o pior cenário possível. O dinheiro sai da conta, o comprovante fica registrado, e o acesso continua bloqueado como se nada tivesse sido pago. Fico com o prejuízo do valor e com o prejuízo maior, que é a operação inteira travada por um erro que não é meu. Tickets escalados para um bot e nenhum agente humano responde Abri o primeiro ticket de suporte no mesmo dia do pagamento, registrado como #29105. Sem nenhuma resposta humana, abri um segundo ticket de acompanhamento em 11 de junho, o #30143. Passaram-se mais de três semanas e os dois continuam congelados no status Escalated, atribuídos a um bot chamado Toney Bot, sem que um único agente humano tenha entrado em contato para resolver o caso. O problema descrito é simples: uma falha de sincronização no banco de dados entre o pagamento aprovado e o saldo da conta. É o tipo de correção que deveria levar minutos para quem tem acesso ao painel administrativo. Em vez disso, o que existe é um fluxo automático que escala o chamado e o deixa parado indefinidamente, sem que ninguém apareça para fechar o ciclo. Também não há transparência sobre prazos. Não recebi previsão, não recebi pedido de documento adicional, não recebi nada além da confirmação automática de abertura de ticket. O silêncio é total, e a impressão que fica é de que o time de suporte não existe ou não tem autorização para mexer em saldo de cliente. Clientes parados e perfis falsos de admin nos canais de comunidade O impacto direto foi financeiro e de reputação. Tenho clientes em espera por serviços que dependem dessas APIs, e cada dia sem acesso é um dia de entrega parada, de explicação desconfortável e de credibilidade arranhada. O valor em créditos era pequeno, mas o custo de ficar fora do ar para quem depende da integração é muito maior do que o valor que desapareceu do painel. Para piorar, os canais de comunidade da plataforma estão tomados por contas falsas de administrador, automatizadas, tentando explorar justamente quem está com problema de cobrança. São perfis que se aproximam de quem abriu reclamação pública oferecendo ajuda e pedindo dados. Quem está desesperado atrás de resolução fica exposto a esse tipo de abordagem, e a plataforma não oferece nenhuma proteção nesse sentido. Somando tudo, o resultado é uma plataforma que cobra rápido, falha no básico e não oferece a quem foi cobrado nenhum caminho humano de correção. Não é uma questão de funcionalidade nem de qualidade dos modelos disponíveis, é questão de confiança no processo de pagamento e no suporte por trás dele. Continuo com o saldo em US$ 0,00, com dois tickets escalados para um bot e sem qualquer previsão de resposta. Registro o relato porque quem avalia o OpenRouter pelo catálogo de modelos não vê essa parte: o processo de cobrança e o atendimento falham justamente no momento em que mais precisam funcionar. Antes de colocar crédito em uma conta nova, vale saber que o dinheiro pode sair e o acesso não vir junto.

Como OpenRouter atua em créditos que expiram

OpenRouter entrega resultado em custo e retorno? Na minha experiência, não. O que me levou a colocar dinheiro na plataforma foi uma declaração pública do próprio COO, feita no Hacker News, de que os créditos não expiram e que a cobrança antecipada funcionava apenas como uma apólice de seguro para cobrir picos de uso. Isso não se sustentou. Quando o saldo sumiu e eu pedi a restauração, recebi uma recusa direta, repetida em três ocasiões diferentes. A promessa do COO no Hacker News e o que encontrei na prática O motivo que me fez confiar na OpenRouter foi bem específico: uma thread no Hacker News em que o COO da empresa afirmou, sem margem para interpretação, que os créditos não expiram e que o modelo pré-pago existia só como garantia, algo próximo de uma apólice de seguro contra eventuais picos de consumo. Aquilo me pareceu razoável e me deu segurança para deixar um saldo maior do que eu costumo usar em um mês. Meses depois, esse saldo simplesmente deixou de existir na interface. Não houve e-mail avisando, não houve alerta na plataforma, não houve nada que eu pudesse ler como prazo de validade. A conta continuou funcionando normalmente pela API, então eu não tinha motivo para desconfiar de nada. Só quando fui conferir os números é que percebi que o valor tinha evaporado do painel. Para quem integra a plataforma em produção, esse silêncio é grave. Quebra a previsibilidade de custo e transforma uma decisão de orçamento em aposta. Se a regra fosse clara desde o começo, eu teria me planejado. O problema não é a existência de uma política de expiração, é a existência de uma política diferente da que foi anunciada publicamente por um executivo da própria empresa. Pedido de restauração: três recusas e nenhuma justificativa Assim que identifiquei o problema, abri um chamado pedindo a restauração dos créditos. A primeira resposta foi uma negativa seca, sem qualquer menção ao que o COO havia declarado publicamente. Insisti, expliquei o contexto e citei a thread original com o link. Veio a segunda recusa, novamente curta, tratando o assunto como encerrado. Tentei uma terceira vez, por outro canal, e o resultado foi idêntico. Três pedidos, três negativas, nenhuma proposta de meio-termo, nenhum crédito de cortesia, nem sequer uma explicação sobre por que a política divulgada publicamente não valia para o meu caso. O atendimento foi educado em todos os contatos, mas educação não resolve nada quando o dinheiro já saiu da minha conta e o serviço não entrega o que prometeu. O que ficou claro para mim é que a comunicação oficial feita em fórum público por um executivo não tem nenhum compromisso com aquilo que o time de suporte aplica no dia a dia. E isso é um problema estrutural, não um caso isolado de um atendente mal informado. Se a empresa não honra o que o próprio COO diz em público, o cliente fica sem qualquer referência confiável para tomar decisão de compra. A parte técnica funciona, mas a gestão de créditos não inspira confiança Depois dessa experiência, passei a olhar a OpenRouter de outro jeito. A parte técnica da plataforma funciona bem: roteamento entre modelos, comparação de preços, uma única API para vários provedores. Nada disso está em discussão aqui, e é justamente por isso que a decepção é maior. O problema é de governança e de confiança, não de engenharia. Quando você pré-paga créditos, está assumindo um risco de crédito com o fornecedor. Esse risco só faz sentido se as regras de validade forem claras e estáveis. Se a política muda, ou se a política real é diferente da que foi anunciada publicamente, o cliente fica sem base para planejar orçamento, especialmente quem usa a plataforma em volume e precisa justificar custo internamente. Hoje eu mantenho saldo mínimo na conta e recarrego com frequência, mesmo assim com desconforto. Para quem pensa em adiantar um valor alto, o meu conselho é não fazer isso. Trate cada recarga como dinheiro que pode desaparecer sem aviso e sem direito a contestação. Foi o aprendizado que tirei, e foi caro. Resumindo o meu veredito: a tecnologia da OpenRouter me atende, mas a gestão de créditos acabou com a confiança que eu tinha. A declaração de que os créditos não expiram não se sustentou quando precisei dela, e três recusas seguidas mostram que não foi falha de um atendente, foi postura da empresa. Vou continuar usando enquanto houver alternativa pior, mas nunca mais com saldo alto parado. Se você valoriza previsibilidade financeira, pense duas vezes antes de pré-pagar.