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!
We considered WASM and libloading, but plugins often require database connections or other privileges. With WASM, supporting that would be the SDK’s responsibility.
Dynamic loading with libloading didn’t offer enough benefit for this design, so we chose modular crates compiled into the application.
Quick question: do you personally understand the Rust code in your project, or was the whole thing AI-assisted ?
classic hackernews comments
https://github.com/respanai/respan-gateway/blob/main/apps/ga...
If we as an industry are going to p(doom) about security and hacking, perhaps we should stop doing things like this?
Today I use GoModel [1], and in example, all providers are built in. Having recently given Pi a try, the plugin ecosystem is a mess and I have more security worries.
Can you explain why you think a plugin based system is preferable to a competent team building a complete, curated product?
Plugins seems like a great way to expose yourself to supply chain security events.
[1] https://gomodel.enterpilot.io/
Plugins offer better interface boundaries. For example, you can implement a PII feature without having to touch the logging, billing, or provider subsystems.
Crates are still an avenue for supply chain compromise, they come from random developers. We've seen it before and I expect we will see in more frequently for a while, until out industry gets really serious about all the things around this.
We have configurable template plugins for common things like adding vendors and formats. No rebuild needed for config changes, but if you want custom logic beyond those templates, you need to compile it in.
And yes, crates still have supply-chain risks. I just meant you can review the source you’re adding, unlike a binary you don’t know.
I would recommend a batteries included approach. You can see a similar difference between adoption of OpenCode and Pi in the harness space.
And get the image published, a changing API is no reason not to have one. Every project evolves their API and users know how to handle this situation.