Kaopu API

Kaopu API sells itself as "AI Application Infrastructure Foundation," and the pitch is narrow but coherent: one standard protocol, one endpoint, many upstreams. The homepage quotes 50+ upstream services integrated, 100+ models with billing support, 50+ compatible API routes, and 10+ scheduling controls, and it shows the exact request shape — a POST to /v1/chat/completions with an Authorization bearer key and a model field you route yourself. That OpenAI-compatible shape matters because it means existing SDKs and wrappers generally work without code changes; the vendor's own example returns a usage block with total_tokens, and the marketing page demonstrates an SSE streaming response. Strengths. The operational feature set is the real product: load balancing under high concurrency, rate limiting per key or per user, real-time cost tracking, request caching, and per-user API keys with scoped permissions. For a platform team that currently reconciles five provider invoices and five dashboards, consolidating that into one console is the concrete win. Being open source and self-hostable is meaningfully different from hosted-only routers — if your prompts cannot leave your own infrastructure, a hosted router is simply not an option and this is. Multi-region deployment and NewAPI multi-protocol configuration support are aimed at people already running self-managed AI infrastructure, and the one-click configuration for Cherry Studio and CC Switch is a small but genuinely useful detail for individual developers. Weaknesses. This is infrastructure, so someone has to run it. Self-hosting means you own uptime, upgrades, and debugging of failed routes, and the vendor says so plainly. The extra hop adds latency and, if you are paying a gateway fee, cost on top of what providers charge directly — the math only works if failover, caching, and consolidated billing save you more than the hop costs. Some controls sit behind specific scheduling configuration, so simple single-provider setups will use a small fraction of what the product does and would be better served by calling the provider's API directly. Because Kaopu sits on a standard protocol rather than proprietary intelligence, there is little moat: LiteLLM offers a comparable open-source proxy, and hosted routers offer comparable convenience. Where it fits. Teams running more than one provider in production, teams that need per-developer keys with permissions and a single spend view, and organisations with a self-hosting mandate. Where it does not: solo builders using one model, non-technical users who want a no-code chatbot builder, and teams that do not want to operate any infrastructure at all. On the specifics: the homepage is what it is — a product page for an infrastructure component. Pricing structure, documentation depth, and release cadence were not reachable in this pass, so treat any figures you see elsewhere as unverified against the source. Evaluate on your own traffic against LiteLLM and