LLM API Gateway Tool: AxonHub
Nite included in Software RecommendationsRecently, I have been collecting quite a few public AI relay sites from linux.do. Once the list grew, I ran into a practical need: I wanted to put them behind a single endpoint and route requests to different providers when needed.
The need itself was simple, but finding the right tool took some trial and error. After testing a few options, the one I kept was AxonHub. If you have a similar setup, it is worth a look.
1. My requirements were pretty simple
I was not looking for a heavy enterprise gateway. I wanted an aggregation layer that stayed light and could still handle differences between multiple upstream providers cleanly:
- One unified external endpoint
- Multiple public relay sites behind it
- One public model name mapped to different upstream model names
- Easy logging and routing inspection when something goes wrong
It sounds like something any API gateway should be able to do, but in practice the details shape the experience.
2. Why I did not stick with LiteLLM
The first thing I tried was LiteLLM.
LiteLLM is not bad, and its ecosystem is fairly mature, but for my use case it had two obvious issues.
First, it is written in Python, so the whole stack feels relatively heavy. If all I want is a simple aggregator and router for public relay sites, pulling in a heavier runtime and dependency set feels unnecessary.
Second, the runtime performance was not as satisfying as I hoped. For a middle layer that already sits between the client and the upstream service, I want it to stay light and fast instead of eating part of the responsiveness on its own.
So LiteLLM was usable, but it did not match the “just run it and forget it” feeling I wanted.
3. Why New API was not a great fit either
After that, I tried New API.
The issue was not multi-channel support itself. It just did not fit my scenario well when I wanted one public-facing model name to map to different upstream model names.
A typical example looks like this:
- On public relay site A, the model is named
gpt-5.3 - On public relay site B, the same model is named
openai/gpt-5.3
What I really want is to expose one unified model name to clients, no matter which provider the request ends up using. That keeps client configuration simple and avoids rewriting scripts every time I switch providers.
AxonHub handled this part much better for me.
4. Why AxonHub worked for me
What I like most about AxonHub is that it fits this “multiple upstreams plus model-name mapping” setup very well.
I. Model mapping is easy to work with
I can expose one unified model name externally, then map it to the real model names used by different public relay sites.
This may look like a small feature, but it matters a lot once you start aggregating multiple upstream sources. As soon as you use more than one provider, naming differences are almost guaranteed. If the gateway layer cannot handle that cleanly, maintenance gets messy very quickly.
AxonHub solves that directly.
II. It feels very fast
This was the most noticeable change after I switched.
As a middleware service, AxonHub feels light. Request forwarding and routing are quick and direct, without that obvious “there is another layer in between, so everything is slower now” drag. In daily use, that difference is easy to notice.
III. Adding channels is convenient
The public relay sites I use come from many different places, so I change them often.
If adding or replacing a provider takes too much effort every time, the aggregator becomes the burden. AxonHub is easier to work with here. Adding channels and adjusting routing is fairly simple, which fits the way I keep collecting and testing different public relay sites.
IV. The WebUI is great for troubleshooting
Another thing I really like is the WebUI.
AxonHub lets me inspect request logs and routing details in real time from the WebUI, which helps a lot when debugging issues. For example, I can quickly see which channel handled a request and why a route matched. The upstream response is there too.
That kind of observability matters a lot for an aggregation service. If an upstream provider becomes unstable or a model mapping is wrong, troubleshooting gets much more painful. The same goes for route misses.
5. Who this fits best
If your setup looks similar to mine, AxonHub is a good fit:
- You have multiple public relay sites or multiple upstream AI APIs
- You want to keep only one unified external endpoint
- You want one model name on the client side, regardless of upstream naming differences
- You want quick access to request logs and routing details
- You do not want to introduce a heavy or slow aggregation layer
If you are also trying to aggregate multiple public relay sites, or you are stuck on model-name mapping between providers, AxonHub is worth a look: https://github.com/looplj/axonhub. For me, it has been the smoothest solution for this kind of setup so far.