ReliAPI

O ReliAPI expõe duas rotas de proxy: /v1/proxy/http para destinos HTTP genéricos e /v1/proxy/llm para provedores de modelos de linguagem configurados. Você define os destinos num arquivo config.yaml, e o proxy aplica suas regras, como cache ou limites de circuito, antes de repassar a chamada. Um só lugar para mudar como cada pedido de saída se comporta. Essa é a vantagem.

Um cache com TTL cobre pedidos HTTP GET e HEAD, além de respostas de LLM sem streaming. Você define uma janela de cache por destino, e chamadas repetidas dentro dessa janela devolvem o resultado guardado em vez de bater de novo no provedor. Para uma API que você chama do mesmo jeito centenas de vezes por dia, só isso já corta latência e custo, e com o tempo soma.

A rota de LLM aceita uma chave de idempotência, e o Redis a rastreia para que o mesmo pedido lógico não execute duas vezes. O projeto é cuidadoso aqui: isso cobre apenas chamadas sem streaming, e não promete execução exactly-once nem coincidência com a cobrança do provedor, então leia a documentação antes de confiar. Leia como proteção contra duplicatas acidentais, não como garantia de cobrança.

Cada destino pode carregar tetos de custo flexíveis e rígidos. Antes de um pedido sair, o ReliAPI estima o custo; um teto flexível pode avisar você e um rígido pode bloquear a chamada. A ressalva é que são estimativas antes do pedido, então não vão pegar cada centavo que um provedor cobra de fato. Bom o bastante para limites. Não para contabilidade.

Os limites de pedidos embutidos permitem limitar o tráfego por nível configurado, e os destinos são definidos em YAML simples em vez de embutidos no código. Adicionar um provedor ou mudar uma URL base é editar um arquivo de configuração. Sem novo deploy. Isso mantém administrável um arranjo com vários provedores. Para equipes que buscam confiabilidade de API em vários provedores, esse desenho guiado por configuração é a parte que economiza mais tempo.

Os SDKs oficiais no npm (reliapi-sdk) e no PyPI (reliapi-sdk) embrulham as rotas do proxy para as duas linguagens. Você pode chamar proxy_http ou proxy_llm com poucas linhas de código em vez de montar os pedidos à mão, e há também uma GitHub Action para fluxos de CI.

Um endpoint /metrics expõe dados do Prometheus para o seu stack de monitoramento atual. Ali você acompanha o tráfego do proxy. Isso importa se você quer um alerta quando o gasto ou as taxas de erro se mexem, em vez de descobrir na fatura.