Floopy isn't an AI Gateway. It's an AI Agent Optimization Platform.

Same gateway primitives, different scope. What is the same: OpenAI-compatible endpoint, multi-provider routing, caching, rate limiting, request/response logging, an LLM firewall, an audit dashboard. What differs: Floopy ships a feedback-driven router (session NPS to routing decisions), per-decision confidence on every audit row, a dry-run endpoint (POST /v1/routing/explain), customer-declared optimization constraints (PUT /v1/constraints), shadow-mode experiments (POST /v1/experiments), and a JSONL export of decisions with a SHA-256 trailer (GET /v1/export/decisions). Portkey leans further into prompt management and agent traces; Floopy leans into closing the loop between user-felt outcomes and routing. If you mainly need a configurable gateway, Portkey covers it. If you also want a router that learns from outcomes you already collect, Floopy fits.

Helicone is excellent at per-request observability and developer feedback — each call gets its own rating. Floopy takes the opposite stance: one NPS score per session propagates across every routing decision in that session, because agent quality depends on the whole trajectory, not individual responses. If you want fine-grained request-level tracking, Helicone fits. If you want the router to learn from session-level end-user signal you already collect, Floopy fits.

For the proxy layer, mostly. Floopy supports 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 — through one OpenAI-compatible endpoint. Streaming, tool calls, and vision inputs are covered for the majors (OpenAI, Anthropic, Gemini, Bedrock); for the others, streaming and tools are supported, vision coverage varies by model. LiteLLM supports more providers (100+) and is open-source if you want to self-host. Floopy trades raw provider count for a managed feedback loop, an LLM firewall, an audit API, and a decision export. If you self-host LiteLLM purely for normalization, both work; if you want the loop, that is what Floopy adds.

Same problem space, different posture on data pooling. TensorZero is open-source and self-hosted, so all signal stays inside your infrastructure. Floopy is managed SaaS with cross-tenant aggregation on a narrow set of fields: aggregated session NPS, LLM-as-judge scores per (provider, model), and benchmark deltas. What is NOT pooled: raw prompts, raw completions, organization identifiers, user identifiers, request bodies, response bodies. Aggregated signals influence the shared priors that warm up Day-0 phase for new orgs; once your org has its own data, your weights dominate. Enterprise can opt out of pooling entirely. Pick TensorZero if you must run the gateway yourself or cannot share any signal at all. Pick Floopy if you want managed infrastructure and the speed-up of warm priors that come from aggregated, non-PII signal.

Because agent quality depends on the trajectory, not the response. Tool calls, retries, and reasoning steps inside one session all influence the final outcome the user feels — so one NPS per session credits or penalises every routing decision in that session. Per-request signal is still available: every request gets an LLM-as-judge score across four dimensions (relevance, coherence, helpfulness, safety), recorded on the decision_trace and queryable via GET /v1/decisions/{id}. You can also POST per-request feedback to /v1/feedback with a request id — the router accepts it and weights it under the Auto phase. The default is session NPS because that is what most teams already collect; the option to attach per-request signal is real and shipped, just not the headline path.