O Floopy não é um AI Gateway. É uma Plataforma de Otimização de Agentes de IA.

Mesmas primitivas de gateway, escopo diferente. O que é igual: endpoint compatível com OpenAI, roteamento multi-provider, caching, rate limiting, logging de request/response, firewall por LLM, dashboard de auditoria. O que difere: o Floopy entrega um router guiado por feedback (NPS de sessão para decisões de roteamento), confidence por decisão em cada linha de auditoria, um endpoint de dry-run (POST /v1/routing/explain), constraints de otimização declarados pelo cliente (PUT /v1/constraints), experimentos em modo shadow (POST /v1/experiments) e exportação em JSONL com trailer SHA-256 (GET /v1/export/decisions). O Portkey investe mais em prompt management e traces de agente; o Floopy investe em fechar o loop entre o resultado sentido pelo usuário e o roteamento. Se você precisa principalmente de um gateway configurável, o Portkey cobre. Se você também quer um router que aprende com sinais que você já coleta, o Floopy encaixa.

O Helicone é excelente em observabilidade por requisição e feedback de desenvolvedor — cada chamada recebe seu próprio rating. O Floopy assume a posição oposta: uma nota NPS por sessão propaga para cada decisão de roteamento daquela sessão, porque a qualidade de um agente depende da trajetória inteira, não de respostas individuais. Se você quer tracking granular por requisição, o Helicone encaixa. Se você quer que o router aprenda com sinal de nível de sessão do usuário final que você já coleta, o Floopy encaixa.

Para a camada de proxy, na maior parte sim. O Floopy suporta 20 providers — OpenAI, Anthropic, Google Gemini, Google Vertex AI, AWS Bedrock, Azure OpenAI, DeepSeek, Mistral, xAI, Groq, Cerebras, SambaNova, Together AI, Fireworks AI, Perplexity, Cohere, AI21 Labs, DeepInfra, Nebius, Novita — através de um único endpoint compatível com OpenAI. Streaming, tool calls e entradas de visão são cobertos para os majors (OpenAI, Anthropic, Gemini, Bedrock); para os demais, streaming e tools são suportados, e a cobertura de visão varia por modelo. O LiteLLM suporta mais providers (100+) e é open-source se você quiser self-hosting. O Floopy troca contagem bruta de providers por um loop de feedback gerenciado, um firewall por LLM, uma API de auditoria e um export de decisões. Se você auto-hospeda o LiteLLM apenas para normalização, ambos servem; se você quer o loop, é isso que o Floopy adiciona.

Mesmo espaço de problema, postura diferente sobre pooling de dados. O TensorZero é open-source e self-hosted, então todo o sinal fica dentro da sua infraestrutura. O Floopy é SaaS gerenciado com agregação cross-tenant em um conjunto restrito de campos: NPS de sessão agregado, scores LLM-as-judge por (provider, model) e deltas de benchmark. O que NÃO é poolizado: prompts brutos, respostas brutas, identificadores de organização, identificadores de usuário, request bodies, response bodies. Os sinais agregados influenciam os priors compartilhados que aquecem a fase Day-0 para novas orgs; uma vez que sua org tem dados próprios, seus pesos dominam. Enterprise pode optar por sair do pooling por completo. Escolha o TensorZero se você precisa rodar o gateway você mesmo ou se não pode compartilhar nenhum sinal. Escolha o Floopy se você quer infraestrutura gerenciada e o ganho de velocidade dos priors aquecidos via sinal agregado e sem PII.

Porque a qualidade de um agente depende da trajetória, não da resposta. Tool calls, retries e passos de raciocínio dentro de uma sessão influenciam o resultado final que o usuário sente — então um NPS por sessão credita ou penaliza cada decisão de roteamento daquela sessão. O sinal por requisição segue disponível: cada requisição recebe uma pontuação LLM-as-judge em quatro dimensões (relevância, coerência, utilidade, segurança), registrada no decision_trace e consultável via GET /v1/decisions/{id}. Você também pode enviar feedback por requisição via POST para /v1/feedback com um request id — o router aceita e pondera dentro da fase Auto. O default é NPS de sessão porque é o que a maioria dos times já coleta; a opção de anexar sinal por requisição é real e está em produção, só não é o caminho principal.