We’re building <a href="https://www.valymux.xyz/" target="_blank" rel="noopener nofollow">Valymux</a> — a self-hosted LLM gateway that gives you one API endpoint for multiple AI providers. It’s open source, written in Rust, and we’re targeting an end-of-April launch.
This post explains why we started building it and what problem we’re trying to solve.
<hr>
<h2>The Problem We Kept Running Into</h2>
If you’re building with multiple AI providers, you’ve probably dealt with some version of this:
API keys everywhere. OpenAI key in one <code>.env</code> file, Anthropic in another, Google in a third. Some shared over Slack when a teammate needed access. Some copy-pasted into CI secrets and forgotten. No central place to see what keys exist or who has access to what.
Different SDKs, different formats. OpenAI and Anthropic handle system messages differently. Streaming events have different shapes. Error responses don’t match. Switching providers means rewriting integration code, not just changing an API key.
Sharing credentials is awkward. When someone on the team needs to test against Claude, do you share the production key? Create a new one? There’s no clean way to give scoped access without exposing the underlying credential.
None of these problems are catastrophic on their own. But they add up. And as we started using more providers — OpenAI for some things, Anthropic for others, Gemini for cost-sensitive workloads — the friction kept growing.
<hr>
<h2>What Existing Tools Do</h2>
We looked at what’s already out there.
LiteLLM is the most popular option. 40K+ GitHub stars, supports 100+ providers, active community. It’s a solid tool. But it’s Python-based, which means you’re adding a runtime dependency and dealing with GC behavior if latency matters. The March 2026 supply chain incident also made us think harder about what it means to route all your API credentials through a third-party package.
Portkey is more polished, with good observability and enterprise features. But it’s SaaS-first. Your credentials live on their infrastructure. For some teams that’s fine; for us, it wasn’t.
Bifrost is fast — they claim microsecond overhead. But it’s focused on raw performance and enterprise governance, not developer experience for small teams.
There’s clearly a market here. These tools exist because the problem is real. But we wanted something different: self-hosted by default, simple to deploy, and something we could audit ourselves.
<hr>
<h2>What We’re Building</h2>
Valymux is a gateway that sits between your application and your AI providers.
One endpoint, multiple providers. You configure your provider credentials once. Your application hits a single endpoint (<code>/v1/chat/completions</code>). Valymux routes to the right provider and translates the response to a consistent format. Switching from GPT-4 to Claude means changing a model string, not rewriting code.
Virtual keys for access control. Instead of sharing your real API key, you create a “virtual key” that maps to it. You can scope virtual keys to specific models, set expiration dates, and revoke them without touching the underlying credential. The real key stays encrypted inside Valymux.
Capability-aware validation. Different models have different constraints — temperature ranges, streaming support, tool compatibility. Valymux validates requests against model capabilities before sending them upstream. You get a clear error instead of a confusing failure from the provider.
Self-hosted and auditable. It runs on your infrastructure. Credentials are encrypted at rest (AES-256-GCM). The code is open source (AGPL-3.0). You don’t have to trust us — you can read it.
<hr>
<h2>Why Rust</h2>
We went with Rust for a few reasons:
<ul>
<li>Predictable latency. No garbage collector means no GC pauses. When you’re proxying requests, consistent performance matters more than peak performance.</li>
<li>Single binary. One Docker image, no runtime dependencies to manage.</li>
<li>Memory safety. The gateway handles credentials. We wanted the compiler catching memory bugs, not production.</li>
</ul>
This isn’t a “Rust is better than Python” argument. LiteLLM works well for a lot of teams. We just had different constraints.
<hr>
<h2>Where We Are Now</h2>
We’re pre-MVP. Here’s the current status:
Done:
<ul>
<li>Core gateway architecture (Tokio + Axum)</li>
<li>Credential encryption (AES-256-GCM)</li>
<li>Virtual key system with scoped access</li>
<li>Google Gemini adapter (streaming and non-streaming)</li>
<li>Request logging with token usage</li>
</ul>
In progress:
<ul>
<li>OpenAI adapter (should be straightforward — it’s the native format)</li>
<li>Anthropic adapter (requires message format translation)</li>
<li>Frontend dashboard and configuration UI</li>
</ul>
Target: End of April 2026
<hr>
<h2>What We’d Like From You</h2>
We’re building this for developers who have the same problems we do. If that’s you, we’d genuinely like your input.
What’s your current setup? What works? What’s frustrating? What would actually make you consider switching tools?
→ <a href="https://www.valymux.xyz/feedback" target="_blank" rel="noopener nofollow">Share your experience</a>
Want early access when we launch?
→ <a href="https://www.valymux.xyz/waitlist" target="_blank" rel="noopener nofollow">Join the waitlist</a>
Want to follow along or contribute?
→ <a href="https://github.com/cloaky233/Valymux" target="_blank" rel="noopener nofollow">GitHub</a>
<hr>
<h2>What’s Next</h2>
Over the next few weeks, we’ll be finishing the OpenAI and Anthropic adapters, building out the frontend, and getting the Docker Compose deployment polished.
We’re building in public, so if you’re interested in following along or have questions, the GitHub repo is the best place to start.
<hr>
Valymux is open source (AGPL-3.0) and self-hostable. Website: <a href="https://www.valymux.xyz" target="_blank" rel="noopener nofollow">valymux.xyz</a>

Lay Sheth aka CLoaKY

Valymux is a self-hosted LLM gateway written in Rust that provides a single API endpoint for multiple AI providers (OpenAI, Anthropic, Google Gemini). It addresses pain points like scattered API keys, inconsistent SDKs, and credential sharing by offering virtual keys with scoped access, capability-aware request validation, and AES-256-GCM credential encryption. Built on Tokio and Axum, it targets predictable low-latency proxying without GC pauses. The project is pre-MVP, open source under AGPL-3.0, and targeting an end-of-April 2026 launch. It positions itself against LiteLLM (Python-based), Portkey (SaaS-first), and Bifrost (enterprise-focused) as a self-hostable, developer-friendly alternative.

Why We're Building a Self-Hosted LLM Gateway