Launch HN: Respan (YC W24) – Open-source Rust AI gateway built around plugins
Hey HN, this is Andy from Respan (https://www.respan.ai). We are building an open-source Rust AI gateway. It is a decoupled gateway, so everything is a plugin, including different providers, protocols (MCP, voice), modalities (images, videos), and gateway features (fallbacks, PII redaction, smart routing). Instead of packaging tons of providers and features into one gateway, Respan provides a small core and public interfaces that teams can use to assemble the AI infrastructure their application needs. That way, users can build their own features as additional plugins without having to change the gateway's core. Here’s a video demo: https://www.youtube.com/watch?v=pVv2ibXiTXM There are countless LLM gateways and most of them solve a common problem: calling different providers from a single endpoint. However, adding new features can become prohibitively difficult. So developers can end up building another gateway to solve a specific problem. We've been building our gateway based on LiteLLM since 2024, and now it's providing services for thousands of orgs. Each org needs different API key settings, routes, and limits. To support that, we kept wrapping LiteLLM, adding more features to it, and at one stage, our wrapper code exceeded 100,000 lines. This January, a routine LiteLLM upgrade caused intermittent connection errors, and we had to roll back. We still haven't figured out the cause, but since then, we no longer upgrade LiteLLM directly and instead manually backport upstream fixes. These experiences made us realize that continuing to patch LiteLLM is not a sustainable long-term solution, and we had to redesign the gateway ourselves. While redesigning our gateway, we wanted to make it easier to add features without breaking existing ones. Inspired by Nginx, we think an AI gateway should have a really small core, only responsible for dispatching events. We believe that everything should be a plugin in our gateway, including providers (OpenAI, Anthropic, Gemini), protocols (chat, realtime voice, MCP), modalities (images, videos), and gateway features for reliability and security (smart routing, fallbacks, and PII redaction through example plugins). Beyond that, we want developers to be able to easily extend the gateway's capabilities by adding their own plugins, without touching the core. Adding a provider, even your own, is dead simple, because quirks are plugins too and there’s nothing magical about them. A provider is a short file, Mistral’s is 22 lines, and each quirk, like Groq putting token usage in its own field, gets its own test. Respan Gateway does more than let you call Claude or Gemini models from the OpenAI SDK. It handles tools, images, and reasoning protocols automatically: an application based on the OpenAI Realtime API can also use Gemini Live through the gateway, though not every feature translates. A simple chat app can use MCP tools configured in the gateway, without implementing MCP itself. We also parse requests into a shared structure. When the client and provider use the same API, we preserve provider-specific fields in their native format, even if our shared structure doesn't have a field for them. That way, the gateway can write them back instead of dropping them. Here’s how it works: An adapter hands each HTTP or WebSocket connection to the first client format that recognizes it. The format exposes the request as a two-way stream of typed input and output events. The core runs plugins in registration order, allowing them to choose a provider, filter or wrap either stream, make additional calls, return a response, or refuse the request. A provider format then opens the upstream connection. If the client and provider use the same format and no plugin changes the payload, the original bytes and protocol-specific fields can pass through unchanged. When formats differ, they translate through shared types for messages, tool calls, results, streams, and usage. This stream model can represent both one-shot HTTP requests and long-lived bidirectional sessions. The gateway is open source at https://github.com/respanai/respan-gateway under the MIT or Apache-2.0 license. You don't need to use Respan's hosted platform and can run it directly on your local machine. Build it from source, add your provider keys, and swap the base URL in a supported client. You can keep using the API your client already speaks. It's still pre-alpha. We make money from our hosted platform (https://www.respan.ai/pricing), which runs the gateway for you with native observability and evals, along with unified billing. If you’re building routing, tools, filtering, observability, or security for agents, we'd love to see it as a plugin. PLUGINS.md in the repo explains how to write one and links to the plugins we’ve created so far. Turning that into an ecosystem is basically our roadmap, and we welcome you to contribute your own plugins. We'd love to answer any questions and hear your feedback! https://github.com/respanai/respan-gateway
评论
5 条预览评论 · 正在加载完整讨论请先登录 h4cker 账号，然后连接 Hacker News 后发表评论。
Operating a Go gateway in production (single machine, ~20B tokens/month across several upstreams), usage-reporting quirks are exactly where our pain concentrated too. What survived for us: - Treat every upstream try as an attempt with its own usage record, and let request cost be whatever the attempts sum to. Without attempt-level accounting, retries make your per-request numbers lie: you count the first attempt's tokens but pay for the retry. - Vendor-reported usage is advisory, not gospel. Some providers emit usage only on the final SSE chunk, some want stream_options, some never report it for streams at all. The parser zoo is unavoidable, but the damage is contained if the rest of the system treats usage as best-effort telemetry. - The sneaky case is disconnects, not usage: a client disconnect storm once looked identical to backend failures and put every healthy backend into cooldown until the pool was empty. Disconnects are network, not backend health - classifying them separately bought us more than any routing policy change. How does Respan handle the retry-accounting side - do plugins see per-attempt records, or is usage aggregated at the request level after middleware runs?
Good luck with the launch! Quick question: do you personally understand the Rust code in your project, or was the whole thing AI-assisted ?
The point about plugin boundaries and safety is spot on. In Rust, choosing between compile-time static dispatch (like trait objects / generics) vs. runtime dynamic loading is always the hardest architectural trade-off for a gateway. Compile-time is blazing fast and gives you strong safety guarantees, but forces users to recompile the binary for custom plugins. Runtime/WASM gives you isolation and hot-reloading, but introduces serialization overhead on the hot path. Curious how Respan handles that split for third-party extensions.
The plugin boundary matters more than the number of plugins. I’d limit the core to request normalization, ordered middleware execution, cancellation, and observability. Each plugin would have a versioned manifest with declared capabilities and compatibility ranges. Run third-party plugins out of process or in WASM so a panic, timeout, or dependency conflict can’t take down the gateway. A small conformance suite using recorded provider responses would also make API changes safer. For prompt-facing plugins, Wordfully can tighten the wording and remove ambiguity before requests enter the gateway.
Replying since this one didn’t get an answer. I’ve been building a gateway too and usage reporting is the annoying part. Groq only gives you usage on streamed responses if you ask for it with stream_options, otherwise you’re guessing. Mistral has no equivalent at all, so for streams you end up estimating from response length. Curious how Respan handles that, or if the plugin just trusts whatever the provider sends back.